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

[Donald Eastlake <[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?
> …