 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
|
Bernard Aboba [mailto://bernard_aboba at hotmail.com]
writes: 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. 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. 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. |