Subject: [eap] Proposed resolution of Issue 204 (for RFC 2284bis)

From: Bernard Aboba <[email-masked]>
Date: Wed, 26 Nov 2003 09:47:43 -0800 (PST)

Issue 204 has been filed against the state machine document, but it has
been an open question as to what effect it would have (if any) on RFC
2284bis.

After looking at the revised section 2.4 "Peer to Peer operation", the
first four paragraphs of the section are about limitations on
peer-to-peer operation, which is somewhat orthogonal to Issue 204.

The next two paragraphs seem to be about a slightly different subject --
whether an authentication is necessary in each direction, which is the
subject of Issue 204.

My suggestion is that we replace the last two paragraphs in Section 2.4,
with the following text:

"Lower layer considerations may dictate whether two EAP authentications,
(one in each direction) are required, rather than a single EAP
method supporting mutual authentication and protected result indications.
These include:

[1] Support for bi-direction session key derivation.  Lower layers such as
IEEE 802.11 only support uni-directional  derivation and transport of
transient session keys. For example, the group-key handshake defined in
[IEEE-802.11i] is uni-directional, since in IEEE 802.11 only the Access
Point (AP) sends multicast traffic. This means that in ad-hoc operation
where either peer may send multicast traffic, two uni-directional
group-key exchanges are required. Due to constraints imposed by the 4-way
unicast key handshake state machine, this also implies two 4-way handshake
and EAP method exchanges.

[2] Support for tie-breaking.  Lower layers such as IEEE 802.11 adhoc
do not support "tie breaking" wherein two hosts initiating authentication
with each other will only go forward with a single authentication. This
implies that even if 802.11 were to support a bi-directional group-key
handshake, then two authentications, one in each direction, might still
occur.

[3] Support for protected result indications.  When an EAP method
supporting mutual authentiation and protected result indication is
in use,  the EAP peer and server will typically be aware of each other's
access decision, as well as their own.  For example, the EAP server will
indicate to the peer whether the peer has successfully authenticated to
it, and the peer will indicate to the EAP server whether the server has
successfully authenticated to the peer. As a result, the EAP peer and
server can determine whether an authentication is required in the
opposite direction.  However, where the authenticator operates as a
pass-through, it will not be aware whether the peer has
accepted the access offered to it by the EAP server unless this
information is provided to it via the AAA protocol.  As a result, two
authentications, one in each direction, may still need to occur."
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Nick Petroni <[email-masked]>
Date: Wed, 26 Nov 2003 12:45:55 -0500 (EST)

> authentications, one in each direction, may still need to occur."

based on this text, a proposed change to the state machine doc would
(roughly) look something like this:

In Figure 5 "EAP Backend Authenticator State Machine", change the
METHOD_RESPONSE state to read

  m.process(aaaEapRespData)
  if (m.isDone()) {
     Policy.update(<...>)
     aaaEapKeyData = m.getKey()
     aaaEapPeerDecision = m.getPeerDecision()
     methodState = END
  } else
    methodState = CONTINUE

aaaEapPeerDecision would take values UNKNOWN, KNOWN_ACCEPT and
KNOWN_REJECT and be exported to the lower layer.

thoughts? any other required changes?

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 26 Nov 2003 10:58:16 -0800 (PST)

> thoughts? any other required changes?

I think this is correct.  The lower layer can then use this variable to
decide whether to initiate EAP authentication in the other direction.

On the peer side, there is also a need to make a decision (as Joe noted).
However there I think that existing interfaces may be adequate because the
peer knows whether it has been granted access and is willing to accept it;
the only question is whether its policy requires an authentication in the
other direction too.  That doesn't seem like a decision that requires
additional interfaces to the lower layer.

---

From: "Joseph Salowey" <[email-masked]>
Date: Wed, 26 Nov 2003 12:54:18 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Bernard Aboba
> Sent: Wednesday, November 26, 2003 9:48 AM
> To: [email-masked]
> Subject: [eap] Proposed resolution of Issue 204 (for RFC 2284bis)
> 
> 
> Issue 204 has been filed against the state machine document, 
> but it has been an open question as to what effect it would 
> have (if any) on RFC 2284bis.
> 
> After looking at the revised section 2.4 "Peer to Peer 
> operation", the first four paragraphs of the section are 
> about limitations on peer-to-peer operation, which is 
> somewhat orthogonal to Issue 204.
> 
> The next two paragraphs seem to be about a slightly different 
> subject -- whether an authentication is necessary in each 
> direction, which is the subject of Issue 204.
> 
> My suggestion is that we replace the last two paragraphs in 
> Section 2.4, with the following text:
> 
> "Lower layer considerations may dictate whether two EAP 
> authentications, (one in each direction) are required, rather 
> than a single EAP method supporting mutual authentication and 
> protected result indications. These include:
> 
> [1] Support for bi-direction session key derivation.  Lower 
> layers such as IEEE 802.11 only support uni-directional  
> derivation and transport of transient session keys. For 
> example, the group-key handshake defined in [IEEE-802.11i] is 
> uni-directional, since in IEEE 802.11 only the Access Point 
> (AP) sends multicast traffic. This means that in ad-hoc 
> operation where either peer may send multicast traffic, two 
> uni-directional group-key exchanges are required. Due to 
> constraints imposed by the 4-way unicast key handshake state 
> machine, this also implies two 4-way handshake and EAP method 
> exchanges.

