Guidance for Authentication, Authorization, and Accounting (AAA) Key Management
draft-housley-aaa-key-mgmt-09

[Ballot comment]
Minor comments:

Section 2, last paragraph:
OLD:
  however, other parties may receive keys that is derived from this
                                                ^^
NEW:
  however, other parties may receive keys that are derived from this

Section 3,
>      Cryptographic algorithm independent

Although this section implies hash function agility is required, it might be clearer to make that explicit.

[Ballot comment]
Section 2, last paragraph:
OLD:
  however, other parties may receive keys that is derived from this
                                                ^^
NEW:
  however, other parties may receive keys that are derived from this

Section 3,
>      Cryptographic algorithm independent

Although this section implies hash function agility is required, it might be clearer to make that explicit.

[Ballot discuss]
The document is overall in excellent shape, but I have
a few issues:

The document describes generic AAA keying issues. EAP
keying issues are a special case of these. However, in
some places the document talks with EAP terminology
where more general terminology would have been more
appropriate. For instance,

        Authorizations SHOULD be synchronized between the EAP peer,
        server, and authenticator.  Once the AAA key management
        protocol exchanges are complete, all of these parties should
        hold a common view of the authorizations associated the other
        parties.

Presumably the requirement holds even when we
are not talking about EAP?

        The context will include the EAP peer and authenticator
        identities in more than one form.  One (or more) name form is
        needed to identify these parties in the AAA protocol and EAP
        method.  Another name form may be needed to identify these
        parties within the lower layer that will employ the session
        key.

As above.

[Ballot comment]
Finally, I believe the document should have an informational
reference to the EAP Keying Framework draft (a WG item of the
EAP WG), as that document discusses EAP specific keying
issues and requirements.

[Ballot discuss]
The document is overall in excellent shape, but I have
a few issues:

The document describes generic AAA keying issues. EAP
keying issues are a special case of these. However, in
some places the document talks with EAP terminology
where more general terminology would have been more
appropriate. For instance,

        Authorizations SHOULD be synchronized between the EAP peer,
        server, and authenticator.  Once the AAA key management
        protocol exchanges are complete, all of these parties should
        hold a common view of the authorizations associated the other
        parties.

Presumably the requirement holds even when we
are not talking about EAP?

        The context will include the EAP peer and authenticator
        identities in more than one form.  One (or more) name form is
        needed to identify these parties in the AAA protocol and EAP
        method.  Another name form may be needed to identify these
        parties within the lower layer that will employ the session
        key.

As above.

Finally, I believe the document should have an informational
reference to the EAP Keying Framework draft (a WG item of the
EAP WG), as that document discusses EAP specific keying
issues and requirements.

[Ballot comment]
(contributed by AAA doctor David Nelson who reviewed the document and is confortable with its content).

The following text in Section 2 seems to be duplicated, and should probably show up only once:

  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.

[Ballot comment]
(contributed by AAA doctor David Nelson).

The following text in Section 2 seems to be duplicated, and should probably show up only once:

This text appears twice in Section 2.  Probably once is enough.

  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.

[Ballot discuss]
I asked the following questions and this started a lively discussion
among the authors.  It seems clear that these paragraphs will need to
change.  It is less clear what they will change to; Bernard seems to
have found some problems in these paragraphs beyond what I asked.


>        When a secure association protocol is used to establish session
>        keys, the parties involved in the secure association protocol
>        MUST identify themselves using identities that are meaningful
>        in the lower layer protocol environment that will employ the
>        session keys.  In this situation, the authenticator and peer
>        may be known by different identifiers in the AAA protocol
>        environment and the lower layer protocol environment, making
>        authorization decisions difficult without a clear key scope.
First, is there any requirement that both identities be authorized
or somehow that we check to make sure the two identities belong
together?
i'm assuming yes, but don't see this clearly stated.
>        In some situations, multiple base stations and a "controller"
>        (such as a WLAN switch) comprise a single EAP authenticator.
>        In this situation, the "base station identity" is irrelevant to
>        the EAP method conversation, which is between the EAP peer and
>        the EAP server.
>
[Are you trying to say that this is not an example of one of the lower
layer identities that needs to be separately identified or are you
trying to say that since this identity is out of scope for EAP, it
needs to be handled separately.  I suspect the former, but the text is
unclear.]