Re: [radext] Gathering opinions on draft-xue-radext-key-management

RFC 5247 provides the Key Management model for EAP. It is standards track - and updates are outside the Charter of RADEXT WG.

> On Jul 7, 2014, at 7:32 PM, "Alan DeKok" <aland@deployingradius.com> wrote:
> 
> Xueli wrote:
>> As you know, we presented the draft-xue-radext-key-management (new version http://tools.ietf.org/id/draft-xue-radext-key-management-03.txt  )
>> Which defines the Radius extensions for key delivery between BNG and AC in some specific scenario.
> 
>  I think the general consensus was that this was outside of the scope
> of RADIUS.
> 
>> Now the argument is that whether this item is the genuine Radius/RADEXT problem?
> 
>  RADIUS is usually about end-users.  Authenticating them, authorizing
> them, and performing accounting for them.  If you want a general purpose
> "remote API" protocol, see Diameter.
> 
>> Radius packet is proposed to resolve this issue because of following reasons:
>> 1 transmit session authorization attributes
>> (Key, which is produced during authentication and delivered by Radius from Server to NAS)
> 
>  If the key is transmitted between a RADIUS client and server, then the
> transmission can be done as part of a normal RADIUS conversation.  If
> the key is transmitted somewhere else, then that's a *huge* security
> problem.  And it doesn't fit the standard RADIUS model.
> 
>> 2 unsolicited messages 
>> 3 It is not the issue of Radius, it may be the issue of EAP over Radius..
>> 
>> At this stage, the authors appreciate your opinions very much for the next step of this draft.
>> Can it be solved in RADEXT? If not, which WG could be the place?
> 
>  I think this proposal would have a hard time finding traction anywhere
> in the IETF.  The security problems with sharing keys are very serious.
> 
>  Alan DeKok.
> 
> _______________________________________________
> radext mailing list
> radext@ietf.org
> https://www.ietf.org/mailman/listinfo/radext