Subject: Re: [AAA-WG]: Issue eap : Key Name AVP

From: Jari Arkko <[email-masked]>
Date: Wed, 21 Apr 2004 14:50:51 +0300

Hi Joe,

I'm going through the remaining issues
on Diameter EAP, and this was one of them.

I do see the point of being able to name a the MSK.
However, I would suggest that we define this AVP
in a separate document when there is a specific use
case and need for it, because I think adding it
to the Diameter EAP document creates some problems
for us (more on that below).

I would also note that we may need AMSK names, though
informing applications of them probably takes place through
some node-internal API rather than a AAA protocol.

About the problems that I mentioned:

o  I think its fine to say that the exact use of
    the name information is link layer dependent.
    I take it that this means the client side?
    But I feel uneasy about defining an attribute
    unless we also specify how the server fills
    in the information.

o  We can expect the EAP Keying Framework document
    to specify this, perhaps, but then we create
    a dependency from this document to the EAP
    Keying Framework, which is likely ready later
    than this document (and is Informational).

o  Current systems do not use the key name for
    anything.

o  As you point out, there is no corresponding
    RADIUS attributes. This would imply that all
    Diameter clients would have to prepare for the
    possibility that they don't get this attribute,
    in case the server was RADIUS. Likewise all
    servers would have to prepare for the possibility
    that their attribute is stripped off by a Diameter
    to RADIUS gateway. So it seems hard to even
    consider relying on this information.

Comments? Pasi, Bernard, do you have an opinion on
this?

--Jari

Joseph Salowey wrote:
> Submitter name: Joe Salowey 
> Submitter email address: [email-masked] 
> Date first submitted: 3/3/2004 
> Reference: 
> Document: eap 
> Comment type: T
> Priority: '1' Should fix 
> Section: 4.1
> Rationale/Explanation of issue: 
> 
> Since EAP keying has the concept of the key name this should probably be
> returned along with the Master Key. 
> 
> "4.1.5 EAP-Master-Session-Key-Name AVP
> 
> The EAP-Master-Session-Key-Name AVP (AVP Code TBD) is of type
> OctetString. It contains the name used to identify the
> EAP-Master-Session-Key.  Exactly how this name is used depends upon the
> link layer in question, and is beyond the scope of this document.  This
> AVP can optionally be present whenever an EAP-Master-Session-Key AVP is
> present.  
> 
> Since there currently are no standard RADIUS attribtues for key name
> this attribute does not translate to or from RADIUS in a standard way."

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 21 Apr 2004 06:35:41 -0700 (PDT)

>     unless we also specify how the server fills

While the use of the name information may be link layer dependent, the
name itself is not.  Since the name as defined in the EAP Key Framework is
dependent on the EAP method, the server obtains the name from the method.

>     than this document (and is Informational).

I don't think a dependency is created merely by including an AVP for the
name.

> o  Current systems do not use the key name for

Actually, IEEE 802.11i does use the key name.  However, the NAS can
calculate the relevant names from the keys themselves, so it doesn't need
it to be supplied by the AAA server.  So I think that the name is
only needed when it is requested by the NAS.

>     consider relying on this information.

I think that these issues can be addressed by only sending the name in
a Response when the NAS includes a name AVP in the Request.

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 21 Apr 2004 15:10:08 -0700 (PDT)

> No, it would be created by stating that the contents
> of the AVP must conform to the rules dictated in [REF].
> But I think what you are saying is that Diameter EAP
> states the name is obtained from the method, and
> then formal dependencies (if any) to EAP Keying Framework
> are in the methods. Is this correct?

Yes.  To Diameter EAP the name is just an opaque blob.

> I didn't think of it this way initially, but
> it looks like a nice way to avoid the dependency!

Good.

> Right. But if I understand this correctly, there'd
> be no NASes that would need this for current link
> layers -- of course this might change for future
> link layers or upgrades.

Yes.  So if the NAS doesn't ask, we don't send it.

> Or by sending the name in any case. Either way, the parties
> have to prepare for the possibility that you don't get the
> AVP even if you wanted it

Today's RADIUS NASen won't ask for a key name.  Therefore a
RADIUS/Diameter gateway won't send a Request with a Key-Name AVP and the
Diameter server won't send one.  So there is no compatibility problem
there.

A future Diameter NAS might or might not ask for a key name.  If it
doesn't ask, then there is no issue either with a Diameter Server or
a RADIUS server to whom it talks via a RADIUS/Diameter gateway.
If it asks for a key name, and it's talking to a Diameter Server, things
will work.  If it's talking to a RADIUS server and asks for a key name,
then the Diameter/RADIUS gateway would need a RADIUS key-name attribute to
translate to.  If there is no such attribute, then the key-name attribute
wouldn't be received.  But presumably for that case, the Diameter NAS
would need to be deployed along with compatible RADIUS servers.  So I
don't see an issue there either.

---

From: Jari Arkko <[email-masked]>
Date: Thu, 22 Apr 2004 00:44:51 +0300

> dependent on the EAP method, the server obtains the name from the method.

Ok.

> it to be supplied by the AAA server.  So I think that the name is

Right. So the name derived by the method (as specified
in EAP Keying) is currently not used, but another type
of name derivation is used in 802.11.

Or by sending the name in any case. Either way, the parties
have to prepare for the possibility that you don't get the
AVP even if you wanted to due to (a) translation to RADIUS
or (b) server not supporting key names. Of course, if its
just Diameter EAP, we can make this mandatory for servers
so that (b) is not an issue. RADIUS translation issue
could be handled by allocating the AVP from RADIUS space,
making it possible to send the name in RADIUS too. But
then we still have to allow for case (b) to happen,
as current servers may not support it.

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Thu, 22 Apr 2004 14:21:47 +0300

> Diameter server won't send one.  So there is no compatibility problem

Right.

> a RADIUS server to whom it talks via a RADIUS/Diameter gateway.

Yes.

> don't see an issue there either.

You are right. I guess my question at this point is whether
Diameter EAP needs to allocate the name AVP from the Diameter
or RADIUS space. It seems like it should be allocated from
the RADIUS space, so that translation the "compatible RADIUS
server" has a standard attribute to use on the RADIUS side.

If you and others agree, I think this results in the following
modifications of Diameter EAP:

1. Add a key name AVP section
2. Make it appear 0-1 times in both the request and response.
3. Explain that the server should return the AVP in response
    if it was present in the request.
4. Explain that the contents come from EAP methods (add
    informative reference to EAP keying).
5. Use a RADIUS number space for the attribute number.

--Jari

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 22 Apr 2004 07:48:48 -0700 (PDT)

> 5. Use a RADIUS number space for the attribute number.

Yes, I think this will work.