Subject: Re: Last Call: 'Guidance for AAA Key management' to BCP (draft-housley-aaa-key-mgmt)

From: Bernard Aboba <[email-masked]>
Date: Wed, 8 Nov 2006 14:00:14 -0800 (PST)

I believe that the document will have implications for the RADIUS 
protocol.  For example, during the RADEXT WG meeting at IETF 67, we 
discussed the need for crypto-agility in RADIUS, and the current lack of 
ability to negotiate cryptographic algorithms.  This is why Crypto-agility 
was added as a RADEXT WG work item. 

Since Diameter already supports cryptographic algorithm negotiation, I do 
not believe that crypto-agility is an issue there. 

My reading of the document is that it does not impose any security 
requirements on EAP methods beyond those described in RFC 4017 and RFC 
3748.  At least that is what is being assumed in the EAP Key Management 
Framework document, which cites RFC 4017 and RFC 3748 as meeting the 
requirements. 

I think that the term 'AAA key management' applies to situations which 
involve use of AAA for derivation or transport of keying material.  In the 
case of EAP, that would include EAP methods, AAA protocols as well as the 
SAP.  

1. I do think that SAP designers are an audience, particularly since that 
work often occurs outside of IETF. 

2. The AAA protocol does play a role in freshness, because it can support 
replay protection, preventing the same key transport message from being 
replayed, thereby introducing stale keys.  

3.  I think that "authentication of all parties" is distinct from context 
binding, although it is certainly a pre-requisite for it.  Without 
defining the parties to the key management exchange and authenticating 
them, it is not possible to protect against key usage outside of the 
authorized scope. 

4. Agree that integrity should also be called out. 

5. There are vulnerabilities associated with the 802.11i key naming 
scheme.  For example, I believe that PSK cracking tools have been built 
that perform offline dictionary attacks on the 802.11i key names.  
EAP methods satisfying RFC 4017 criteria are not vulnerable, but I do 
think it illustrates the potential dangers.  The problem is fixed in 
802.11r. 

6. I believe this section applies to binding within all phases, including 
AAA, EAP and SAP.  Generally AAA integrity protection mechanisms should 
satisfy the binding requirements (or at least that is what is assumed in 
the EAP Key Management Framework document).  For EAP, the requirements are 
met by RFC 4017 requirements (including Channel Binding support).  So in 
practice the issue has mostly arisen within SAP designs, some of which 
have not properly handled key scoping and binding.  For example, within 
IEEE 802.11i, the authenticator is not identified, only the port/BSSID so 
that the peer cannot properly determine the authenticator key scope.  This 
is also fixed in 802.11r. 

7.  I think some clarification may be needed here.  As stated in the EAP 
Key Management Framework document, the authenticator and AAA client are 
always co-located (though these entities may both be distributed as in 
some CAPWAP architectures). 

-----------------------------------------------------------------
Hi Russ and Bernard,

I'm not really clear on the purpose of the document.  What does it apply
to?  Does it require changes to existing AAA protocols? Does it add new
requirements to EAP methods that are not in RFC3748? It would probably
be good to reference 3748 when it applies to a requirement in this
document (such as replay protection, strong fresh session keys, etc.).

What does AAA key management protocol refer to?  Is it the combination
of EAP, AAA and Security Association Protocol?  

A few comments on this document

1. Section 3 states "This section provides guidance to AAA protocol
designers and EAP method designers."

This should include designers of "security association protocols" as
well since many of the requirements apply to them.

2. Strong fresh session keys

In this section it is not clear what the subject session keys are.  It
is not clear to me what role the AAA protocol plays in "ensure that the
keying material supplied as an input to session key derivation is fresh"

Also wouldn't key caching be relevant on the EAP server rather than the
"AAA server"?

3.  Authenticate all parties

What is the AAA key management protocol?  It seems that some of this
section is about validating keys are used within they correct context
and not necessarily authentication.  Maybe part of this section should
belong with the context binding section. 

4. Keying material confidentiality

It seems that a system should also preserve key material integrity
(perhaps this is assumed in confidentiality). 

5. Unique Key Names

This section states "the key name MUST NOT be based on the keying
material itself." 802.11i uses this technique; are there vulnerabilities
associated with this?  

6. Bind key to its context

In this section it is not clear what the "protocol" is or how the
binding would occur.  What is meant by "The manner in which the keying
material is expected to be used." 
 
7. Security considerations

The first paragraph is difficult to understand.  It seems to be stating
that the authenticator can be separated from a AAA client as long as the
context of the request is communicated correctly between parties. Is
this it? 

Joe

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 8 Nov 2006 23:50:08 -0500

> case of EAP, that would include EAP methods, AAA protocols as well as the 

Does 'AAA key management' protocol also include EAP lower layer
protocols such as 802.1X, PANA and IKEv2?

Yoshihiro Ohba

---

From: Sam Hartman <[email-masked]>
Date: Thu, 09 Nov 2006 11:15:17 -0500

>>>>> "Yoshihiro" == Yoshihiro Ohba <[email-masked]> writes:

    Yoshihiro> On Wed, Nov 08, 2006 at 02:00:14PM -0800, Bernard Aboba
    Yoshihiro> wrote:
    >> I believe that the document will have implications for the
    >> RADIUS protocol.  For example, during the RADEXT WG meeting at
    >> IETF 67, we discussed the need for crypto-agility in RADIUS,
    >> and the current lack of ability to negotiate cryptographic
    >> algorithms.  This is why Crypto-agility was added as a RADEXT
    >> WG work item.
    >> 
    >> Since Diameter already supports cryptographic algorithm
    >> negotiation, I do not believe that crypto-agility is an issue
    >> there.
    >> 
    >> My reading of the document is that it does not impose any
    >> security requirements on EAP methods beyond those described in
    >> RFC 4017 and RFC 3748.  At least that is what is being assumed
    >> in the EAP Key Management Framework document, which cites RFC
    >> 4017 and RFC 3748 as meeting the requirements.
    >> 
    >> I think that the term 'AAA key management' applies to
    >> situations which involve use of AAA for derivation or transport
    >> of keying material.  In the case of EAP, that would include EAP
    >> methods, AAA protocols as well as the SAP.

    Yoshihiro> Does 'AAA key management' protocol also include EAP
    Yoshihiro> lower layer protocols such as 802.1X, PANA and IKEv2?

Yes.