<font size=2 face="sans-serif">Hi Martin,</font>
<br>
<br><font size=3 face="Times New Roman">Relative to our prior questions
on NIST SP 800-131a compliance, your prior answer basically said to use
the connection configuration definition to specify compliant algorithms
and to use compliant certificates for authentication which we understand
and agree with, but there is a bit more to the standard. Here are a few
more questions:</font>
<br><font size=3 face="Times New Roman"><br>
1. Does strongSwan inherently use any cryptographic functions for any reason
that are not controlled through the connection configuration definition?<br>
2. SP 800-131a refers to SP 800-90A for DRNG (PRNG) algorithms which refers
to SP 800-90B for entropy sources and SP 800-90C for DRNG construction
with SP 800-90A and SP 800-90B   definitions.<br>
  a. Is the PRNG in your default cryptographic library compliant with
these standards?<br>
  b. What is the entropy source for your PRNG and do you manage the
PRNG per these standards requirements?<br>
3. SP 800-131a's definition implies the use of TLS 1.2 interfaces. Do you
know of any reason we cannot configure a connection with this protocol?
<br>
4. We are running on StrongSwan 4.6.1. Do you know of any limitations of
this level relative to this discussion? <br>
5. I am not particularly expert on your connection configuration files,
and I am wondering whether this file lets you control things such the TLS
level and the mechanism for key exchange. I see there lists of these in
the StrongSwan.Config and that you can over-ride this. Is this where you
would effect this level of control? For example, say we wanted to limit
all connections to TLS 1.2 or say we wanted to limit a specific connection
to TLS 1.2 but allow other connections to use TLS 1.2 or lower levels of
TLS? </font>
<br><font size=2 face="sans-serif"><br>
Regards,</font>
<br><font size=2 face="sans-serif"><br>
Dale</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">From:</font>
<td><font size=1 face="sans-serif">Martin Willi <martin@strongswan.org></font>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">To:</font>
<td><font size=1 face="sans-serif">Dale H Anderson/Tucson/IBM@IBMUS</font>
<tr>
<td valign=top><font size=1 color=#5f5f5f face="sans-serif">Cc:</font>
<td><font size=1 face="sans-serif">dev@lists.strongswan.org</font>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">Date:</font>
<td><font size=1 face="sans-serif">01/16/2013 01:37 AM</font>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">Subject:</font>
<td><font size=1 face="sans-serif">Re: [strongSwan-dev] NIST SP800-131a</font></table>
<br>
<hr noshade>
<br>
<br>
<br><tt><font size=2>Hi Dale,<br>
<br>
> 1. Does strongSwan 4.6.1 comply with NIST SP800-131a?<br>
<br>
I haven't read that spec in detail, but it seems that it just defines<br>
algorithms and key lengths to use for "acceptable" operation.<br>
<br>
strongSwan can support many of these algorithms and key lengths, it's<br>
just a matter of configuration. Make sure to define the algorithms you<br>
require in your connections in the "esp" and "ike"
proposal keywords,<br>
and append a '!' to disable others (man ipsec.conf for details).<br>
<br>
If you are using certificates, generate the the keys with appropriate<br>
key length and sign the certificates with the required hashing<br>
algorithms.<br>
<br>
So yes, it should be possible to configure strongSwan for NIST<br>
SP800-131a compliance (but it is also possible to configure it to<br>
violate this spec).<br>
<br>
> If the answer is no to all three questions, then we will look into
using <br>
> the OpenSSL or libgcrypt routines with strongSwan.<br>
<br>
I don't think that the selection of the crypto backend matters, you can<br>
use weak algorithms or key lengths with any backend.<br>
<br>
Regards<br>
Martin<br>
<br>
</font></tt>
<br>
<br>