Subject: [eap] Issue 43: Security Claims

From: [email-masked] (Bernard Aboba)
Date: Wed, 27 Nov 2002 11:25:10 -0800 (PST)

Issue 43: Security Claims
Submitter: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: November 25, 2002
Reference:
Document: RFC2284bis-07
Comment type: T
Priority: S
Section:  6
Rationale/Explanation of issue:

RFC 2284bis does not include definitions of Security Claims or
guidance as to how they are to be treated.

Proposed change:

Delete Section 7.2, and add the following sections to Section 6:

6.3. Security claims

In order to clearly articulate the security provided by an EAP method,
EAP method specifications accompanying a request for allocation of a
Type code MUST include the following declarations:

[a] Intended use. This includes a statement of whether the method is
intended for use over a physically secure or insecure network, as
well as a statement of the applicable media.

[b] Mechanism. This is a statement of the authentication technology:
certificates, pre-shared keys, passwords, token cards, etc.

[c] Security claims. This is a statement of the claimed security
properties of the method, using terms defined in the next section.
The Security Claims section SHOULD include references to proof, or
the proof itself (preferrably in an Appendix).

[d] Key strength. If the method derives keys, then the effective key
strength MUST be provided.

[e] Description of key hierarchy. EAP methods deriving keys MUST either
provide a reference to a key hierarchy specification, or describe
how keys for authentication/integrity, encryption and IVs are to be
derived from the provided keying material, and how cryptographic
separation is maintained between keying material used for different
purposes.

[f] Indication of vulnerabilities. In addition to the security claims
that are made, the specification MUST indicate which of the
security claims detailed in the next section are NOT being made,
and discuss the security implications.

6.4. Security terms

Mutual authentication
This refers to a method in which, within a single
conversation, the Authenticator authenticates the Peer
and the Peer authenticates the Authenticator. Two one-way
conversations, running in opposite directions, do not
provide mutual authentication as defined here.

Integrity protection
This refers to authentication and integrity protection of
EAP messages, including EAP Requests and Responses of
types Identity, Nak and Notification, as well as EAP
Requests and Responses, and success and failure
indications.

Replay protection
This refers to replay protection of EAP messages,
including EAP Requests and Responses of types Identity,
Nak and Notification, as well as EAP Requests and
Responses, and success and failure indications.

Confidentiality
This refers to encryption of EAP messages, including EAP
Requests and Responses of types Identity, Nak and
Notification, as well as EAP Requests and Responses, and
success and failure indications. A method making this
claim MUST therefore also include support for identity
protection.

Key derivation This refers to the ability of the EAP method to derive
ciphersuite-independent master session keys, used only
for further key derivation, as detailed in [KEYS].

Key strength This refers to the effective entropy of the derived
master session keys, independent of their physical
length. For example, a 128-bit key derived from a
password might have an effective entropy much less than
128 bits.

Dictionary attack resistance
Where password authentication is used, users are
notoriously prone to selection of poor passwords. A
method may be said to be dictionary attack resistant if a
brute force attack would require, on average, sorting
through 2^64 or more possibilities. This can be
accomplished, for example, by avoiding the use of
passwords altogether (e.g. certificates, token cards), or
by using a shared secret with sufficiently high entropy.

Fast reconnect The ability, in the case where a security association has
been previously established, to create a new or refreshed
security association in 2.5 round-trips or less
(excluding an Identity exchange).
including EAP Requests and Responses of types Identity,
Nak and Notification, as well as EAP Requests and
Responses, and success and failure indications.

Man-in-the-Middle resistance
The ability, for the peer to demonstrate to the
authenticator that it has acted as the peer for each
method within a sequence of methods or tunnel. Similarly,
the authenticator demonstrates to the peer that it has
acted as the authenticator for each method within the
sequence or tunnel. If this is not possible, then the
authentication sequence or tunnel may be vulnerable to a
man-in-the-middle attack.

Acknowledged Success/Failure indications
The ability of the Peer to provide the Authenticator with
a Success/Failure indication in response to such an
indication sent from the Authenticator to the Peer. Since
cleartext success/failure indications can be spoofed,
making this claim requires that the acknowledged
Success/Failure exchange be integrity protected.