Subject: [eap] Issue 156: Terminology reorganization

From: [email-masked] (Bernard Aboba)
Date: Mon, 7 Jul 2003 20:09:32 -0700 (PDT)

Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: July 6, 2003
Reference:
Document: EAP-04
Comment type: T
Priority: S
Section: 1.2, 1.3, 7.2.1
Rationale/Explanation of issue:

The security claims terminology is best left with the rest of the security
claims section 7.2.
Also, the definitions of Man-in-the-Middle resistance and Cryptographic
binding appear to overlap.

Change Section 1.2 to the following:

"1.2 Terminology

   This document frequently uses the following terms:

   authenticator
             The end of the link initiating EAP authentication. The
             term Authenticator is used in [IEEE-802.1X], and
             authenticator has the same meaning in this document.

   peer
             The end of the link that responds to the authenticator.
             In [IEEE-802.1X], this end is known as the Supplicant.

   backend authentication server
             A backend authentication server is an entity that provides
             an authentication service to an authenticator.  When used,
             this server typically executes EAP methods for the
             authenticator. This terminology is also used in
             [IEEE-802.1X].

   Displayable Message
             This is interpreted to be a human readable string of
             characters.  The message encoding MUST follow the UTF-8
             transformation format [RFC2279].

   EAP server
             The entity that terminates the EAP authentication method
             with the peer.  In the case where no backend authentication
             server is used, the EAP server is part of the authenticator.
             In the case where the authenticator operates in
             pass-through mode, the EAP server is located on the backend
             authentication server.

   Silently Discard
             This means the implementation discards the packet without
             further processing.  The implementation SHOULD provide the
             capability of logging the event, including the contents of
             the silently discarded packet, and SHOULD record the event
             in a statistics counter.

   Successful authentication
             In the context of this document, "successful
             authentication" is an exchange of EAP messages, as a result
             of which the authenticator decides to allow access by the
             peer, and the peer decides to use this access. The
             authenticator's decision typically involves both
             authentication and authorization aspects; the peer may
             successfully authenticate to the authenticator but access
             may be denied by the authenticator due to policy reasons.

   Message Integrity Check (MIC)
             A keyed hash function used for authentication and integrity
             protection of data.  This is usually called a Message
             Authentication Code (MAC), but IEEE 802 specifications (and
             this document) use the acronym MIC to avoid confusion with
             Medium Access Control.

   Cryptographic separation
             Two keys (x and y) are "cryptographically separate" if an
             adversary that knows all messages exchanged in the protocol
             cannot compute x from y or y from x without "breaking" some
             cryptographic assumption.  In particular, this definition
             allows that the adversary has the knowledge of all nonces
             sent in cleartext as well as all predictable counter values
             used in the protocol.  Breaking a cryptographic assumption
             would typically require inverting a one-way function or
             predicting the outcome of a cryptographic pseudo-random
             number generator without knowledge of the secret state.  In
             other words, if the keys are cryptographically separate,
             there is no shortcut to compute x from y or y from x, but
             the work an adversary must do to perform this computation
             is equivalent to performing exhaustive search for the
             secret state value.

   Master Session Key (MSK)
             Keying material that is derived between the EAP peer and
             server and exported by the EAP method. The MSK is used
             in the derivation of Transient Session Keys (TSKs) for
             the ciphersuite negotiated between
             the EAP peer and authenticator.  Where a backend
             authentication server is present, acting as an EAP server,
             it will typically transport the MSK to the authenticator,
             so that in this case, the MSK is available to the peer,
             authenticator and authentication server.

   Extended Master Session Key (EMSK)
             Additional keying material derived between the EAP client
             and server that is exported by the EAP method.  Unlike the
             MSK, the EMSK is known only to the EAP peer and EAP server
             and is not provided to a third party.  The EMSK is reserved
             for future uses that are not defined yet.  For example, it
             could be used to derive additional keying material for
             purposes such as fast handoff, cryptographic binding, etc."

Delete Section 1.3.

Add Section 7.2.1:

