Re: SSL Certs and FIPS 140-2 Compliance

Excellent comments all.  I believe that the whole issue of FIPS and multiple copies of SSL certs/private keys are not explicitly defined but implied.  I have been working with our Covalent Apache reps on this issue.  As you expect, FIPS mainly applies to more traditional PKI environments where you have one authoratative key store (app) that is managing these pub/private keypairs.  It is still quite unclear how these FIPS regulations functionally apply to most web SSL environments.  I agree that it is difficult to apply these regulations to a standard web farm infrastructure with load-balancing/fail-over, etc...

 

Another aspect that I believe is mudding the waters is the licensing of SSL certs by 3rd party CAs.  I contacted my CA about this issue and they instructed me to create separate CSRs for each physical server and alter a portion of the OU field.  This would allow me to implement unique SSL certs on each host (meaning that there would be no reuse/duplication of private keys) and this would not effect the end user since they would all reference the same domain name/URL.  While this is great info - this was not related to FIPS compliancy, but rather the CAs licensing policy (meaning more $$$$$ for unique certs).

 

I agree with the comments about the need for NIST to update their FIPS data to include applicability for web servers/SSL.  The one issue here is that these types of updates/tests need a sponsor.  I am urging my Apache vendor to pursue this course of action.

 

--
Ryan C. Barnett
Web Application Security Consortium (WASC) Member
CIS Apache Benchmark Project Lead
SANS Instructor: Securing Apache
GCIA, GCFA, GCIH, GSNA, GCUX, GSEC

 

On 9/6/05, Lyal Collins <lyal.collins@xxxxxxxxxxxxx> wrote:

As many of us have found, often an organisation's culture is seen as 'the
standard', rather than based on any documented requirement or approach at
industry or formal standaisation level.

Overall, this is a domain question, not a machine-specific question.
Treated as a machine-specific problem, a unique cert machine effectively
means that load balancing and hot-failover won't work, affeacting the
Availability dimension of CIA.

This is a dead discussion in the current state of SSL and PKI - the concepts
evolved at a time when today's needs  and security issues weren't envisaged,
or couldn't be included in the standards of the day.  And any government
standard that counters the fundamentals of SSL and HTTP/s merely mean no-one
can meet security and business requirements for up-time.

Should there be a re-drafting of the standard, or new standards to address
today's and what are perceived to be tomorrow's needs - definitely yes.

Fips is more about correctness of implementation of the crypto solution,
less on how keys are used.  Other NIST documents may be more relevant.
Not being in the US, I won't claim to be an expert on NIST documents, but a
quick read shows:
Special Pub 800-44 is silent on this topic
Nist CIMC PP is not helpful, other than using terms that suggest a SSL cert
store in a web server is a part of the certificate issuing and management
components, and that private keys outside a 'cimc' are stored in encrypted
form.  I would envison this caters for the process of moving the cert
between machines, using PKCS7/8or similar.
Draft Nist Pub "mininum requirements for federal info processs sysyems" of
July this year largely ignores the topic of key management.
Nist Pub 200-52  says the server cert gives assurance  'the server controls
the private key corresponding to the public key in the server's certificate'
but nothing else on this topic.

Lyal

-----Original Message-----
From: John Thompson [mailto: jwledt@xxxxxxxxxxx]
Sent: Wednesday, 7 September 2005 10:09 AM
To: 'Lyal Collins'; 'Lionel Ferette'; websecurity@xxxxxxxxxxxxx
Cc: 'Ryan Barnett'
Subject: RE: [WEB SECURITY] SSL Certs and FIPS 140-2 Compliance


I agree with you Lyal.  Multiple SSL Vendors have products or licensing
models to allow clients to install SSL certificates for a single common name
or URL onto multiple machines.

My own question is really directed along the lines of Ryan original question
which stated that to meet NIST's FIPS 140-2 compliance in their
organization, they could not use a single certificate on more than 1
physical server because according to FIPS, their private / shared / server
key for the SSL certificate for their site may not exist in more than 1
location.   I've never heard / read this before and so I'm really interested
in clarifying this statement.

I've searched through the documents I mentioned previously and could not
find mention of this situation.  Perhaps there are some Cavium, nCipher, or
Safenet employees on the list that could speak to this with authority but,
my own limited knowledge regarding SSL/TLS certificates and FIPS is that
issue is that the private key may not leave the "FIPS environment" in an
unencrypted form.  As long as the private key for the certificate in
question remains secure within the FIPS environment, you're okay.  As any
sales people for the companies I mentioned will tell you, they all have FIPS
compliant solutions that provide  FIPS compliant environments that allow the
same import / export / management of private keys within the FIPS
environment across multiple FIPS compliant devices.  And my understanding of
the import / export function on these devices is that it is a copy import /
copy export; the original file being imported or exported is not destroyed
on the original medium during the process.

