Here are my comments on the document: Overall Comments While this document includes a lot of useful requirements, it does not provide guidance on how document authors should demonstrate adherence to the principles that are described. For example, a AAA key management document may not include a section describing the assumptions and requirements of the design, which can make it difficult for a reviewer to determine whether or not the protocol fulfills its goals. The document describes a number of useful security properties, but there is no request that document authors include sections in their documents that correspond to these requirements. As a result, my concern is that reviewers could be left with a large task to determine whether a given document did or did not fulfill the requirements described in this document. In order to make life easier for reviewers, it might be helpful for the document to provide explicit guidance for draft authors. NITs Section 2 This section is entitled "AAA Environment Concerns". As a result, I was expecting the section to begin with a description of issues relating to AAA. Instead the section starts off talking about EAP. My suggestion is that the section be reorganized as follows: " Examples of serious flaws plague the history of key management protocol development, starting with the very first attempt to define a key management protocol in the open literature, which was published in 1978 [NS]. A flaw and a fix were published in 1981 [DS], and the fix was broken in 1994 [AN]. In 1995 [L], a new flaw was found in the original 1978 version, in an area not affected by the 1981/1994 issue. All of these flaws were blindingly obvious once described, yet no one spotted them earlier. Note that the original protocol, if it were revised to employ certificates, which of course had yet to be invented, was only three messages. Many proposed AAA key management schemes are significantly more complicated. This bit of history shows that key management protocols are subtle. Experts can easily miss a flaw. As a result, peer review by multiple experts is essential. In addition, formal methods can help uncover problems [M]. AAA-based key management is being incorporated into standards developed by the IETF and other standards development organizations (SDOs), such as IEEE 802. However, due to ad hoc development of AAA- based key management, AAA-based key distribution schemes have poorly understood security properties, even when well-studied cryptographic algorithms are employed. More academic research is needed to fully understand the security properties of AAA-based key management in the diverse protocol environments where it is being employed today. In the absence of research results, pragmatic guidance based on sound security engineering principles is needed. In addition to the need for interoperability, cryptographic algorithm independent solutions are greatly preferable. Without algorithm independence, the protocol must be changed whenever a problem is discovered with the selected algorithm. As the AAA history shows, problems are inevitable. Problems can surface due to age or design failure. DES [FIPS46] was a well designed encryption algorithm, and it provided protection for many years. Yet, the 56-bit key size was eventually overcome by Moore's Law. No cryptographic deficiencies have been discovered in DES. The history of AAA underlines the importance of algorithm independence as flaws have been found in authentication mechanisms such as CHAP, MS-CHAPv1 [SM1], MS-CHAPv2 [SM2], Kerberos [W][BM][DLS], and LEAP [B]. Unfortunately, RADIUS [RFC2865] mandates use of the MD5 algorithm for integrity protection, which has known deficiencies, and RADIUS has no provisions to negotiate substitute algorithms. Similarly, the vendor-specific key wrap mechanism defined in [RFC2548] has no provisions to negotiate substitute algorithms. The principle of least privilege is an important design guideline. This principle requires that a party be given no more privilege than necessary to perform the task assigned to them. Ensuring least privilege requires clear identification of the tasks assigned to each party, and explicit determination of the minimum set of privileges required to perform those tasks. Only those privileges necessary to perform the tasks are granted. By denying to parties unneeded privileges, those denied privileges cannot be used to circumvent security policy or enable attackers. With this principle in mind, AAA key management schemes need to be designed in a manner where each party has only the privileges necessary to perform their role. That is, no party should have access to any keying material that is not needed to perform their own role. A party has access to a particular key if it has access to all of the secret information needed to derive it. EAP is being used in new ways. The inclusion of support for EAP within IKEv2 and the standardization of robust Wireless LAN security [802.11i] based on EAP are two examples. EAP is also supported within IEEE 802.16e [802.16e] and by the IETF PANA Working Group. EAP selects one end-to-end authentication mechanism. The mechanisms defined in [RFC3748] only support unilateral authentication, and they do not support mutual authentication or key derivation. As a result, these mechanisms do not fulfill the security requirements for many deployment scenarios, including Wireless LAN authentication [RFC4017]. To ensure adequate security and interoperability, EAP applications need to specify mandatory-to-implement algorithms. As described in [RFC3748], EAP methods seeking publication as an IETF RFC need to document their security claims. However, some EAP methods are not based on well-studied models, which makes the validity of these security claims difficult to determine. In the context of EAP, the EAP peer and server are the parties involved in the EAP method conversation, and they gain access to key material when the conversation completes successfully. However, the lower layer needs keying material to provide the desired protection through the use of cryptographic mechanisms. As a result, a "pass- through" mode is used to provide the keying material, and the lower layer keying material is replicated from the AAA server to the authenticator. The only parties authorized to obtain all of the keying material are the EAP peer and server; the authenticator obtains only the keying material necessary for its specific role. No other party can obtain access to any of the keying material." _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf