Subject: [eap] Comments about draft-aboba-pppext-key-problem-05

From: [email-masked] ([email-masked])
Date: Thu, 6 Feb 2003 15:00:25 +0200

Comments about draft-aboba-pppext-key-problem-05
Submitter name: Pasi Eronen
Submitter email address: [email-masked]
Date first submitted: 6 Feb 2003
Document: draft-aboba-pppext-key-problem-05
Comment type: Technical and editorial
Priority: 1 (should be fixed)
Section: various
Rationale/Explanation of issue:

PASI: Document looks reasonably good, and most of these issues
are simply editorial. Some technical clarifications or questions
are included as well.

--
Section: 1.2
Comment type: Editorial

> Authentication Server
>     An Authentication Server is an entity that provides an
>     Authentication Service to a Network Access Server (NAS). This
>     service verifies from the credentials provided by the Client, the
>     claim of identity made by the Client. Where an Authentication
>     Server is provided, it acts as the EAP Server, terminating EAP
>     conversation with the EAP Client.  In the EAP Keying architecture
>     the Authentication Server acts as a KDC, distributing the Master
>     Session Keys (MSKs) to the EAP Client and NAS.

PASI: Proposed change: "In the EAP Keying architecture the Authentication
Server acts as a KDC, distributing the Master Session Keys (MSKs) 
to the NAS (using AN-Token), and in some EAP methods, also to
the EAP Client (using CS-Token)."

--
Section: 1.2
Comment type: Technical

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

PASI: Proposed change: add "If tunneling is used, the binding
MUST/SHOULD also demonstrate that the same entity has acted as the
tunnel endpoint and EAP Client" after the first sentence, and 
"(and if applicable also as the tunnel endpoint)" after the next
sentence. (Valtteri Niemi et al. paper)

--
Section: 1.2
Comment type: Editorial

> Pairwise Master Key (PMK)
>     As defined in [RFC2716], the MSK is 192 octets (1536 bits) in
>     length.  Octets 0-31 of the MSK are known as the "Peer to
> ...

PASI: I think this text only confuses here. Perhaps it could
be included in Appendix B, if necessary. Proposed change: Delete.

--
Section: 2.1
Comment type: Editorial

> Similarly, because the NAS is not required to implement any EAP methods,
> the NAS cannot be assumed to implement code specific to any EAP method.
> Since operating systems provide EAP APIs in order to remain "EAP-Method
> Agnostic", EAP APIs cannot be assumed to implement EAP method-specific
> code either.

PASI: Operating system EAP APIs are an implementation issue; the EAP
methods could be part of the NAS software instead of a separate
module. Also, the document is already quite convincing about why
cipher suite independence is a good idea.  
Proposed change: Delete the last sentence.

--
Section: 2.1
Comment type: Editorial

> EAP methods deriving keys MUST support mutual authentication and provide
> for the derivation of an EAP Master Key (EMK), known only to the EAP
> Client and Server. EAP methods deriving keys also MUST provide for the
> distribution of the CS-Token between the AAA Server and EAP Client, and
> the AN-Token between the AAA server and NAS.  The MSK contained within
> the CS-Token and AN-Tokens is suitable for use with any negotiated
> ciphersuite, and therefore an EAP method MUST NOT directly use the MSK
> as a Transient Session Key (TSK).  Rather, the TSK(s) are derived from
> the MSK in a separate step, once the negotiated ciphersuite is known.

PASI: This text duplicates information contained later, and I don't
think most of it really belongs to the "cipher suite independence" section.

Proposed change: Replace with "The MSK is suitable for use with any
negotiated ciphersuite, and therefore an EAP method MUST NOT directly
use the MSK as a Transient Session Key (TSK).  Rather, the TSK(s) are
derived from the MSK in a separate step, once the negotiated
ciphersuite is known."

--
Section: 3
Comment type: Editorial

> [a] Two-party exchange. The two-party exchange occurs where the EAP
>     Client and NAS act as the endpoints of the EAP conversation, and no
>     Authentication Server is present. Here the NAS implements the EAP
>     method locally, rather than acting as a pass-through. In this mode,
>     the EAP method used between the EAP Client and NAS (EAP Server)
>     derives the EMK, as well as providing for the distribution of the
>     Client-Server token containing the MSK.
>
> [b] Three-party exchange. This mode is used where the NAS acts as a
>     pass-through and an Authentication Server (acting as an EAP Server)
>     is present. In this mode, the EAP Server and Client derive the EMK,
>     and the Authentication Server distributes to the CS-Token to the
>     EAP Client and the AN-Token to the NAS.  Both the CS-Token and AN-
>     Token contain the embedded MSK.

