RE: Last Call: 'Guidance for AAA Key Management' to BCP (draft-housley-aaa-key-mgmt)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]