Subject: [eap] Proposed Resolution to Issue 141: Minor NITs

From: [email-masked] (Bernard Aboba)
Date: Thu, 29 May 2003 10:54:49 -0700 (PDT)

The text of issue 141 is enclosed below. The proposed fixes are as
follows:

In Section 5, change:

"In this case, the input should be processed using an
appropriate stringprep [RFC3454] profile, and encoded in octets using
UTF-8 encoding [RFC2279]. A possible registered stringprep profile
is specified in [SASLPREP]."

To:

"In this case, the input should be processed using an
appropriate stringprep [RFC3454] profile, and encoded in octets using
UTF-8 encoding [RFC2279]. A preliminary version of a possible
stringprep profile is described in [SASLPREP]."

In Section 1.3, change:

"EAP Master key (MK)
A key derived between the EAP client and server during the
EAP authentication process that is purely local to the EAP
method. The MK MUST NOT be exported from the EAP method or
be made available to a third party. Since derivation of
the MK is a residue of the successful completion of the EAP
authentication exchange, proof of MK possession may be used
to shorten future EAP exchanges between the same EAP client
and server, a technique known as "fast resume".

Master Session Key (MSK)
Keying material that is derived between the EAP client and
server. 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.

The MSK differs from the MK in that it not assumed to
remain local to the EAP method, and is known by all parties
in the EAP exchange: the peer, authenticator and the
authentication server (if present). The MSK MAY be derived
from the MK via a one-way function, or it may be an
independent quantity. However possession of the MSK MUST
NOT provide any information useful in determining the MK.

Extended Master Session Key (EMSK)
Additional keying material derived between the EAP client
and server that is exported by the EAP method. However,
unlike the MSK, the EMSK is known only to the EAP peer and
EAP server and MUST NOT be provided to a third party. The
EMSK therefore MUST NOT be transported by the backend
authentication server to the authenticator. 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,
man-in-the-middle vulnerability protection, etc."

To:

"Master Session Key (MSK)
Keying material that is derived between the EAP client and
server. 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,
man-in-the-middle vulnerability protection, etc."

In Section 7.10, change:

"Non-overlapping substrings of the MSK MUST be cryptographically
separate from each other. This is required because some existing
ciphersuites form TSKs by simply splitting the MSK to pieces of
appropriate length. Likewise, non-overlapping substrings of EMSK
MUST be cryptographically separate from each other, and from
substrings of the MSK."

To:

"Non-overlapping substrings of the MSK MUST be cryptographically
separate from each other, as defined in Section 1.3. That is, knowledge
of one substring MUST NOT help in recovering some other substring without
breaking some hard cryptographic assumption. This is required because
some existing ciphersuites form TSKs by simply splitting the MSK to pieces
of appropriate length. Likewise, non-overlapping substrings of the EMSK
MUST be cryptographically separate from each other, and from
substrings of the MSK."

---------------------------------------------------------------------
Issue 141: Minor NITs
Submitter name: Pasi Eronen
Submitter email address: [email-masked]
Date first submitted: May 19, 2003
Reference:
Document: EAP-03
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:
- Section 5: "In this case, the input should be processed using an
appropriate stringprep [RFC3454] profile, and encoded in octets using
UTF-8 encoding [RFC2279]. A possible registered stringprep profile
is specified in [SASLPREP]."

SASLPREP is not (yet) a registered stringprep profile. Proposed
text: "A preliminary version of a possible stringprep
profile is described in [SASLPREP]."

- Section 1.3: I think it would be simpler if the terminology section
only defined the terms, but would not specify any requirements
for EAP implementations. At least, unnecessary duplication
of those requirements should be avoided. Here are some
proposed changes that would simplify 1.3 somewhat:

- Master Session Key (MSK): delete second paragraph (similar text
was already deleted from 7.10)
- Delete "EAP Master key (MK)": no longer necessary since
the term is not used anywhere.
- Key derivation: Delete the last two sentences (unnecessary
duplication)
- Key strength: Delete (unnecessary duplication, since it's
already specified in main text)
- Extended Master Session Key (EMSK): Proposed replacement:
"Additional keying material that is derived between the EAP
client and server, reserved for future use."
- Cryptographic separation: delete. Instead, add to section 7.10,
4th paragraph, after the first sentence: "That is, knowledge
of one substring MUST NOT help in recovering some other
substring without breaking some hard cryptographic assumption."

[Jari Arkko] - In general I agree with what has been
stated in http://www.drizzle.com/~aboba/EAP/eapissues.html#Issue%20141
and support the proposed changes. However, I think the term "cryptographic
separation" should stay in the document, because the definition
is more precise than the suggested replacement.

Also, regarding the MSK and EMSK, should we instead
move the normative language to the main body, not
delete it completely?

---

From: [email-masked] (Jari Arkko)
Date: Thu, 29 May 2003 22:26:12 +0300

Ok.

--Jari

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