Subject: [eap] Re: Issue 222: Synchronized State

From: Bernard Aboba <[email-masked]>
Date: Tue, 10 Feb 2004 11:37:27 -0800 (PST)

The way I read the proposed text, it would require *all* EAP methods to
satisfy the conditions stated below.  Is this is what is intended?  Or is
the goal to create a new Security Claim "Synchronized State"?

Comments below.

"Synchronized State

At the completion of an EAP authentication method the Peer and Server
MUST have the same notion of state related to the authentication.

[BA] I think you need define "state" very clearly.  Is this limited to the
protocol executed, credentials presented/accepted, keys derive, and
instance?

Successful authentication MUST NOT result in a situation where both
parties believe the authentication succeeded, but have different notions
of state including; the protocol both executed, what credentials were
presented and accepted by both parties, what keys both have derived, and
how to distinguish this instance of the protocol from all other
instances of the protocol.

[BA] An EAP method can only guarantee sync of the protocol
executed if it includes the Type field within a MIC. Otherwise there are
"protocol translation" attacks that can be executed.

They MUST also share the same view of
negotiable attributes of the EAP method specific protocol, such as
cipher suites, limitations of usage on all protocol state, and the same
view of what attributes of the protocol instance are public and which
are private to the two parties alone.

[BA] I assume this means "EAP method-specific ciphersuite", no?  This
requirement appears to boil down to the need for a protected two-way
negotiation between the parties.

If the peer and the server do not
share the same notion of state then either or both of the parties MUST
fail the authentication and MUST NOT generate keys for export out of the
method."

[BA] I think this part makes sense, assuming that the definition of
"state" can be nailed down.
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: "Joseph Salowey" <[email-masked]>
Date: Tue, 10 Feb 2004 17:14:34 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Bernard Aboba
> Sent: Tuesday, February 10, 2004 11:37 AM
> To: [email-masked]
> Subject: [eap] Re: Issue 222: Synchronized State
> 
> 
> The way I read the proposed text, it would require *all* EAP 
> methods to satisfy the conditions stated below.  Is this is 
> what is intended?  Or is the goal to create a new Security 
> Claim "Synchronized State"?
> 
[Joe] Should either be a new security claims section or just included in
the 802.11 requirements.

> Comments below.
> 
> "Synchronized State
> 
> At the completion of an EAP authentication method the Peer 
> and Server MUST have the same notion of state related to the 
> authentication.
> 
> [BA] I think you need define "state" very clearly.  Is this 
> limited to the protocol executed, credentials 
> presented/accepted, keys derive, and instance?
> 
[Joe] This is the state associated with the completed authentication.
The list must also include negotiated parameters. This is from a list
that Jesse sent out in his explanation of the 802.11i requirements.
Nailing down exactly what the state is will be a little tricky, but I
agree it is key.  

> Successful authentication MUST NOT result in a situation 
> where both parties believe the authentication succeeded, but 
> have different notions of state including; the protocol both 
> executed, what credentials were presented and accepted by 
> both parties, what keys both have derived, and how to 
> distinguish this instance of the protocol from all other 
> executed if it includes the Type field within a MIC. 
> Otherwise there are "protocol translation" attacks that can 
> be executed.
> 

[Joe] It seems that the EAP-type number is external to the specific
authentication protocol itself and that a the two sides could have other
means of knowing that they executed the same protocol.  But I think you
may be right that to have a general solution you would have to include
the method type field in the MIC.   This could be problematic for some
current proposed methods.  

> negotiable attributes of the EAP method specific protocol, 
> such as cipher suites, limitations of usage on all protocol 
> state, and the same view of what attributes of the protocol 
> instance are public and which are private to the two parties alone.
> 
> [BA] I assume this means "EAP method-specific ciphersuite", 
> no?  This requirement appears to boil down to the need for a 
> protected two-way negotiation between the parties.
> 

[Joe] Yes. 