PASI: I think this should be rephrased a little, since earlier the
document says that most EAP methods don't actually use CS-Token, but
derive the MSK using the EMK key.

Proposed change: Replace last sentence of [a] with "In this mode, the
EAP method used between the EAP Client and NAS (EAP Server) derives
the EMK, and if the MSK is not derived from the EMK, provides for the
distribution of the CS-Token containing the MSK", and in [b]
"In this mode, the EAP Server and Client derive the EMK, and the 
Authentication Server distributes the AN-Token to the NAS,
and if the MSK is not derived from the EMK, the CS-Token 
to the EAP Client".

--
Section: 3.1
Comment type: Editorial

> If the authentication occurs with a method not implemented on the NAS,
> or involves a non-local user whose credentials the Server is unable to
> validate, then the NAS functions as a "pass-through".  For pass-through
> authentication methods, instead of implementing the authentication
> method locally, the NAS delegates the authentication to an
> Authentication Server. The Authentication Server installs the desired
> EAP method, typically by interfacing with the operating system via an
> EAP API, such as that described in [EAPAPI].

PASI: Proposed change: delete last sentence.

--
Section: 3.2
Comment type: Editorial and technical

> [c] TSK derivation. During this phase, the EAP Client and NAS confirm
>     mutual possession of the MSK, and derive the Transient Session Keys
>     used in the negotiated ciphersuite. TSK derivation occurs out of
>     band of EAP; an example is the 4-way handshake provided in IEEE
>     802.11 RSN.

