Subject: [eap] Proposed Resolution to Issue 394: Guidelines Sync

From: "Bernard Aboba" <[email-masked]>
Date: Sun, 06 May 2007 09:31:06 -0700

The text of issue 394 is enclosed below.   The proposed resolution is as 
follows:

In Section 5.1, replace:

"  Requirement: In the event that an authenticator is compromised or
   stolen, an attacker may gain access to the network through that
   authenticator, or may obtain the credentials required for the
   authenticator/AAA client to communicate with one or more backend
   authentication servers.  Similarly, if a peer is compromised or
   stolen, an attacker may obtain credentials required to communicate
   with one or more authenticators.  Compromise of a single peer MUST
   NOT compromise keying material held by any other peer within the
   system, including session keys and long-term keys, with the possible
   exception of group keys.  Likewise, compromise of a single
   authenticator MUST NOT compromise keying material held by any other
   authenticator within the system.  In the context of a key hierarchy,
   this means that the compromise of one node in the key hierarchy must
   not disclose the information necessary to compromise other branches
   in the key hierarchy.  Obviously, the compromise of the root of the
   key hierarchy will compromise all of the keys; however, a compromise
   in one branch MUST NOT result in the compromise of other branches.
   There are many implications of this requirement; however, two
   implications deserve highlighting.  First, the scope of the keying
   material must be defined and understood by all parties that
   communicate with a party that holds that keying material.  Second, a
   party that holds keying material in a key hierarchy must not share
   that keying material with parties that are associated with other
   branches in the key hierarchy."

With:

"  Requirement: In the event that an authenticator is compromised or
   stolen, an attacker can gain access to the network through that
   authenticator, or can obtain the credentials needed for the
   authenticator/AAA client to communicate with one or more backend
   authentication servers.  Similarly, if a peer is compromised or
   stolen, an attacker can obtain credentials needed to communicate with
   one or more authenticators.  As noted in  [I-D.housley-aaa-key-mgmt]
   Section 3:

      Compromise of a single peer MUST NOT compromise keying material
      held by any other peer within the system, including session keys
      and long-term keys.  Likewise, compromise of a single
      authenticator MUST NOT compromise keying material held by any
      other authenticator within the system.  In the context of a key
      hierarchy, this means that the compromise of one node in the key
      hierarchy must not disclose the information necessary to
      compromise other branches in the key hierarchy.  Obviously, the
      compromise of the root of the key hierarchy will compromise all of
      the keys; however, a compromise in one branch MUST NOT result in
      the compromise of other branches.  There are many implications of
      this requirement; however, two implications deserve highlighting.
      First, the scope of the keying material must be defined and
      understood by all parties that communicate with a party that holds
      that keying material.  Second, a party that holds keying material
      in a key hierarchy must not share that keying material with
      parties that are associated with other branches in the key
      hierarchy.

      Group keys are an obvious exception.  Since all members of the
      group have a copy of the same key, compromise of any one of the
      group members will result in the disclosure of the group key."

In Section 5.2, replace:

"  Requirement: The ability to negotiate cryptographic algorithms
   resilience against compromise of a particular algorithm.  This is
   usually accomplished by including an algorithm identifier and
   parameters in the protocol, and by specifying the algorithm
   requirements in the protocol specification.  While highly desirable,
   the ability to negotiate key derivation functions (KDFs) is not
   required.  For interoperability, at least one suite of mandatory-to-
   implement algorithms MUST be selected.  The selection of the "best"
   cryptographic algorithm SHOULD be securely confirmed.  The mechanism
   SHOULD detect attempted roll back attacks."

with:

"   Requirement from [I-D.housley-aaa-key-mgmt] Section 3:

      The AAA key management protocol MUST be cryptographic algorithm
      independent.  However, an EAP method MAY depend on a specific
      cryptographic algorithm.  The ability to negotiate the use of a
      particular cryptographic algorithm provides resilience against
      compromise of a particular cryptographic algorithm.  Algorithm
      independence is also REQUIRED with a Secure Association Protocol
      if one is defined.  This is usually accomplished by including an
      algorithm identifier and parameters in the protocol, and by
      specifying the algorithm requirements in the protocol
      specification.  While highly desirable, the ability to negotiate
      key derivation functions (KDFs) is not required.  For
      interoperability, at least one suite of mandatory-to-implement
      algorithms MUST be selected...  The selection of the "best"
      ciphersuite SHOULD be securely confirmed.  The mechanism SHOULD
      detect attempted roll back attacks."

In Section 5.3, replace:

"  Requirement: Each party in the EAP, AAA and Secure Association
   Protocol conversations MUST be authenticated to the other parties
   with whom they communicate.  Authentication mechanisms MUST maintain
   the confidentiality of any secret values used in the authentication
   process.  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.
   While preserving algorithm independence, confidentiality and
   integrity of all keying material MUST be maintained."

With:

