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

[Alan DeKok <[e-mail]>]

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.