Looks OK to me, Donald On Wed, Aug 26, 2009 at 9:24 PM, Glen Zorn<gwz@xxxxxxxxxxx> 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? > … _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf