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