> share the same notion of state then either or both of the 
> parties MUST fail the authentication and MUST NOT generate 
> keys for export out of the method."
> 
> [BA] I think this part makes sense, assuming that the 
> definition of "state" can be nailed down.

[Joe] Agree.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 10 Feb 2004 18:22:15 -0800 (PST)

> [Joe] Should either be a new security claims section or just included in

My understanding is that the 802.11 requirements document will be going to
IETF last call, which will provide the opportunity for commenting on the
document.  Unless the text provides general value, I'd prefer that it be
put into the IEEE 802.11 requirements document, particularly since
defining the exact meaning of "state" could take a while.  Look how long
it has taken to achieve clarity on the meaning (and usefulness) of
protected result indications :)

Of course, the decision to put text into the IEEE 802.11 requirements
document is a decision of IEEE 802.11, not the EAP WG, but in any case
putting the text into RFC 2284bis won't help unless it is referenced in
the IEEE 802.11 requirements doc.
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Jari Arkko <[email-masked]>
Date: Wed, 11 Feb 2004 10:37:26 +0200

> the IEEE 802.11 requirements doc.

I would also note that there are likely many useful security properties
which are not listed in 2284bis, and it would be hard to ensure that all
these properties are put there. (In particular, it might take a long time
and we'd like to get the doc published.)

For instance, I suspect that in some environments, IKEv2-class DoS
protection property would be useful. But we have not defined anything
like that in 2284bis. Link layer folks who want such features can and
should use also their own list of properties, not just the ones defined
in 2284bis.

--Jari

---

From: "Joseph Salowey" <[email-masked]>
Date: Wed, 11 Feb 2004 08:25:53 -0800

> From: Jari Arkko [mailto:[email-masked]] 
> Sent: Wednesday, February 11, 2004 12:37 AM
> To: Bernard Aboba
> Cc: Joseph Salowey; [email-masked]
> Subject: Re: [eap] Re: Issue 222: Synchronized State
> 
> 
> Bernard Aboba wrote:
> >>[Joe] Should either be a new security claims section or 
> just included 
> >>in the 802.11 requirements.
> > 
> > 
> > My understanding is that the 802.11 requirements document will be 
> > going to IETF last call, which will provide the opportunity for 
> > commenting on the document.  Unless the text provides 
> general value, 
> > I'd prefer that it be put into the IEEE 802.11 requirements 
> document, 
> > particularly since defining the exact meaning of "state" 
> could take a 
> > while.  Look how long it has taken to achieve clarity on 
> the meaning 
> > (and usefulness) of protected result indications :)
> > 
> > putting the text into RFC 2284bis won't help unless it is 
> referenced 
> > in the IEEE 802.11 requirements doc.
> 
> I would also note that there are likely many useful security 
> properties which are not listed in 2284bis, and it would be 
> hard to ensure that all these properties are put there. (In 
> particular, it might take a long time and we'd like to get 
> the doc published.)
> 
> For instance, I suspect that in some environments, 
> IKEv2-class DoS protection property would be useful. But we 
> have not defined anything like that in 2284bis. Link layer 
> folks who want such features can and should use also their 
> own list of properties, not just the ones defined in 2284bis.
> 

[Joe] I agree, that it is probably better to explain this in the 802.11
requirements.  I'll send some suggested text to the authors and eap
list.

---

From: Jari Arkko <[email-masked]>
Date: Wed, 11 Feb 2004 21:14:10 +0200

I re-read the security claims part of RFC 2284bis and this issue.
I think it makes most sense to put the 802.11 requirements, whatever
they are, in their document. However, it appears that RFC 2284bis
talks about the claims as if they were the only possible security
properties worth talking about. This is obviously not the case.
Perhaps we could close 222 by adding the following paragraph
to the end of 7.2.1:

    Note that this list of properties is not exhaustive. Additional
    properties, such as specific forms of denial-of-service protection,
    may be relevant as well.

--Jari

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 12 Feb 2004 16:32:05 -0800 (PST)

Fine by me.