Subject: [Dime] Problem with draft-wu-dime-local-keytran

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 9 Nov 2009 17:01:07 -0800

I have reviewed draft-wu-dime-local-keytran and found an issue with it. 

The document utilizes an existing RADIUS attribute (EAP-Key-Name) within a
Diameter Grouped AVP.   According to the value of the EAP-Key-Type AVP,

the type of key being sent (and therefore the EAP-Key-Name) will change. 

Unfortunately, this usage is incompatible with the definition of the
EAP-Key-Name in RFC 4072.  RFC 4072 Section 4.1.4 notes:

   The EAP-Key-Name AVP (Radius Attribute Type 102) 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).

As noted in RFC 5247 Section 5.9, the EAP-Key-Name attribute contains the
EAP-Session-Id, and followon standards such 

as IEEE 802.1X-REV depend on this attribute in order to obtain the
EAP-Sesssion-Id utilized in subsequent cryptographic

calculations.   

My concerns about this usage include:

a.       The inclusion of an existing RADIUS attribute within a Diameter
Grouped AVP, thereby changing their meaning.  The usage of grouping with
existing RADIUS attributes has been discussed and rejected in RADEXT as part
of the Extended Attributes work, due to concerns about backward
compatibility.   This document therefore represents an attempt to get around
an objection raised in RADEXT via submission of a document in DIME. 

b.      The updating of RFC 5247 by a non-standards track document in a WG
that has no charter to revise EAP standards track documents. 

c.       Conflicts between this document and work items on the RADEXT WG
charter requested by IEEE 802.1 and referred to in the appendix of IEEE
802.1X-REV.

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 11 Nov 2009 11:41:03 +0900

Bernard Aboba  <mailto:[mailto://[email-masked]%5d>
[mailto://[email-masked]] writes:

calculations.   

I'm afraid that you are mistaken about this: I'm quite certain that the last
thing anyone wants is to extend the RADIUS protocol in any IETF WG.  In
particular, I have absolutely no interest in any further work on RADIUS:
it's dead, and radext is just hammering the final few nails in the coffin.
In any case, no problem: it was pointed out in yesterday's dime session that
to prefix the AVP names in our draft with "EAP-" is entirely too limiting.
Therefore, we will be changing the names and not re-using the Diameter AVP
in question.