OpenSSH use of OpenSSL in FIPS Mode
kladko at aspectlabs.com
Tue Mar 6 08:28:20 EST 2007
Coming back to the quote from the CMVP FAQ
"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."
It is specified that the module provides "all the cryptographic services in
the solution". It is not specified that the module provides "all the
security-relevant services in the solution". The FIPS 140-2 standard in
focused on the cryptography. There are many generically security relevant
functionalities such as antivirus protection, firewalling, IPS/IDS and
others which are not currently covered by the FIPS 140-2 standard. An
antivirus solution which uses a cryptographic module for its operations can
satisfy requirements of the FIPS 140-2 by delegating its cryptographic
functions to an embedded FIPS 140-2 validated module. Including the entire
antivirus solution in the FIPS 140-2 validation would hardly improve the
overall security since FIPS 140-2 does not currently have requirements in
the field of antivirus protection. In a similar fashion, the FIPS 140-2
standard does not currently have requirements related to network
vulnerabilities or denial of service attacks.
The main job of a FIPS 140-2 testing lab is to consistently apply current
regulations including the FIPS 140-2 standard, the Derived Test Requirements
and the Implementation Guidance. One can have suggestions for further
improvements which could be communicated to the CMVP and potentially
incorporated in the future versions of the standard or in the implementation
guidance. For the current version of the standard a testing lab needs to
apply the current regulations impartially to all vendors. If in the future
the CMVP decides to introduce a simple and inexpensive program for
validating compliance of IT solutions with embedded FIPS 140-2 modules it
might be a reasonable idea. For now, as explained in the CMVP FAQ, such
validation is not available.
Since the CMVP does not have a formal program for validation of IT solutions
with embedded FIPS 140-2 modules, the question is how is the actual
compliance/non-compliance determined. Our experience is that the compliance
is determined by the federal agency/buyer selecting the solution. During the
process the customer may contact the CMVP, testing labs or security experts
for an opinion. In many cases, though, the buyers make such decisions
independently. Here one shall mention that FIPS 140-2 is only a security
baseline and each federal agency may establish its own requirements
exceeding the requirements of FIPS 140-2. In the particular example of
network protocols our experience shows that federal agencies generally do
accept networking products (IPSEC/TLS/SSH etc.) with embedded FIPS 140-2
validated crypto software modules or hardware cards as FIPS 140-2 compliant.
----- Original Message -----
From: "Joshua Hill" <josh-lists at untruth.org>
To: "Stan Kladko" <kladko at aspectlabs.com>
Cc: <openssh-unix-dev at mindrot.org>
Sent: Monday, March 05, 2007 9:46 AM
Subject: Re: OpenSSH use of OpenSSL in FIPS Mode
> 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
>> incorporates a validated module, the module provides all the
>> services in the solution, and reference the modules validation
> 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
>> 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,
>> assembly/disassembly, defragmentation, radio and link layer
>> 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
>> or FIPS 140-2 (as appropriate) evaluated Kernel Mode Cryptographic Module
>> encrypt the traffic packet data and file contents respectively if
>> appropriately with the selections of FIPS compliant algorithms."
>> A review of the Kernel Module Security Policy then shows that the
>> services are specified as services performing cryptographic algorithms
>> supported by IPSec/IKE(such as encryption/decryption and key agreement)
>> not as providing a full IPSec/IKE protocol impelementation. This could
>> serve as an illustration of the fact that non-cryptographic services of a
>> particular protocol are in many cases implemented outside of a
> 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.
More information about the openssh-unix-dev