Subject: [eap] Proposed Resolution to Issue 234: Comments

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

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

1) A security considerations section has been added. See the resolution of
Issue 225.

2) Other proposed resolutions will promote more requirements to a SHOULD,
so I think this is addressed.

3) See resolution of Issue 224.

4) Discuss this in IEEE 802.11i.

5) The PSK mode vulnerability exists in part because there is no
mandatory-to-implement EAP method satisfying the dictionary attack
requirement. Therefore the solution is to encourage
development of methods that conform to it.

-----------------------------------------------------------------------
Issue 234: Comments
Submitter name: Pasi Eronen
Submitter email address: [email-masked]
Date first submitted: 3/25/2004
Reference:
http://mail.frascone.com/pipermail/public/eap/2004-March/002400.html
Document: draft-walker-ieee802-req-00
Comment type: T/E
Priority: S/1
Section: various
Rationale/Explanation of issue:

1) Security considerations

The draft does not have a "security considerations" section.
I think this section should provide at least a brief rationale
about why the requirements are what they are.  In some cases,
the reasons are fairly obvious; in other cases, it is not
immediately clear why a system not meeting that requirement
would be unacceptable.

2) Conditional compliance

Section 1.1 defines the terms "unconditionally compliant" and
"conditionally compliant". Since the draft includes only one
SHOULD level requirement (about fragmentation), I do not think
this distinction adds any value to the document.

3) Synchronization of state

I agree with Joe Salowey's comment in issue 224 that protected
result indications and synchronization of state don't have much
to do with each other.  Joe's proposed text looks basically OK,
but I am not sure whether it is actually necessary. Much of it
just attempts to capture what being a "not totally flawed"
authentication method means.

I also agree with 2284bis's conclusion that protected result
indications do not add any significant value in 802.11 use, so
IMHO they should not be required.

4) Cryptographic bindings

A strict reading of the draft would suggest that, for instance,
OTP-over-PEAPv1 would not be acceptable while OTP-over-PEAPv2
would be. This is because PEAPv1 does not have "cryptographic
bindings". However, both cases are actually equally secure since
OTP does not generate a key: so actually PEAPv2 does not have
"cryptographic binding" in this case either...

IMHO this case does not have so severe security problems that it
should be prohibited. As noted in 2284bis section 7.4, there are
other valid approaches that prevent the MitM attack, including
policies about when to use which methods.  Also, 2284bis already
requires that "tunneled methods MUST support protection against
man-in-the-middle attacks" (section 2.1), presumably meaning
that policy is one possible way to support this.

How about "When a tunnel method is used with "inner" methods
that support key derivation, the tunnel method SHOULD support
the "cryptographic binding" claim."? Or perhaps no text
is required here since 2284bis already has the MUST requirement
relating to this?

5) Dictionary attacks

There are good reasons to prohibit methods vulnerable to
dictionary attacks, but IMHO those same reasons apply
equally to 802.11i PSK mode. Perhaps this apparent
contradiction should be somehow justified, or maybe
changed to a "SHOULD NOT"?
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap