[Emu] Proposed Resolution: EMU Issue track #36
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.² ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] Proposed Resolution: EMU Issue track #38
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.² ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] Proposed Resolution: EMU Track Issue #40
http://trac.tools.ietf.org/wg/emu/trac/ticket/40 Channel Binding TLV should match Channel Binding Spec. clarify that channel binding tlv can be used bidirectional to transmit channel back data and verification result. TEAP draft 01, http://tools.ietf.org/html/draft-ietf-emu-eap-tunnel-method-01 Section 4.2.15 Old text: ³The Channel-Binding TLV allows an EAP-peer to send channel binding data to the EAP-server as described in [I-D.ietf-emu-chbind] . ³ New Text: ³The Channel-Binding TLV provides a mechanism for carrying channel binding data from the peer to the EAP server and a channel binding response from the EAP server to the peer as described in [I-D.ietf-emu-chbind]. ³ ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] Proposed resolution: EMU Issue track #34
http://trac.tools.ietf.org/wg/emu/trac/ticket/34 Dan proposed text for server unauthenticated provisioning. This is still in discussion on the list and has not be incorporated into the the draft. TEAP draft 01, http://tools.ietf.org/html/draft-ietf-emu-eap-tunnel-method-01 Section 3.2 Old text: Other ciphersuites MAY be supported. It is RECOMMENDED in the case when the inner authentication method provides man-in-the-middle protection [Editor's Note: The use of Anonymous Cipher Suites is still under discussion on the list]. New Text: Other ciphersuites MAY be supported. It is REQUIRED that anonymous ciphersuites such as TLS_DH_anon_WITH_AES_128_CBC_SHA only be used in the case when the inner authentication method provides mutual authentication, key generation, and resistance to to man-in-the-middle and dictionary attack. Suggest to leave the Server Unauthenticated Provisioning Mode to another document. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
