Subject: Re: draft-zorn-radius-pkmv1-05.txt

From: Bernard Aboba <[email-masked]>
Date: Wed, 26 Aug 2009 09:50:33 -0700

Donald Eastlake said:

"Doing a little more research, 802.16e-2005, which 

you don't reference, does begin to touch on this by at least 

specifying how EAP fits into 802.16."

[BA] As I understand it, this document is focused entirely on
PKMv1, which does not support EAP.  So it does not apply to
IEEE 802.16e-2005.  That's quite an important point, since
there are existing specifications (from WiMAX forum) that 
deal extensively with IEEE 802.16e/AAA interactions. 

If that point is not very clear from the document, then it needs
to be. 

[Donald Eastlake]

If above you are saying that the security of these new RADIUS 

attributes can be evaluated entirely based on a knowledge of RADIUS, I 

do not agree with this. 

[BA]

PKMv1 has some fairly serious security problems that are described here:
http://www2.computer.org/portal/web/csdl/doi/10.1109/SNPD.2008.138

So I think the question is whether this document can make those serious
security problems even worse, in a way that has not already been 
documented. 

I'd suggest that the document reference the known security
issues that are covered in other documents, such as the ones above and
others (such as RFC 3579) that describe weaknesses in the MPPE-Key
attributes. 

[Donald Eastlake]

If above, you are saying is that there is no 

need for there to be some explanation, in your draft or in some 

document referenced by it, of how RADIUS fits into 802.16 and that 

people who don't have an a priori knowledge of this should just keep 

their noses out of your document, I don't agree with that either. 

[BA]  I would suggest that the document could reference the
RADIUS specifications from WiMAX forum that relate
to IEEE 802.16e-2005 to make it clear that operation with
that updated specification is out of scope. 

[Donald Eastlake]

"RADIUS can be used by an IEEE 802.16 Base Station, acting as an EAP 

Authenticator, to communicate with a remote Authentication Server to 

authenticate 802.16 Subscriber Stations and support 802.16 Privacy Key 

Management Version 1. This document defines a set of additional RADIUS 

Attributes which are designed to enable this support." 

[BA] Since PKMv1 does not support EAP, mentioning EAP in the abstract
doesn't make sense. 

[Donald Eastlake] 

Is it really such a burden, to provide some security context for what 

you are doing, to say something like: 

"Security consideration for IEEE 802.16 appear in Section 7 of 

802.16-2004 and of 802.16e-2005. Security considerations for RADIUS 

extensions appear in RFC 2869." or the like? "

[BA] Since this document applies only to PKMv1, mentioning IEEE 802.16e
would probably be confusing.  Mentioning RFC 3579 (which supercedes
RFC 2869 with respect to EAP/RADIUS) might make sense. 

 EMAILING FOR THE LEAST WORST BAD
Join me

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 26 Aug 2009 14:20:07 -0700

Bernard Aboba [mailto:[email-masked]] writes:

Donald Eastlake said:

If you can suggest a way to make it clearer, I'd appreciate it: only PLMv1
is ever mentioned, the only referenced IEEE standard is 802.16-2006, the
attributes defined have nothing to do with EAP, etc.

[Donald Eastlake]

[BA]

AFAICT, this is not the case.  The use of RADIUS doesn't improve the
security of PKMv2 but it doesn't seem to reduce it either .  The suggested
use of the MS-MPPE-Send-Key Attribute may be problematic but seems pretty
much unavoidable at present.

OK
[Donald Eastlake]

I have no idea how that would make anything clear.  Can you explain?

.

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 26 Aug 2009 18:24:21 -0700

.

OK

The Security Considerations section now looks like this:

7.  Security Considerations

   Section 4 of RFC 3579 [RFC3579] discusses vulnerabilities of the

   RADIUS protocol.

   Section 3 of the paper "Security Enhancements for Privacy and Key

   Management Protocol in IEEE 802.16e-2005" [SecEn] discusses the

   operation and vulnerabilities of the PKMv1 protocol.

   If the Access-Request message is not subject to strong integrity

   protection, an attacker may be able to modify the contents of the

   PKM-Cryptosuite-List Attribute, weakening 802.16 security or

   disabling data encryption altogether.

   If the Access-Accept message is not subject to strong integrity

   protection, an attacker may be able to modify the contents of the

   PKM-Auth-Key Attribute.  For example, the Key field could be replaced

   with a key known to the attacker.

   Although it is necessary for a plaintext copy of the Key field in the

   PKM-AUTH-Key Attribute to be transmitted in the Access-Accept

   message, this document does not define a method for doing so

   securely.  In order to transfer the key securely, it is RECOMMENDED

   that it be encapsulated in an instance of the MS-MPPE-Send-Key

   Attribute [RFC2548]; however, see section 4.3.4 of RFC 3579 [RFC3579]

   for details regarding weaknesses in the encryption scheme used.

Is that OK?
.

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 26 Aug 2009 22:36:42 -0400

Looks OK to me,
Donald

On Wed, Aug 26, 2009 at 9:24 PM, Glen Zorn<[email-masked]> wrote:
> …
> AFAICT, this is not the case.  The use of RADIUS doesn’t improve the
> security of PKMv2 but it doesn’t seem to reduce it either .  The suggested
> …

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 26 Aug 2009 23:45:48 -0700

Yes, this looks good. 

> Date: Wed, 26 Aug 2009 22:36:42 -0400
> Subject: Re: draft-zorn-radius-pkmv1-05.txt
> From: [email-masked]
> To: [email-masked]
> CC: [email-masked]; [email-masked]; [email-masked]
> 
> Looks OK to me,
> Donald
>