On Sun, Mar 04, 2007 at 05:13:10PM -0800, Stan Kladko wrote:
> Ask the vendor to supply a signed
> letter stating their application, product or module is a validated module or
> incorporates a validated module, the module provides all the cryptographic
> services in the solution, and reference the modules validation certificate
> number."
And that last part is the rub.
> A typical network protocol, such as IPSec/IKE, TLS, SSH, S-MIME or 802.11
> protocol family may provide a complex variety of services. Some of such
> services may have cryptographic nature and utilize Approved or allowed for
> use cryptographic algorithms, such as encryption, decryption, signatures,
> hashes, message digests and others. Other services provided by a network
> protocol may be of non-cryptographic nature, such as packet routing, packet
> assembly/disassembly, defragmentation, radio and link layer communications,
> firewalling, network address translation, address resolution, quality of
> service, re-transmission and others.
Though there may exist certain protocols that combine security and
non-security relevant functionality, the vast majority of IPSec/IKE,
TLS and SSHv2 _is_ security relevant from a FIPS 140 perspective.
> "Both IPSEC and EFS in Windows 2000, XP, and Server 2003 use the FIPS-140-1
> or FIPS 140-2 (as appropriate) evaluated Kernel Mode Cryptographic Module to
> encrypt the traffic packet data and file contents respectively if configured
> appropriately with the selections of FIPS compliant algorithms."
>
> A review of the Kernel Module Security Policy then shows that the module's
> services are specified as services performing cryptographic algorithms
> supported by IPSec/IKE(such as encryption/decryption and key agreement) and
> not as providing a full IPSec/IKE protocol impelementation. This could again
> serve as an illustration of the fact that non-cryptographic services of a
> particular protocol are in many cases implemented outside of a cryptographic
> module.
I think that we agree that one could design a module that does implement
all of the security relevant portions of a protocol. Is it done in the
case of Microsoft's Kernel Module? I have no idea, and I wouldn't care
to speculate.
Is this the case for OpenSSL's validated module, a case where literally
anyone with a bit of time on their hands can look at the module and
determine precisely what the module is (and is not) doing? I don't
think so.
In particular, within SSHv2 and TLS there are key agreement protocols.
(If we want to get all reference, you'll note that these protocols
are listed in FIPS 140-2's IG 7.1). As key establishment protocols are
security relevant, and thus the code that implements them must be included
within a FIPS boundary. Does it have to be included within the OpenSSL
sub-module? No, of course not. But if this functionality exists within
the "IT device", it does need to be included within SOME FIPS module.
Josh
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
|