Subject: [AAA-WG]: Issue 465: Key Naming

From: Bernard Aboba <[email-masked]>
Date: Mon, 5 Jul 2004 18:04:57 -0700 (PDT)

I'm opening Issue 465 for residual issues relating to Diameter EAP Key
naming.

In reading Diameter EAP-08,  Section 4.1.4 says:

"   The EAP-Key-Name AVP (AVP Code TBD-BY-IANA) is of type OctetString.
   It contains an opaque key identifier (name) generated by the EAP
   method.  Exactly how this name is used depends on the link layer in
   question, and is beyond the scope of this document (see [EAPKey] for
   more discussion).

   It should be noted that not all link layers use this name, and
   currently most EAP methods do not generate it.  The home Diameter
   server SHOULD include this AVP in Diameter-EAP-Response only if an
   empty EAP-Key-Name AVP was present in Diameter-EAP-Request."

The question is what happens if the EAP-Key-Name AVP sent in a
Diameter-EAP-Request is non-null.

I'd suggest that the second paragraph should be changed to say:

"It should be noted that not all link layers use this name, and
currently most EAP methods do not generate it. Since the NAS
operates in pass-through, it cannot know the Key-Name before
receving it from the AAA server. As a result, a Key-Name
AVP sent in a Diameter-EAP-Request MUST not contain any data.
A home Diameter server receiving a Diameter-EAP-Request
with a Key-Name AVP with non-null data MUST silently
discard the AVP. In addition, the home Diameter
server SHOULD include this AVP in Diameter-EAP-Response only if an
EAP-Key-Name AVP with non-null data was present in Diameter-EAP-Request."

Jari Arkko said:

"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."

---

From: Jari Arkko <[email-masked]>
Date: Tue, 06 Jul 2004 08:44:17 +0300

> EAP-Key-Name AVP with non-null data was present in Diameter-EAP-Request."
                         ^^^^^^^^

I think you meant "null" above? Or I need more coffee this morning...

Otherwise I think the resolution is OK.

--Jari

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 6 Jul 2004 08:04:17 -0700 (PDT)

> I think you meant "null" above? Or I need more coffee this morning...

You are correct.  I think it's me who needs the additional coffee...