"   Requirement: Each party in the EAP, AAA and Secure Association
    Protocol conversations MUST be authenticated to the other parties
    with whom they communicate. As noted in [I-D.housley-aaa-key-mgmt] 
Section 3:

      Authentication mechanisms MUST maintain the confidentiality of any
      secret values used in the authentication process.
      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 can 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.  If the lower layer
      identifier of the peer will be used to make authorization
      decisions, then the pair of identifiers associated with the peer
      MUST be authorized by the authenticator and/or the AAA server.

      Authentication mechanisms MUST NOT employ plaintext passwords.
      Passwords may be used provided that they are not sent to another
      party without confidentiality protection...  While preserving
      algorithm independence, confidentiality and integrity of all
      keying material MUST be maintained."

In Section 5.4, replace:

"  Requirement: Keying material MUST be bound to the appropriate
   context.  Any party with legitimate access to keying material can
   determine its context.  In addition, the protocol MUST ensure that
   all parties with legitimate access to keying material have the same
   context for the keying material.  This requires that the parties are
   properly identified and authenticated, so that all of the parties
   that have access to the keying material can be determined.  The
   context includes the following:

      o The manner in which the keying material is expected to be used.

      o The other parties that are expected to have access to the keying
      material.

      o The maximum lifetime of the keying material.  The maximum
      lifetime of a child key SHOULD NOT be greater than the maximum
      lifetime of its parent in the key hierarchy."

With:

"   Requirement from [I-D.housley-aaa-key-mgmt] Section 3:

      Keying material MUST be bound to the appropriate context.  The
      context includes the following:

      o  The manner in which the keying material is expected to
         be used.

      o  The other parties that are expected to have access to
         the keying material.

      o  The expected lifetime of the keying material.  Lifetime
         of a child key SHOULD NOT be greater than the lifetime of
         its parent in the key hierarchy.

      Any party with legitimate access to keying material can determine
      its context.  In addition, the protocol MUST ensure that all
      parties with legitimate access to keying material have the same
      context for the keying material.  This requires that the parties
      are properly identified and authenticated, so that all of the
      parties that have access to the keying material can be determined.

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

In Section 5.5, replace:

"  Requirement: Peer and authenticator authorization MUST be performed.
   These entities MUST demonstrate possession of the appropriate keying
   material, without disclosing it.  Authorization is REQUIRED whenever
   a peer associates with a new authenticator.  The authorization
   checking prevents an elevation of privilege attack, and it ensures
   that an unauthorized authenticator is detected.  Authorizations
   SHOULD be synchronized between the EAP peer, server, and
   authenticator.  Once all protocol exchanges are complete, all of
   these parties should hold a common view of the authorizations
   associated the other parties.  The Secure Association Protocol (phase
   2) conversation may utilize different identifiers from the EAP
   conversation (phase 1a), so that binding between the EAP and Secure
   Association Protocol identities is REQUIRED."

With:

"  The Secure Association Protocol (phase
   2) conversation may utilize different identifiers from the EAP
   conversation (phase 1a), so that binding between the EAP and Secure
   Association Protocol identities is REQUIRED."
   As noted in [I-D.housley-aaa-key-mgmt] Section 3:

      Peer and authenticator authorization MUST be performed.  These
      entities MUST demonstrate possession of the appropriate keying
      material, without disclosing it.  Authorization is REQUIRED
      whenever a peer associates with a new authenticator.  The
      authorization checking prevents an elevation of privilege attack,
      and it ensures that an unauthorized authenticator is detected.

      Authorizations SHOULD be synchronized between the peer, NAS, and
      backend authentication server.  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.

      In addition to authenticating all parties, key management
      protocols need to demonstrate that the parties are authorized to
      possess keying material.  Note that proof of possession of keying
      material does not necessarily prove authorization to hold that
      keying material.  For example, within an IEEE 802.11i, the 4-way
      handshake demonstrates that both the peer and authenticator
      possess the same EAP keying material.  However, by itself, this
      possession proof does not demonstrate that the authenticator was
      authorized by the backend authentication server to possess that
      keying material.  As noted in [RFC3579] Section 4.3.7, where AAA
      proxies are present, it is possible for one authenticator to
      impersonate another, unless each link in the AAA chain implements
      checks against impersonation.  Even with these checks in place, an
      authenticator may still claim different identities to the peer and
      the backend authentication server.  As described in [RFC3748]
      Section 7.15, channel binding enables the peer to verify that the
      authenticator claim of identity is both consistent and correct."

In Section 5.6, replace:

"   Requirement: Exchanges MUST be replay protected, including AAA, EAP
   and Secure Association Protocol exchanges.  Replay protection allows
   a protocol message recipient to discard any message that was recorded
   during a previous legitimate dialogue and presented as though it
   belonged to the current dialogue."

With:

"   Requirement from [I-D.housley-aaa-key-mgmt] Section 3:

      The AAA key management protocol exchanges MUST be replay
      protected, including AAA, EAP and Secure Association Protocol
      exchanges.  Replay protection allows a protocol message recipient
      to discard any message that was recorded during a previous
      legitimate dialogue and presented as though it belonged to the
      current dialogue."

