Assurance

[Brian Arkills <>]

I was lost in this same maze of "Approved Algorithms" last week. After following a bunch of links, I ended up thinking that the approved list was the FIPS 140-1/140-2 list, although I didn't figure out which of the security levels within the FIPS program mapped to what.

 

My interest was to verify the commonly held belief that the algorithms Active Directory uses are not in the Approved Algorithms list, as I had been assuming.

 

So your alternate conclusion is interesting. I'm very interested to hear what the guidance is here on what the "Approved Algorithms" are for the various sections in the IAP that reference that.

 

From: [mailto:] On Behalf Of Capehart,Jeffrey D
Sent: Monday, February 25, 2013 12:43 PM
To:
Subject: [Assurance] Question on Protected Channel - SSL/TLS

 

So, what level of testing do you think is necessary to validate that a Protected Channel is used?

 

Per the v1.2 IAAF, typical SSL/TLS should provide the protections.  Take a look over these steps and decide… where would you stop … how much assurance would you have that the channel is protected using NIST approved encryption?  What would you consider “typical”?

 

POTENTIAL AUDIT TESTS:

1)      Look in the browser and make sure the address is HTTPS: and the lock is enabled.  DONE?

2)      Right click properties/View Page Info and see that:

a.       “Connection Partially Encrypted”

b.      “Connection Encrypted” (IS THIS GOOD ENOUGH?)

c.       “TLS 1.0, RC4 with 128 bit encryption (High); RSA with 2048 bit exchange” (HOW ABOUT THIS ONE)

d.       “High Grade Encryption – AES-128” is used.

3)      Click on the Certificate and view that Version is 3.0, Signature Algorithm is sha1RSA, and RSA Key is 2048 bits (GOOD ENOUGH YET?)

4)      Request a list of supported ciphers from IT on the particular servers/routers and ensure only NIST Approved ciphers are used.

 

Supporting information:

Protected Channels appear in the following InCommon Silver v1.2 requirements (4.2.2.1; 4.2.5.3; 4.2.7.3; 4.2.8.2)

The IAAF defines a Protected Channel as:

The security of communications between system components (IdP, IdMS, Verifier, etc.) is

important. A Protected Channel uses cryptographic methods that implement an Approved

Algorithm to provide integrity and confidentiality protection, resistance to replay and man in-

the-middle attacks, and mutual authentication. For example, typical SSL/TLS

implementations provide these protections.

 

NIST SP800-52 lists the cipher suites that should be supported.  Therefore those should meet the NIST Approved Algorithm requirement. Refer to tables 2 and 3 on pages 22-23. (Table 3 included FYI)

 

This cipher is on the client table, but not on the server table.  There is a footnote related to it for non-government usage where an exception is made for it to be OK.  Since Universities are not the Federal Government, does that make it OK to use per the exemption?

  cipher RSA_WITH_RC4_128_SHA

 

Cited reference material from IAP v1.2:

 

4.2.2.1 (S) RA AUTHENTICATION

Communications between an RA and the IdMS shall be encrypted using an Approved

Algorithm that also authenticates the IdMS platform.

4.2.5.3 (S) (B) SECURE COMMUNICATION

Communication between Subject and IdP must use a Protected Channel.

4.2.7.3 (S) (B) CRYPTOGRAPHIC SECURITY

Cryptographic operations are required between an IdP and any SP. Cryptographic

operations shall use Approved Algorithms. […] using a Protected Channel.

4.2.8.2 (S) NETWORK SECURITY

1. Appropriate measures shall be used to protect the confidentiality and integrity of

network communications supporting IdMS operations. Protected Channels should

be used for communications between systems.

 

 

Cited reference material from NIST SP800-52:

Guidelines for the Selection and Use of Transport Layer Security (TLS) Implementations

5.2 Server Considerations

Cipher Suites

Although the client may present the cipher suites that it prefers in order of descending preference, the server generally does not defer to the client’s preferred cipher suite. The server may, at its choosing, select a common cipher suite that it prefers. The following table (Table 3) represents the cipher suites that a TLS server implementation should support. This table presents the cipher suites in order of descending preference.

Table 3: Recommended Server Cipher Suites24Cipher Suite	Auth	Key Establishment	Encryption	Digest
TLS_DHE_DSS_WITH_AES_256_CBC_SHA	DSS	DHE	AES_256_CBC	SHA-1
TLS_DHE_RSA_WITH_AES_256_CBC_SHA	RSA	DHE	AES_256_CBC	SHA-1
TLS_RSA_WITH_AES_256_CBC_SHA	RSA	RSA	AES_256_CBC	SHA-1
TLS_DH_DSS_WITH_AES_256_CBC_SHA	DSS	DH	AES_256_CBC	SHA-1
TLS_DH_RSA_WITH_AES_256_CBC_SHA	RSA	DH	AES_256_CBC	SHA-1
TLS_DHE_DSS_WITH_AES_128_CBC_SHA	DSS	DHE	AES_128_CBC	SHA-1
TLS_DHE_RSA_WITH_AES_128_CBC_SHA	RSA	DHE	AES_128_CBC	SHA-1
TLS_RSA_WITH_AES_128_CBC_SHA	RSA	RSA	AES_128_CBC	SHA-1
TLS_DH_DSS_WITH_AES_128_CBC_SHA	DSS	DH	AES_128_CBC	SHA-1
TLS_DH_RSA_WITH_AES_128_CBC_SHA	RSA	DH	AES_128_CBC	SHA-1
TLS_DHE_DSS_WITH_AES_256_CBC_SHA	DSS	DHE	AES_256_CBC	SHA-1
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA	DSS	DHE	3DES_EDE_CBC	SHA-1
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA	RSA	DHE	3DES_EDE_CBC	SHA-1
TLS_RSA_WITH_3DES_EDE_CBC_SHA	RSA	RSA	3DES_EDE_CBC	SHA-1
TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA	DSS	DH	3DES_EDE_CBC	SHA-1
TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA	RSA	DH	3DES_EDE_CBC	SHA-1

 

 

 

Jeff Capehart, CISA
IT Audit Manager
University of Florida - Office of Internal Audit
(352) 273-1882

http://oia.ufl.edu