Re: [secdir] draft-zorn-radius-pkmv1-05.txt

[Bernard Aboba <[e-mail]>]

Yes, this looks good. 




> Date: Wed, 26 Aug 2009 22:36:42 -0400
> Subject: Re: draft-zorn-radius-pkmv1-05.txt
> From: [e-mail]
> To: [e-mail]
> CC: [e-mail]; [e-mail]; [e-mail]
> 
> Looks OK to me,
> Donald
> 
> On Wed, Aug 26, 2009 at 9:24 PM, Glen Zorn<[e-mail]> wrote:
> > …
> > 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?
> > …