In Section 5.7, replace:

"  Requirement: While preserving algorithm independence, session keys
   MUST be strong and fresh.  A session key SHOULD be considered
   compromised if it remains in use beyond its authorized lifetime.
   Each session deserves an independent session key; disclosure of one
   session key MUST NOT aid the attacker in discovering any other
   session keys.  Fresh keys are required even when a long replay
   counter (that is, one that "will never wrap") is used to ensure that
   loss of state does not cause the same counter value to be used more
   than once with the same session key.  A fresh cryptographic key is
   one that is generated specifically for the intended use.  In this
   situation, a secure association protocol is used to establish session
   keys.  The AAA protocol and EAP method MUST ensure that the keying
   material supplied as an input to session key derivation is fresh, and
   the secure association protocol MUST generate a separate session key
   for each session, even if the keying material provided by EAP is
   cached."

With:

"  Requirement: A session key SHOULD be considered compromised if it
   remains in use beyond its authorized lifetime.  As noted in [I-
   D.housley-aaa-key-mgmt] Section 3:

      While preserving algorithm independence, session keys MUST be
      strong and fresh.  Each session deserves an independent session
      key.  Fresh keys are required even when a long replay counter
      (that is, one that "will never wrap") is used to ensure that loss
      of state does not cause the same counter value to be used more
      than once with the same session key.

      Some EAP methods are capable of deriving keys of varying strength,
      and these EAP methods MUST permit the generation of keys meeting a
      minimum equivalent key strength.  BCP 86 [RFC3766] offers advice
      on appropriate key sizes.  The National Institute for Standards
      and Technology (NIST) also offers advice on appropriate key sizes
      in [SP800-57].

      A fresh cryptographic key is one that is generated specifically
      for the intended use.  In this situation, a secure association
      protocol is used to establish session keys.  The AAA protocol and
      EAP method MUST ensure that the keying material supplied as an
      input to session key derivation is fresh, and the secure
      association protocol MUST generate a separate session key for each
      session, even if the keying material provided by EAP is cached.  A
      cached key persists after the authentication exchange has
      completed.  For the AAA/EAP server, key caching can happen when
      state is kept on the server.  For the NAS or client, key caching
      can happen when the NAS or client does not destroy keying material
      immediately following the derivation of session keys.

      Session keys MUST NOT be dependent on one another.  Multiple
      session keys may derived from a higher-level shared secret as long
      as a one-time value, usually called a nonce, is used to ensure
      that each session key is fresh.  The mechanism used to generate
      session keys MUST ensure that the disclosure of one session key
      does not aid the attacker in discovering any other session keys."

In Section 5.8, replace:

"  Requirement: Following the principle of least privilege, parties MUST
   NOT have access to keying material that is not needed to perform
   their role.  A party has access to a particular key if it has access
   to all of the secret information needed to derive it.  Any protocol
   that is used to establish session keys, MUST specify the scope for
   session keys, clearly identifying the parties to whom the session key
   is available."

With:

"   Requirement from [I-D.housley-aaa-key-mgmt] Section 3:

      Following the principle of least privilege, parties MUST NOT have
      access to keying material that is not needed to perform their
      role.  A party has access to a particular key if it has access to
      all of the secret information needed to derive it.

      Any protocol that is used to establish session keys, MUST specify
      the scope for session keys, clearly identifying the parties to
      whom the session key is available."

In Section 5.9, replace:

"  Requirement: A robust key naming scheme is REQUIRED, particularly
   where key caching is supported.  The key name provides a way to refer
   to a key in a protocol so that it is clear to all parties which key
   is being referenced.  Objects that cannot be named cannot be managed.
   All keys MUST be uniquely named, and the key name MUST NOT directly
   or indirectly disclose the keying material.  If the key name is not
   based on the keying material, then one can be sure that it cannot be
   used to assist in a search for the key value."

With:

"   Requirement from [I-D.housley-aaa-key-mgmt] Section 3:

      AAA key management proposals require a robust key naming scheme,
      particularly where key caching is supported.  The key name
      provides a way to refer to a key in a protocol so that it is clear
      to all parties which key is being referenced.  Objects that cannot
      be named cannot be managed.  All keys MUST be uniquely named, and
      the key name MUST NOT directly or indirectly disclose the keying
      material.  If the key name is not based on the keying material,
      then one can be sure that it cannot be used to assist in a search
      for the key value."

=================
Issue 394: Guidelines Sync
Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date Submitted:
Reference:
Document: KEYING-18
Comment type: Technical
Priority: S
Section: 5
Rationale/Explanation of issue:

Keying-08 was based on the -06 version of the Guidelines for AAA Key 
management document, which is now at -09.  When the Guidelines for AAA Key 
Management document is approved for publication as an RFC, the requirements 
text in Section 5 of the EAP Key Management Framework document will need to 
be updated to reflect the changes to the Guidelines requirements.

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap