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

From: Xueli <[email-masked]>
Date: Tue, 8 Jul 2014 02:21:42 +0000

Hello all

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.

In practice, operators prefer to deploy BNG as Authenticator while AC is as much as simple for AP management.
In this scenario, an standard approach is required to help the WTP to obtain the PMK, especially, when AC and BNG are deployed by different vendors.. 
This work tries to discuss the issues related with this topic and proposes a RADIUS extension to address the problem.
As before we discussed in the meeting, the scenario is already clear and reasonable. 

Now the argument is that whether this item is the genuine Radius/RADEXT problem? 
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)
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?

Thanks in advance

Li On co-authors' behalf

---

From: Alan DeKok <[email-masked]>
Date: Mon, 07 Jul 2014 22:31:50 -0400

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

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

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

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 7 Jul 2014 21:15:28 -0700

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" <[email-masked]> wrote:
> 
> Xueli wrote:
> _______________________________________________
> radext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/radext

---

From: Sam Hartman <[email-masked]>
Date: Tue, 08 Jul 2014 08:01:59 -0400

>>>>> "Xueli" == Xueli  <[email-masked]> writes:

    Xueli> Hello all As you know, we presented the
    Xueli> draft-xue-radext-key-management (new version
    Xueli> http://tools.ietf.org/id/draft-xue-radext-key-management-03.txt
    Xueli> ) Which defines the Radius extensions for key delivery
    Xueli> between BNG and AC in some specific scenario.

    Xueli> In practice, operators prefer to deploy BNG as Authenticator
    Xueli> while AC is as much as simple for AP management.  As before
    Xueli> we discussed in the meeting,
    Xueli> the scenario is already clear and reasonable.

With respect, when I consider this scenario I find myself confused and
I'm hoping that if you decide  to continue this  work you will spend
significantly more effort clarifying the scenario and working with the
community to evaluate whether it is reasonable.

As I understand it, operators would like to deploy with a model
different than that described by RFC 5247.  We spent a long time
developing RFC 5247, working within the IETF to make sure our protocols
support it, and working within the IEEE to make sure that their
re-authentication and other protocols work within this model.

When we hear that work is wrong, we feel skeptical

Also, when I read this document I am concerned, because the security
model is different than that proposed by RFC 5247.  I do not wish to see
the security of wireless access decreased, and I'd like to understand
whether this proposed solution  does that.

I would request that you:

* Approach this as an architectural issue at the RFC 5247 level rather
  than a RADIUS issue

* Focus on clearly describing the scenario and having a discussion with
  the IETF community about whether this scenario is reasonable.

* Discuss with the IETF community about whether a solution to this
  scenario is desirable.

This is a much bigger change than one RADIUS attribute.

Thanks for your consideration,

Sam Hartman
Painless Security, LLC

---

From: Xueli <[email-masked]>
Date: Wed, 9 Jul 2014 02:06:14 +0000

Hello Alan

Thanks for your comments.

>> At this stage, the authors appreciate your opinions very much for the

>next step of this draft.

Understand..

This scenario is the existing gap right now in WLAN network, also mentioned in other SDO.

We will think carefully this security issue.

Regards

Li

>-----Original Message-----

>From: radext [mailto:[email-masked]] On Behalf Of Alan DeKok

>Sent: Tuesday, July 08, 2014 10:32 AM

>To: Xueli

>Cc: [email-masked]

>Subject: Re: [radext] Gathering opinions on

>draft-xue-radext-key-management

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

>> Now the argument is that whether this item is the genuine

>Radius/RADEXT problem?

>> Radius packet is proposed to resolve this issue because of following

>reasons:

>> (Key, which is produced during authentication and delivered by Radius

>from Server to NAS)

>> At this stage, the authors appreciate your opinions very much for the

>next step of this draft.

---

From: Xueli <[email-masked]>
Date: Wed, 9 Jul 2014 02:07:48 +0000

Thanks

>From: Bernard Aboba [mailto:[email-masked]]

>Sent: Tuesday, July 08, 2014 12:15 PM

>To: Alan DeKok

>Cc: Xueli; [email-masked]

>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" <[email-masked]>

>wrote:

>> them, and performing accounting for them.  If you want a general

>purpose

---

From: Xueli <[email-masked]>
Date: Wed, 9 Jul 2014 02:12:02 +0000

Hi Sam

I appreciate it.. Make sense to me..

Thanks

Regards

Li