Subject: [eap] [eap]: questions on AAA key management draft

From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
Date: Thu, 27 Oct 2005 17:06:20 -0400

Hi,

I just spent a bit of time going through the AAA key management draft
(V00) and have the following comments.

First of all I appreciate Bernard and Russ providing guidance for the
community and am wondering if there is a plan for sequels? And I don't
know which WG this draft was targeted for? AAA WG maybe? And I apologize
if I don't have the history on this draft. I am drawing parallels
between this draft and EAP keying drafts based on the following (may
that is not the intention).

The draft provides a lot of history for why EAP came about, and talks
about combination of EAP and RADIUS, as well as EAP methods and post EAP
handshakes, it does sort of confirm the impression that it wants to talk
about key management using EAP and AAA protocols. However, I think the
following would lead to improvement

1)the draft could be more clear when it deals with a AAA process and
when it deals with an EAP process

1a)Initially picking up the draft with excitement I thought the draft is
talking about management of THE "AAA-key" produced as a result of EAP
process (sort of what EAP key management draft is defining). Ironically
that is the first thing that is sort of confusing. So "AAA assisted key
management" might be a good alternative!?

1b) distinction between EAP server and AAA server. Distinction between
what is done by AAA protocol and what is done by EAP. For instance:

1c) It talks about key caching but it would be nice if it included where
keys should or should not be cached (AAA server, AAA client, EAP
authenticator, EAP server etc.) Some of this is covered in EAP RFCs or
the new keying drafts, but others are not, simply because RADIUS RFCs
where written before EAP ones. It is becoming harder and harder to find
a one-stop shop for advice or spec to find the rules or point people to
in debates. Even then a lot of hair splitting between various documents
is required.

1d) "replay detection mechanism: AAA key mgmt protocol exchanges MUST be
replay protected" Is the draft proposing ways to fix AAA (RADIUS or
Diameter) messaging? EAP messaging? Or only attributes that deal with
key management, I would think the latter.

Other comments:

2) Not initially very clear what is meant by "session keys" in "strong,
fresh requirement", I am assuming we mean keys that are produced as part
of session association protocol (SAP), since the subsection later talks
about post-EAP handshakes. However, one paragraph does talk about keys
derived by EAP methods, so not sure if MSK, EMSK, AAA key needs to be
fresh, or Tasks or all. Given that the draft recognizes the definition
of SAP, using both SAP and post-EAP handshake can be pretty confusing.

3) More guidance on key scope is appreciated. For instance the scope of
key is defined by using the "least privilege" principle. From the point
of key derivation (who has the master key and the material to derive
further keys), I think this is clear to some extent, but since this
document advertises as providing guidance for AAA-based key management,
I think guidance on how it is possible (or not) for the AAA
infrastructure to control the key scope is useful. I have combing
through a lot of EAP keying material in the past year, I still have not
understood how much control the AAA server can exert on the key scope
and hierarchy (who can create what key from what, is AAA server aware of
SAP? Should it be?)

4) Key material confidentiality: Is nonce not considered as keying
material. If SAP (or post-EAP handshake) uses nonces, I did not think
they did not need to stay confidential? 

My final but not least important comment is that a lot of SDOs are
starting to use AAA key management mechanisms (using your terminology)
to provide security for mobile environments and in the absence of clear
guidance are creating a number of procedures that this very draft is
stating to want to avoid. Would it not really be helpful if this draft
provided more guidance for this densely populated category of people?
i.e. guidance on how to do use AAA-based key management mechanisms to
support handovers?

For instance it is not clear from the draft and its 
 "prevention of Domino effect/ keying material confidentiality"
requirements whether
 context transfer of keying material from one authenticator to the next
for support of fast mobility ruled out?
Would we violate principle of least privilege even though we only move
MSK between authenticator? Or the post EAP keys between BSs (consider
802.16 model).

Thanks,

Madjid Nakhjiri
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 27 Oct 2005 16:10:30 -0700

>know which WG this draft was targeted for? AAA WG maybe?

The document was intended to provide guidance for the IETF as a whole,
though it originated from a talk that Russ gave in the AAA WG at IETF 56.

>I am drawing parallels

At the point when Russ gave his talk at IETF 56, no IETF specification
involving AAA-based key management had ever been approved for publication
as an IETF Proposed Standard, though many had tried.  Therefore one of the
key questions that we were trying to answer was "What is the bar for
AAA-based key management proposals seeking approval?"

The "AAA Key Management" document attempts to describe the requirements
that specifications need to meet in order to be published as IETF Proposed
Standards.

Since the requirements are generic, they apply to the EAP Key Framework
document as well as any other document.  Specifically, in order to enable
its publication, the EAP Key Framework document needs to demonstrate that
EAP, along with AAA and Secure Association Protocols, can meet the
requirements described in the document.

Note that the details of that proof are out of scope of the "AAA Key
Management Requirements" document, but very  much in scope for the EAP Key
Framework document.

---

From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
Date: Fri, 28 Oct 2005 16:20:56 -0400

Hi Bernard, 

Please see inlines,

Regards,

Madjid

<snip>
At the point when Russ gave his talk at IETF 56, no IETF specification
involving AAA-based key management had ever been approved for
publication as an IETF Proposed Standard, though many had tried.
Therefore one of the key questions that we were trying to answer was
"What is the bar for AAA-based key management proposals seeking
approval?"  

Madjid>>I think with the EAP keying going on standards track, the bar
must have been raised, no? So where do we stand now?

The "AAA Key Management" document attempts to describe the requirements
that specifications need to meet in order to be published as IETF
Proposed Standards. 

Since the requirements are generic, they apply to the EAP Key Framework
document as well as any other document.  Specifically, in order to
enable its publication, the EAP Key Framework document needs to
demonstrate that EAP, along with AAA and Secure Association Protocols,
can meet the requirements described in the document. 

Madjid>> Makes sense. However, do you agree with the points on the needs
for further clarification as I raised in my email. I understand that
Russ and yourself are busy, is it possible to provide revisions with
more clarifications? I can volunteer for help if needed.

Note that the details of that proof are out of scope of the "AAA Key
Management Requirements" document, but very  much in scope for the EAP
Key Framework document.

Madjid>> agreed.