Subject: RE: [eap] Revised Proposed Resolution to Issue 207: Miscellaneous Comments

From: Bernard Aboba <[email-masked]>
Date: Tue, 6 Jan 2004 12:16:33 -0800 (PST)

> Furthermore, the definition
> of "protected result indication" is so vague that it's not
> easy to determine which current methods actually do that :-)

That is part of what Russ's comment is about, and so I'd suggest that we
need to fix this.

> As Jari already pointed out, some failure indications
> simply can't be protected: if the authentication failed,
> how do you authenticate the result indication?

If you recall, the requirement was originally called "Acknowledged Result
indications", in recognition of the fact that the indications cannot
always be protected.  The text was then changed to "Protected Result
indications" in an attempt to improve clarity, but that seems to have had
the opposite effect :(

> Authenticating only success indications might be more feasible,
> but I don't see any compelling reason to do that.

If mutual authentication and key derivation succeed, then one can assume
that there is an implicit indication of a successful result in the
absence of an error message to the contrary.  So I'd agree that there is
no need for an explicit success indication.

> Acknowledged result indications are quite enough to avoid long timeouts

Yes.

> Therefore, I suggest we keep the old text.

The old text was apparently too vague to be useful, so keeping it probably
won't address all the concerns.

What I think we need is:

a. A definition of "protected result indications" sufficiently clear so
that we can understand if an EAP method provides it.

b. An understanding of whether we need an additional AAA attribute to tell
the authenticator when the peer has successfully authenticated it, or
whether the key attribute (and an Access Accept) is sufficient.

c. What the implications of a) and b) are in terms of method design.
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: <[email-masked]>
Date: Mon, 5 Jan 2004 22:13:13 +0200

Bernard Aboba wrote:
>
> In Section 7.10, change the first paragraph from:
> 
> "It is possible for the peer and EAP server to mutually
> authenticate and derive keys.  In order to provide keying
> material for use in a subsequently negotiated ciphersuite, 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.  EAP Methods
> deriving keys MUST provide for mutual authentication between
> the EAP peer and the EAP Server."
> 
> To:
> 
> "It is possible for the peer and EAP server to mutually
> authenticate and derive keys.  In order to provide keying
> material for use in a subsequently negotiated ciphersuite, 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.
> 
> EAP Methods supporting key derivation MUST also support mutual
> authentication between the EAP peer and the EAP Server.  EAP
> Methods supporting mutual authentication MUST also support key
> derivation and protected result indications."

I am against adding new "MUST" requirements at this stage,
especially if they are not absolutely necessary. 

The requirement that mutually authenticating methods must 
also support key derivation isn't probably that bad (it seems
that currently all do), but not all existing methods have
protected result indications. Furthermore, the definition
of "protected result indication" is so vague that it's not
easy to determine which current methods actually do that :-)

Authenticating only success indications might be more feasible,
but I don't see any compelling reason to do that. Acknowledged
result indications are quite enough to avoid long timeouts
(in case of packet loss), and spoofing them doesn't lead to 
anything worse than DoS anyway.

Best regards,
Pasi