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

"Glen Zorn" <gwz@net-zen.net> Wed, 11 November 2009 02:40 UTC

From: Glen Zorn <gwz@net-zen.net>
To: 'Bernard Aboba' <bernard_aboba@hotmail.com>
References: <BLU137-DS21174249DD354E73295D993AB0@phx.gbl>
In-Reply-To: <BLU137-DS21174249DD354E73295D993AB0@phx.gbl>
Date: Wed, 11 Nov 2009 11:41:03 +0900
Organization: Network Zen
Message-ID: <000601ca6278$6af2e020$40d8a060$@net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CA62C3.DADA8820"
Thread-Index: AcphoUk7/yU7tggjQrSam6FoJtYnKwA1L0oA
Content-Language: en-us
Cc: dime@ietf.org, 'radext mailing list' <radiusext@ops.ietf.org>
Subject: Re: [Dime] Problem with draft-wu-dime-local-keytran
Precedence: list

Bernard Aboba  <mailto:[mailto://bernard_aboba@hotmail.com%5d>
[mailto://bernard_aboba@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.

[Dime] Problem with draft-wu-dime-local-keytran Bernard Aboba
Re: [Dime] Problem with draft-wu-dime-local-keytr… Glen Zorn