Anyway, I'm really curious if anyone can reference a specific document
stating that in order to meet FIPS compliancy as a consumer/client of a FIPS
certified product that the private key for a specific keypair may only exist
in a single location on a single device at any specific point in time; or
stating the opposite.

I'm wondering if I'm missing something that's probably glaringly obvious or,
if it's not and the issue is that Ryan's Corporate Security Policy is what
is stating the Single Instance of an SSL cert in a FIPS environment, or if
maybe there's a miscommunication somewhere.  In any case, I'd love to hear
from someone who can speak authoritatively regarding this FIPS Compliancy
(One Location) Single Instance of a Private Key issue...

TIA



John

-----Original Message-----
From: Lyal Collins [mailto:lyal.collins@xxxxxxxxxxxxx ]
Sent: Tuesday, September 06, 2005 4:25 PM
To: 'John Thompson'; 'Lionel Ferette'; websecurity@xxxxxxxxxxxxx
Cc: 'Ryan Barnett'
Subject: RE: [WEB SECURITY] SSL Certs and FIPS 140-2 Compliance

Verisign's commercial SSL cert license/T&Cs allows an ssl cert to be used on
more than 1 machine, provided a second license is purchased. Given they at
least have an appearance of liability, I'm sure Verisign wouldn't license
something that could severely bite their liability fund.
I don't know if there is a 'Verisign for government' license which is any
different to this.

Fundamentally, SSL certs may be considered, in some cases, to verify
owenerhsip of the domain name, not the server/machine on which it resides.
What would be the point of preventing a smooth failover of a public-facing
site?

Lyal

-----Original Message-----
From: John Thompson [mailto: jwledt@xxxxxxxxxxx]
Sent: Wednesday, 7 September 2005 8:35 AM
To: 'Lionel Ferette'; websecurity@xxxxxxxxxxxxx
Cc: Ryan Barnett
Subject: RE: [WEB SECURITY] SSL Certs and FIPS 140-2 Compliance


Hello all!

I was just trying to find the document or paragraph that specifically states
that the private key for an SSL/TLS certificate may not exist in more than 1
physical location.  Does anyone on the list have that information?

I've read through "FIPS PUB 140-2 Security Requirements for Cryptographic
Modules" and "Implementation Guidance for FIPS PUB 140-2 and Cryptographic
Module Validation Program" and I could not find any references to:
Centralized Storage of Keys, Single Instance Storage of a Private or Secret
Key for a key pair OR certificate, Non-Duplication of Keys, etc...

Much appreciated.


John


-----Original Message-----
From: Lionel Ferette [mailto:lionel.ferette@xxxxxxxxx]
Sent: Monday, August 22, 2005 11:41 PM
To: websecurity@xxxxxxxxxxxxx
Cc: Ryan Barnett
Subject: Re: [WEB SECURITY] SSL Certs and FIPS 140-2 Compliance

Ryan, List, greetings!

In the wise words of Ryan Barnett, on Monday 22 August 2005 22:43:
> I am hoping that some other people on this list have some info on this
> area.  I will try and make it brief.
[SNIP Concise and precise description]

> The FIPS compliancy issue seems to be that the SSL signed cert and
> private key should only exist in one location - otherwise this
> violates the whole reuse of keys sections.  In this case, FIPS is
> making it difficult to leverage typical load-balancing
> implementations.
The way you describe it, I'm also afraid that the one location requirement
is not met, indeed.

> Has anyone else, who works with the government, run into a similar
> scenario?  The only option that we are kicking around is to implement
> some sort of hardware SSL accelerator on the network and consolidate
> our SSL functions on this host.
My own experience only relates to the banking sector, and the only solution
we found was to use a shared HSM, like nCipher's netHSM (which is FIPS 140-2
level 3 certified, incidentally). They don't come cheap, unfortunately, and
we had to drop their use for SSL. We used an HSM for the CA, though.

(Standard disclaimer: I'm not affiliated to nCipher, there are certainly
other products that perform the same function, but I have no first-hand
experience with them).

HTH,

Lionel

--
"To understand how progress failed to make our lives easier, please press 3"

Lionel Ferette
BELNET CERT Coordinator

Tel: +32 2 7903385                  http://cert.belnet.be/
Fax: +33 2 7903375                  PGP Key Id: 0x5662FD4B

---------------------------------------------------------------------
The Web Security Mailing List http://www.webappsec.org/lists/websecurity/

The Web Security Mailing List Archives
http://www.webappsec.org/lists/websecurity/archive/




---------------------------------------------------------------------
The Web Security Mailing List
http://www.webappsec.org/lists/websecurity/

The Web Security Mailing List Archives
http://www.webappsec.org/lists/websecurity/archive/

-- 
Ryan C. Barnett
Web Application Security Consortium (WASC) Member
CIS Apache Benchmark Project Lead
SANS Instructor: Securing Apache
GCIA, GCFA, GCIH, GSNA, GCUX, GSEC