Subject: [Emu] Proposed Resolution: EMU Issue track #36

From: Hao Zhou <[email-masked]>
Date: Tue, 21 Feb 2012 11:42:28 -0500

http://trac.tools.ietf.org/wg/emu/trac/ticket/36

Old Text:
³In the case of multiple peer authentications, the Peer-ID is determined
from the first peer authenticatication.²

New Text:
³In the case of multiple peer authentications, all authenticated peer
identities need to be exported. ²

Rational:
It is desirable to export all peer identities that have been authenticated
by the tunnel method. And there is no limit to the number of peer identities
being exported, provided the interface is available.

RFC 5247, EAP Keying Framework says:

³It is possible for more than one Peer-Id to be exported by an EAP
   method.  For example, a peer certificate can contain more than one
   peer identity; in a tunnel method, peer identities can be
   authenticated within both an outer and inner exchange, and these
   identities could be different in type and contents.  For example, an
   outer exchange could provide a Peer-Id in the form of a Relative
   Distinguished Name (RDN), whereas an inner exchange could identify
   the peer via its NAI or MAC address.  Where EAP keying material is
   determined solely from the outer exchange, only the outer Peer-Id(s)
   are exported; where the EAP keying material is determined from both
   the inner and outer exchanges, then both the inner and outer
   Peer-Id(s) are exported by the tunnel method.²

---

From: Hao Zhou <[email-masked]>
Date: Tue, 21 Feb 2012 11:55:01 -0500

http://trac.tools.ietf.org/wg/emu/trac/ticket/37
Clarify that if peer only supports a higher version than the server
supports, peer should send  a NAK with other proposed EAP method if
available. 

Old Text:
³If the TEAP peer does not support this version, it responds with
      an EAP-Response of EAP type=TEAP and the highest supported version
      number that's less than the number proposed by the TEAP server.²

New Text:
³If the TEAP peer does not support this version but supports the version
that¹s lower than the version proposed by the TEAP server, it responds with
      an EAP-Response of EAP type=TEAP and the highest supported version
number. If the TEAP peer only supports the version that¹s higher than the
version proposed by the TEAP server, then use of TEAP will not be possible.
In this case, the TEAP peer should send  back an EAP-Nak with other proposed
EAP method if available.²

---

From: Hao Zhou <[email-masked]>
Date: Tue, 21 Feb 2012 12:40:53 -0500

http://trac.tools.ietf.org/wg/emu/trac/ticket/38
Clarify that crypto-binding TLV will always be run after every single EAP
authentication, also even if there is no inner EAP authentication or, to
ensure the outer TLVs and EAP type, version are verified.

TEAP draft 01, 
http://tools.ietf.org/html/draft-ietf-emu-eap-tunnel-method-01

Section 3.3
Old text:
³Phase 2 MUST always end with a protected termination exchange described in
Section 3.3.3. ³

New Text:
³Phase 2 MUST always end with a crypto-binding TLV exchange descried in
Section 4.2.9 and protected termination exchange described in Section 3.3.3.
³

Section 4.2.9:

Old Text:
³The Crypto-Binding TLV is used to prove that both the peer and server
   participated in the tunnel establishment and sequence of
   authentications.  It also provides verification of the TEAP version
   negotiated before TLS tunnel establishment, see Section 3.1 .

  The Crypto-Binding TLV MUST be included with the Intermediate-Result
   TLV to perform Cryptographic Binding after each successful EAP method
   in a sequence of EAP methods.  The Crypto-Binding TLV can be issued
   at other times as well.²

New Text:
³The Crypto-Binding TLV is used to prove that both the peer and server
   participated in the tunnel establishment and sequence of
   authentications.  It also provides verification of the TEAP type, version
   negotiated, outer TLVs exchanged before the TLS tunnel establishment.

  The Crypto-Binding TLV MUST be exchanged and verified before the final
Result TLV exchange, regardless whether there is an inner EAP method
authentication or not. It MUST be included with the Intermediate-Result
   TLV to perform Cryptographic Binding after each successful EAP method
   in a sequence of EAP methods, before proceeding with another inner EAP
method.²