[Joe] Where is the use of multicast/broadcast defined in the case of an
ad-hoc network? Is it defined in 802.11i?
> 
> [2] Support for tie-breaking.  Lower layers such as IEEE 
> 802.11 adhoc do not support "tie breaking" wherein two hosts 
> initiating authentication with each other will only go 
> forward with a single authentication. This implies that even 
> if 802.11 were to support a bi-directional group-key 
> handshake, then two authentications, one in each direction, 
> might still occur.
> 
> [3] Support for protected result indications.  When an EAP 
> method supporting mutual authentiation and protected result 
> indication is in use,  the EAP peer and server will typically 
> be aware of each other's access decision, as well as their 
> own.  For example, the EAP server will indicate to the peer 
> whether the peer has successfully authenticated to it, and 
> the peer will indicate to the EAP server whether the server 
> has successfully authenticated to the peer. As a result, the 
> EAP peer and server can determine whether an authentication 
> is required in the opposite direction.  However, where the 
> authenticator operates as a pass-through, it will not be 
> aware whether the peer has accepted the access offered to it 
> by the EAP server unless this information is provided to it 
> via the AAA protocol.  As a result, two authentications, one 
> in each direction, may still need to occur." 

[Joe] Here is a suggestion. It may need a little work, but I think it is
more characteristic of the scenario. 

[3] Peer Policy is not satisfied. It is possible that the EAP Peer's
access policy was not satisfied during the EAP-Method exchange, for
example the peer may not have satisfactorily authenticated the
authenticator.  In this case the peer may wish to open another
authentication exchange with the authenticator in the reverse direction.
It is possible for an EAP mechanism to allow the Peer to return a
protected result indicator to indicate that it successfully
authenticated the authenticator.  However, where the authenticator
operates as a pass-through, it will not be aware whether the peer has
accepted the credentials offered to it by the EAP server unless this
information is provided to it via the AAA protocol.  As a result, two
authentications, one in each direction, may still need to occur.  It is
also possible for the peer to require additional authentication in the
reverse direction even if the protected result indicator from the peer
indicated success.  

> ______
_________________________________________

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 26 Nov 2003 14:55:57 -0800 (PST)

How about this?

[3] Peer Policy satisfaction. EAP methods may support
protected result indications, enabling the peer to indicate
to the EAP server that it successfully authenticated it.
However, a pass-through authenticator will not be aware that the peer
has accepted the credentials offered to it by the EAP server, unless
this information is provided to the authenticator via the AAA protocol.
As a result, two authentications, one in each direction, may still need
to occur.

It is also possible that the EAP peer's access policy was not satisfied
during the EAP method exchange. For example, the authenticator may
not have successfully authenticated to the peer, or may not have
demonstrated sufficient authorization to act in multiple roles.
For example, in EAP-TLS [RFC2716], the authenticator may have
authenticated using a valid TLS server certificate, but not using
a valid TLS client certificate. As a result, the peer may require
an additional authentication in the reverse direction, even if
the peer provided a protected result indication to the EAP server
indicating that the server had successfully authenticated to it.
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: "Joseph Salowey" <[email-masked]>
Date: Wed, 26 Nov 2003 15:02:29 -0800

Looks good.

> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Wednesday, November 26, 2003 2:56 PM
> To: Joseph Salowey
> Cc: [email-masked]
> Subject: RE: [eap] Proposed resolution of Issue 204 (for RFC 2284bis)
> 
> 
> How about this?
> 
> However, a pass-through authenticator will not be aware that 
> the peer has accepted the credentials offered to it by the 
> EAP server, unless this information is provided to the 
> authenticator via the AAA protocol. As a result, two 
> authentications, one in each direction, may still need to occur.
> 
> It is also possible that the EAP peer's access policy was not 
> satisfied during the EAP method exchange. For example, the 
> authenticator may not have successfully authenticated to the 
> peer, or may not have demonstrated sufficient authorization 
> to act in multiple roles. For example, in EAP-TLS [RFC2716], 
> the authenticator may have authenticated using a valid TLS 
> server certificate, but not using a valid TLS client 
> certificate. As a result, the peer may require an additional 
> authentication in the reverse direction, even if the peer 
> provided a protected result indication to the EAP server

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 27 Nov 2003 00:59:41 +0100

The first paragraph of the replacement text for the end of 2.4 still reads:

  These include:"

However the list item 3 below seems to me not to really fall into the
category of "Lower layer considerations"?  Mayby the paragraph quoted above
also needs a tweak?

Wednesday 26 November 2003, Bernard wrote:
> Peer Policy satisfaction. EAP methods may support

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 26 Nov 2003 16:27:42 -0800 (PST)

> category of "Lower layer considerations"?  Mayby the paragraph quoted above

Good catch! I've gone ahead and tweaked the resolution to address this.
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap