RE: draft-zorn-radius-pkmv1-05.txt

["Glen Zorn" <gwz@xxxxxxxxxxx>]

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

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.

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.

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?
…

_______________________________________________

Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf