Subject: [eap] Proposed Resolution to Issue 227: Corrections

From: Bernard Aboba <[email-masked]>
Date: Mon, 10 May 2004 20:25:57 -0700 (PDT)

The text of Issue 227 is enclosed below.  The proposed resolution is as
follows:

Drop the term "Draft" and refer to [RFC3748] instead of [RFC2284bis].

Accept the proposed editorial changes.

Leave "Channel Bindings" as a MAY.  This is still an experimental
facility.

Leave optional capabilities as is.

------------------------------------------------------------------------
Issue 227: CorrectionsSubmitter name: Russ Housley
Submitter email address: [email-masked]
Date first submitted: 2/27/2004
Reference:
Document: EAP-WLAN-00
Comment type: 'T'echnical
Priority: S
Section: Various
Rationale/Explanation of issue:
Abstract

The Draft IEEE 802.11i MAC Security Enhancements Amendment makes use of

[ It is clear that 802.11i will be approved soon and depend on EAP.
Since this document will live forever, it might be better to drop
'Draft.' Alternatively, we could wait until 802.11i is published. ]

2.1. Credential types

The Draft IEEE 802.11i MAC Security Enhancements Amendment requires that
EAP authentication methods are available. Wireless LAN deployments are
expected to use different credentials types, including digital
certificates, user-names and passwords, existing secure tokens, and
mobile network credentials (GSM and UMTS secrets). Other credential
types that may be used include public/private key (without necessarily
requiring certificates), and asymmetric credential support (password on

[ s/password/such as password/ ]

[1] Generation of keying material. This corresponds to the "Key

[ s/keying/symmetric keying/ ]

derivation" security claim defined in [RFC2284bis], Section 7.2.1.

[7] Key strength. An EAP method suitable for use with IEEE 802.11 MUST
be capable of generating keying material with 128-bits of effective
key strength, as defined in [RFC2284bis] Section 7.2.1. As noted
in [RFC2284bis] Section 7.10, an EAP method supporting key
derivation MUST export a Master Session Key (MSK) of at least 64
octets, and an Extended Master Session Key (EMSK) of at least 64
octets.

[ This should probably be placed after [1] so that discussion of key
derivation are next to each other. ]

2.4. Optional features

EAP authentication methods used for wireless LAN authentication MAY
support the following features:

[ Do we want to say that they are desirable? Or, say that they are
useful in some environments? ]

[9] Channel binding. This corresponds to the "Channel binding"
security claim defined in [RFC2284bis], Section 7.2.1.

[ Why isn't [9] a SHOULD? I know that none of the current EAP methods
give it to use, but it might be good to push for it. ]
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap