Subject: [eap] Re: Issue 302: Clarifications on the "Domino Effect"

From: Bernard Aboba <[email-masked]>
Date: Fri, 29 Jul 2005 19:44:19 -0700 (PDT)

A number of questions have arisen relating to this and other requirements.
Previously all we had had for reference was RFC 4017, which was based
on Russ Housley's presentation at IETF 56.

Now in addition we have an I-D entitled "AAA Key Management":
http://www.ietf.org/internet-drafts/draft-housley-aaa-key-mgmt-00.txt

Here what this document says about the Domino Effect:

"Compromise of a single authenticator MUST NOT compromise any
other part of the system, especially session keys and long-term
keys.  There are many implications of this requirement;
however, two implication deserves highlighting.  First, an
authenticator MUST NOT share any keying material with another
authenticator.  Second, the scope of the authenticator needs to
be defined and understood by all parties that communicate with it."

-----------------------------------------------------------------------
Issue 302: Clarifications on the "Domino Effect"
Submitter name: Julien Bournelle
Submitter email address: [email-masked]
Date first submitted: 5/4/2005
Reference: http://mail.frascone.com/pipermail/eap/2005-May/003390.html
Document: KEYING-06
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue
 In RFC4017, the Domino effect is described:

 "Compromise of a single authenticator cannot compromise any other part
 of the system, including session keys and long-term secrets."

 Does this finally imply that the authenticator MUST not provide keys to
 other entity ?

_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Jari Arkko <[email-masked]>
Date: Sat, 30 Jul 2005 07:21:04 +0300

Bernard Aboba wrote:

>Second, the scope of the authenticator needs to
Does this include the ability to avoid a situation
where scope to party A (the peer) != scope to
party B (AAA)? Or does it matter?
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 29 Jul 2005 21:23:00 -0700 (PDT)

The proposed resolution is to summarize the security requirements
from draft-housley-aaa-key-mgmt-00.txt in the key management document.

In Section 6.2, change:

"  In order to address these threats, [Housley] describes the mandatory
   system security properties:

Algorithm independence
     Wherever cryptographic algorithms are chosen, the algorithms must
     be negotiable, in order to provide resilient against compromise of
     a particular algorithm.  Algorithm independence must be
     demonstrated within all aspects of the system, including within
     EAP, AAA and the Secure Association Protocol.  However, for
     interoperability, at least one suite of algorithms MUST be
     implemented.

Strong, fresh session keys
     Session keys must be demonstrated to be strong and fresh in all
     circumstances, while at the same time retaining algorithm
     independence.

Replay protection
     All protocol exchanges must be replay protected.  This includes
     exchanges within EAP, AAA, and the Secure Association Protocol.

Authentication
     All parties need to be authenticated.  The confidentiality of the
     authenticator must be maintained.  No plaintext passwords are
     allowed.

Authorization
     EAP peer and authenticator authorization must be performed.

Session keys
     Confidentiality of session keys must be maintained.

Ciphersuite negotiation
     The selection of the "best" ciphersuite must be securely confirmed.

Unique naming
     Session keys must be uniquely named.

Domino effect
     Compromise of a single authenticator cannot compromise any other
     part of the system, including session keys and long-term secrets.

Key binding
     The key must be bound to the appropriate context."

to:

"  In order to address these threats, [Housley] describes the mandatory
   system security properties:

Cryptographic algorithm independence
     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.  The AAA
     protocol MUST be algorithm independent, both in terms of its own
     security mechanisms as well as mechanisms supported for user
     authentication.  Algorithm independence is also REQUIRED with a
     Secure Association Protocol if one is defined.  This is usually
     accomplished by including an algorithm identifier in the protocol,
     and by specifying the algorithm requirements in the protocol
     specification.  For interoperability, at least one suite of
     mandatory-to-implement algorithms MUST be selected.

Strong, fresh session keys
     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 as defined in [RFC3766].

     A fresh cryptographic key is one that is generated specifically for
     the intended use.  In this situation, a post-EAP handshake is used
     to establish session keys.  Thus, the AAA protocol and EAP method
     MUST ensure that the keying material supplied as an input to
     session key derivation is fresh, and the post-EAP handshake MUST
     generate a separate session key for each session, even if the
     keying material provided by EAP is cached.  Further, the keys MUST
     NOT be dependent on one another.  That is, disclosure of one
     session key does not aid the attacker in discovering any other
     session keys.

Key scope Limitation
     Follow the principle of least privilege.  Parties MUST NOT have
     access to 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.

     If a post-EAP handshake is used to establish session keys, the
     post-EAP handshake MUST specify the scope for session keys.

Replay detection mechanism
     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.

Authenticate all parties
     Each party in the AAA key management protocol MUST be authenticated
     to the other parties with whom it communicates.  Authentication
     mechanisms MUST maintain the confidentiality of any secret values
     used in the authentication process.

     A post-EAP handshake is used to establish session keys, and the
     parties involved in the post-EAP handshake MUST identify themselves
     using identities that are meaninful in the lower layer protocol
     environment that will employ the session keys.

No Cleartext Passwords
     Authentication mechanisms MUST NOT employ plaintext passwords.

Peer and authenticator authorization
     Peer and authenticator authorization MUST be performed.
     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,
     authenticator.  Once the AAA key management protocol exchanges are
     complete, all of these parties should hold view of the
     authorizations associated the other parties.

Keying material confidentiality
     While preserving algorithm independence, confidentiality of all
     keying material MUST be maintained.

Confirm ciphersuite selection
     The selection of the "best" ciphersuite MUST be securely confirmed.
     The mechanism MUST detect attempted roll back attacks.

Uniquely name keys
     AAA key management proposals require a robust key naming scheme,
     particularly where key caching is supported.  Objects that cannot
     be named cannot be managed.  All keys MUST be uniquely named, and
     the key name MUST NOT be based on the keying material itself.

Prevent the Domino effect
     Compromise of a single authenticator MUST NOT compromise any other
     part of the system, especially session keys and long-term keys.
     There are many implications of this requirement; however, two
     implication deserves highlighting.  First, an authenticator MUST
     NOT share any keying material with another authenticator.  Second,
     the scope of the authenticator needs to be defined and understood
     by all parties that communicate with it.

Bind key to its context
     Keying material MUST be bound to the appropriate context.

Acceptable solutions SHOULD meet all of these requirements as well:

Confidentiality of Identity
     In many environments it is important to provide confidentiality
     protection for identities.  However, this is not important in other
     environments.  For this reason, EAP methods SHOULD provide a
     mechanism for identity protection of EAP peers, but such protection
     is not a requirement.

Authorization Restriction
     If peer authorization is restricted, then the peer SHOULD be made
     aware of the restriction."

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 29 Jul 2005 21:35:49 -0700 (PDT)

> party B (AAA)? Or does it matter?

Good question.  I think "all parties" does include the EAP peer,
authentication and AAA server in this case.

Where key caching is supported, at the lower layer, the peer and
authenticator need to identify each  other, so that they can be in sync
with respect to the scope of the EAP keying material cached in the lower
layer.

The AAA server needs to know the authenticator identity so that it can
authorize the transport of keying material.  Since an authenticator can
have more than one IP address, the NAS-Identifier attribute is the best
choice for this (as opposed to NAS-IP-Address and/or NAS-IPv6-Address).

In order to be compatible with channel bindings, the authenticator
identity provided to the AAA server needs to be the same as the identity
provided to the peer.
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap