OpenSSH use of OpenSSL in FIPS Mode

Stan Kladko 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 
>> 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 



More information about the openssh-unix-dev mailing list