PASI: Proposed change: Add Section 3.3 for discussion of the TSK
derivation step, so we don't have to duplicate it in 3.1 and 3.2.
Move text from 3.2 (paragraphs starting with "During the (optional)
TSK derivation step" and "If the TSK derivation does not"...) there.
Some of this text could be in 4.4 as well (as requirements
for TSK derivation step).

This also needs some clarification, since proving possession of 
the MSK can be implicit (by proving possession of TSKs). 

--
Section: 3.2
Comment type: Technical 

> If the TSK derivation does not support mutual authentication, then the
> EAP Client will not have assurance that it is connected to the right
> NAS, only that the NAS and AAA server share a trust relationship
> (assuming that the AAA protocol supports mutual authentication). This
> distinction can become important when multiple NASes receive MSKs from
> the Authentication Server, as may be the case where fast handoff is
> supported. If the TSK derivation does not provide for protected
> ciphersuite negotiation, then downgrade attacks are possible.

PASI: I think the "mutual authentication" part should be clarified.
The TSK proof of possession and protection of the negotiated
cipher suite must include some connection-specific information
(such as addresses) to ensure that the client is connected
to the right NAS.

--
Section: 3.3
Comment type: Technical

> In order to protect against compromise of the EMK, the EMK MUST NOT
> be directly used to protect data; rather the TEKs derived from the
> EMK are used for this purpose. Examples of the EMK branch of the
> key hierarchy are given in Appendix A.

PASI: What properties are required of the EMK->TEK derivation?
Does it have to be cryptographically one-way? (see also
next comment abount MSK branch)

--
Section: 3.3
Comment type: Technical

> [b] Master Session Key (MSK) branch. The MSK is (optionally)
>     distributed by the Authentication Server to the EAP Client within
>     the CS-Token (or alternatively, derived from the EMK). It is
>     transported from the Authentication Server to the NAS within the
>     AN-Token.  Since the MSK is not ciphersuite-specific, it is larger
>     than necessary, and is truncated to fit as part of the Transient
>     Session Key (TSK) derivation process. As with the EMK, the MSK MUST
>     NOT be directly used to protect data; rather TSKs derived from the
>     MSK are used for this purpose. Examples of the MSK hierarchy are
>     given in Appendix B.

PASI: Truncation might not be the only possible option for TSK
derivation, especially if some strange ciphersuite would require more
than MSKs length of keys. Also, if the TSK would be exactly the same
length as MSK (unlikely, but possible in theory) using TSK=MSK could
be allowed (so the MSK->TSK derivation can be simple splitting,
and it does not have to be cryptographically one-way, right?)

--
Section: 4.1
Comment type: Editorial

> The security of the three-party exchange is highly dependent on the
> security properties of the each of the protocols.  For example, if
> mutual authentication is not completed between the EAP Client and
> Authentication server, then the Client will be vulnerable to rogue
> Authentication Servers and NASes. If the EMK is not derived between the
> Client and Authentication Server, then there will be no binding between
> the authentication and subsequent data traffic, leaving the session
> vulnerable to hijack.

PASI: Proposed change: "If the subsequent data traffic is not
protected using TSKs derived from the MSK (which is either derived
from EMK, or sent in a CS-Token protected by EMK), then there 
will be..."

--
Section: 4.2
Comment type: Technical and editorial

> EMK hierarchy
>     Methods deriving keys MUST support mutual authentication and
>     derivation of the EMK, as well as specifying how TEKs are derived
>     from the EMK. The EMK MUST NOT be used to directly protect data.

PASI: There might be cases where it is difficult for an attacker to
masquerade as the NAS, but passive eavesdropping is still a
problem. In this kind of environment, mutual authentication is not
absolutely required, so I think it should say "SHOULD" instead of
"MUST".

Proposed change 1: Add "Mutual Authentication: Methods deriving keys SHOULD
support mutual authentication to protect against rogue Authentication
Servers and NASes". 

Proposed change 2: Replace text with "EMK hierarchy: Methods deriving
keys MUST support derivation of the EMK, as well as specifying how
TEKs are derived from the EMK. The EMK SHOULD NOT be used to directly
protect data. If multiple TEKs are used, they SHOULD be cryptographically 
separate from each other."

Is a SHOULD enough here? Depending on what algorithms are used in a
particular method, this might not be absolutely necessary (although
using cryptographically separate TEKs would certainly be a good idea,
as a generic design advice).

--
Section: 4.2
Comment type: Editorial

> CS-Token specification
>     Methods supporting key derivation MUST specify the format of the
>     CS-Token containing the MSK. If no explicit CS-Token format is
>     used, then the formulas for derivation of the MSK MUST be provided.

PASI: Proposed change: "CS-Token specification / MSK derivation:
Methods supporting key derivation MUST specify either the format of
the CS-Token containing the MSK (if a CS-Token is used), or the
formulas for derivation of the MSK from other information
(e.g. EMK)."

--
Section: 4.2
Comment type: Editorial

> Ciphersuite Independence
>      The MSK derivation SHOULD be ciphersuite-independent and the EAP
>      method SHOULD NOT assume knowledge of the ciphersuite.

PASI: Proposed change: "The MSK derivation SHOULD be independent
of the ciphersuite used later to protect data traffic, and the EAP
method SHOULD NOT assume knowledge of this ciphersuite".

--
Section: 4.4
Comment type: Editorial

> TEK derivation
>     In order to establish a protected channel between the EAP Client
>     and Server as part of the EAP exchange, a ciphersuite needs to be
>     negotiated and keyed, using TEKs derived from the EMK.  The
>     ciphersuite used to protect the EAP exchange is distinct from the
>     ciphersuite negotiated between the EAP client and NAS, used to
>     protect data.  Where a protected channel is established within the
>     EAP method, the method specification MUST specify the mechanism by
>     which the EAP ciphersuite is negotiated, as well as the algorithms
>     for derivation of TEKs from the EMK during the EAP authentication
>     exchange.

PASI: This is a requirement for an EAP method, so if it's needed, it
should be in Section 4.2 instead of here.  However, 4.2 already says
that the method must specify how TEKs are derived, and any ciphersuite
negotiation is a method-internal issue (e.g., it could use a fixed
cipher suite without any negotiation).
Proposed change: Delete.

--
Section: 4.4
Comment type: Editorial

> EAP method independence
>     Algorithms for deriving TSKs from the MSK MUST NOT depend on the
>     EAP method. However, algorithms for deriving TEKs from the EMK MAY
>     be specific to the EAP method.

PASI: Even how many TEKs are needed, and how long they should be, is
quite specific to the EAP method. This is also clear from previous
text. Proposed change: delete last sentence.

--
Section: 4.4
Comment type: Editorial and technical

> Cryptographic separation
>     The TSKs derived from the MSK MUST be cryptographically separate
>     from each other. Similarly, TEKs MUST be cryptographically separate
>     from each other. In addition, the TSKs MUST be cryptographically
>     separate from the TEKs.

PASI: TEK separation really belongs to Section 4.2. Assuring that
TSKs and TEKs are cryptographically separate requires some 
clarification, since TEKs are derived in a method-specific way,
while MSK->TSK derivation should be method-independent.

In most cases it would be enough that MSK can't be derived from TEKs
(it might not harm most EAP methods if TEKs can be derived from
MSK/TSK). If we want to require bidirectional separation, I propose we
add "MSK must be cryptographically separate from TEKs" to Section 4.2,
"CS-Token specification...".

Best regards,
Pasi