eap Mailing List: Comments about draft-walker-ieee802-req-00

[Pasi.Eronen (Pasi.Eronen]

Submitter name: Pasi Eronen
Submitter email address: pasi.eronen [at] nokia.com
Date first submitted: 25.3.2004
Reference: 
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"?

Best regards,
Pasi