"7.2.1 Security claims terminology for EAP methods

   These terms are used to described the security properties of EAP
   methods:

   Mutual authentication
             This refers to an EAP method in which, within an
             interlocked exchange, the authenticator authenticates the
             peer and the peer authenticates the authenticator.  Two
             independent one-way methods, running in opposite directions
             do not provide mutual authentication as defined here.

   Integrity protection
             This refers to providing data origin authentication and
             protection against unauthorized modification of information
             for EAP packets (including EAP Requests and Responses).
             When making this claim, a method specification MUST
             describe the EAP packets and fields within the EAP packet
             that are protected.

   Replay protection
             This refers to protection against replay of an EAP method
             or its messages, including method-specific success and
             failure indications.

   Confidentiality
             This refers to encryption of EAP messages, including EAP
             Requests and Responses, and method-specific success and
             failure indications. A method making this claim MUST
             support identity protection (see Section 7.3).

   Key derivation
             This refers to the ability of the EAP method to derive
             exportable keying material such as the Master Session Key
             (MSK), and Extended Master Session Key (EMSK). The MSK is
             used only for further key derivation, not directly for
             protection of the EAP conversation or subsequent data.  Use
             of the EMSK is reserved.

   Key strength
             If the effective key strength is N bits, the best currently
             known methods to recover the key (with non-negligible
             probability) require an effort comparable to 2^N operations
             of a typical block cipher.

   Dictionary attack protection
             Where password authentication is used, users are
             notoriously prone to select poor passwords.  A method may
             be said to be dictionary attack resistant if, when there is
             a weak password in the secret,  the method does not allow
             an attack more efficient than brute force.

   Fast reconnect
             The ability, in the case where a security association has
             been previously established, to create a new or refreshed
             security association in a smaller number of round-trips.

   Cryptographic binding
             The demonstration of the EAP peer to the EAP server that a
             single entity has acted as the EAP peer for all methods
             executed within a tunnel method.  Binding MAY also
             imply that the EAP server demonstrates to the peer that a
             single entity has acted as the EAP server for all methods
             executed within a tunnel method.  If executed
             correctly, binding serves to mitigate man-in-the-middle
             vulnerabilities.

   Acknowledged result indications
             The ability within a method for the authenticator to indicate
             to the peer whether it has successfully authenticated to it,
             and for the peer to acknowledge receipt of that indication as
             well as indicating to the authenticator whether it has
             successfully authenticated to the peer.  Since EAP Success
             and Failure packets are neither acknowledged nor integrity protected,
             this claim requires implementation of a method-specific
             result exchange that is authenticated, integrity and replay
             protected on a per-packet basis."

---

From: [email-masked] (John Vollbrecht)
Date: Tue, 08 Jul 2003 18:12:08 -0400

I think this is good.

--On Monday, July 7, 2003 8:09 PM -0700 Bernard Aboba <[email-masked]> 
wrote:

>              and Failure packets are neither acknowledged nor integrity
> protected,              this claim requires implementation of a
> method-specific              result exchange that is authenticated,
> integrity and replay              protected on a per-packet basis."
>
> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap
>

---

From: [email-masked] (David Jablon)
Date: Wed, 09 Jul 2003 10:40:38 -0400

I see some potential confusion in the proposed EAP-04 definition
for "Dictionary attack protection".

>>"7.2.1 Security claims terminology for EAP methods
...
>>             an attack more efficient than brute force.

Here's a suggested rewording.

        "Where password authentication is used, passwords are
        commonly selected from a set that is small,
        as compared to a set of N-bit keys.  A method may
        be said to be dictionary attack resistant if, when it uses
        a password as a secret, the method does not allow
        an offline attack that has a work factor based on
        the number of passwords in an attacker's dictionary."

The changes are intended to address the following concerns:

-- Since dictionary attack may be regarded as a form of brute force attack,
a reader might wonder how dictionary attack could ever be more efficient than
brute force attack.  A significant distinction can be drawn if "dictionary"
more clearly refers to a work factor based on the set of password guesses
rather than key size.

-- Underqualified use of derogatory terms like "poor" and "weak" leads to
a confusingly circular definition.  The value of using a specific password
depends, in part, on the characteristics of the method, one of which is being
defined here.

-- Users are not alone in being responsible for selecting passwords from
a small set.  Systems, including their developers and administrators, are
"notoriously prone" to encouraging such practice too.

-- There was no mention of whether the attack is offline or online.

---

From: [email-masked] (Bernard Aboba)
Date: Wed, 9 Jul 2003 08:01:02 -0700 (PDT)

>          "Where password authentication is used, commonly selected
>           passwords are weak because they are selected from a
>           small set (as compared to a set of N-bit keys).
>           A method may be said to be dictionary attack resistant if,
>           when it uses a password as a secret, the method does not allow

OK. I've revised the proposed fix in Issue 156.

---

From: [email-masked] (Uri Blumenthal)
Date: Wed, 09 Jul 2003 11:23:27 -0400

Thanks!

Regards,
Uri.

---

From: [email-masked] (David Jablon)
Date: Wed, 09 Jul 2003 12:49:47 -0400

>OK. I've revised the proposed fix in Issue 156.

The first sentence in the above version has a problem similar to the original
version.  It does not make sense to characterize password quality outside
the context of a specific method.  How about:

        "Where password authentication is used, passwords are
        commonly selected from a small set (as compared to a set
        of N-bit keys), which raises the concern of dictionary attack. ..."
        
-- David