Re: [Emu] Last call comments on emu-eap-tunnel-method-05
On Feb 21, 2013, at 1:10 PM, Jim Schaad jim...@augustcellars.com wrote: I have no comments that I would consider to be blocking. There are couple of issues that should be considered to be dealt with in the last call. Jim 1. Lower case must/may in the document. There are disputes about the role of a lower case must in a document. Some people consider it to be an RFC 2119 usage and some people don't. If it is then these all need to be looked at, if it doesn't then I would suggest putting in text as part of the RFC2119 boiler plate to say that lower case versions of these words have their natural language meaning. [Joe] Thanks, well look at this and try to make the usage consistent with 2119 and move other usages to different words 2. I am not completely clear on this, but don't know if it needs to be clarified. Server and client rune one inner EAP method. Server sends Crypto-Binding TLV and Result TLV Client sends Crypto-Binding TLV, Request-Action TLV [Negotiate EAP] Server sends EAP-Payload [EAP start method] Does the server also needs to send an Intermediate-Result TLV per section 3.3.1? Note - in section 3.3.3 - it would appear that there is a may recommendation that the server actually send Crypt-Binding TLV, Intermediate-Result TLV, Result TLV thus making the problem not a problem. However this is not required behavior. [Joe] This needs to be clarified. Even if there is only one inner method the server needs to send and intermediate result TLV. How about OLD (section 3.3) 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. NEW The Crypto-Binding TLV and Intermediate-Result TLV MUST be included to perform Cryptographic Binding after each successful EAP method in a sequence of one or more EAP methods. 3. Not completely sure the second to last paragraph in 3.3 is correct. Should the server return the EAP success or failure based on the peer's result TLV or the peer's request-action tlv? I think that either could be a correct answer I just want to verify that the text presented is correct. [Joe] Good catch: OLD If the server ignores the request, it proceeds with termination of the tunnel and send the clear text EAP Success or Failure message based on the value of the peer's result TLV. NEW If the server ignores the request, it proceeds with termination of the tunnel and send the clear text EAP Success or Failure message based on the status field of the peer's request-action TLV. 4. Last chance to change our minds and allocate an extra flag in section 4.2.1 just in case we needed it. I have no idea which is going to be the more scarce resource. But only one reserve flag might be an issue. [Joe] I think it would be preferable to keep the current format that is used by other methods. 5. It is technically incorrect to say that the TLV Type is two octets (section 4.2.2). I don't know that there is any reason to correct this as it is essentially correct. Just a we need to be sure we don't want to fix it. (Note: text is different in section 4.2.2) [Joe] OK 6. section 4.2.13 - I think that the received version number is supposed to say set to the TEAP version number received not the EAP version number [Joe] Correct 7. section 4.3 s/multiple multiple Basic/multiple Basic/ [Joe] OK 8. Section 5.2 There are two possible confusions that could result in the computation of the text string for the IMSK a) It is possible that the string \0 could be misinterpreted. This could be stated as 0x00. b) It is possible that the 64 could be misinterpreted as being longer than a byte and thus could be stated as 0x40. (Oops just looked at the referenced document and it is 0x00 0x40). Not clear if this really needs to be changed. [Joe] We could add the note from 5295 where: | denotes concatenation EMSK consists of the 4 ASCII values for the letters \0 = is a NULL octet (0x00 in hex) length is the 2-octet unsigned integer 8 in network byte order 9. Section 5.2 - s/thendoesn/?/ [Joe] s/thendoesn/then ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Comments on draft-ietf-emu-eap-tunnel-method
On Feb 23, 2013, at 5:46 PM, Sam Hartman hartmans-i...@mit.edu wrote: First, the document has been improved a lot in its clarity since the last time I read it. I'd really like to thank the editors, Jim and everyone else who gave comments for some excellent work. TEAP is by far the best EAP method I've ever reviewed, and I think security of EAP conversations would be significantly improved if people implement and deploy TEAP. Section 3.4: Does the server_id depend on whether the identifier is actually authenticated? That is, let's say the server is using a certificate but the client has no way to validate the certificate back to a trust anchor. However, the client uses some strong inner method and EMSK-based crypto binding to verify the server. Does the subject from the server cert make its way into the server ID in this case? [Joe] Section 3.4 says all authenticated identities so in this case I would not expect it to make its way into the server ID. Is it important that implementations get binary identical strings for server_id on both sides of the conversation? [Joe] I don't think the server_id is used in the protocol or on the wire, so its encoding is a local matter. I don't think both sides need to have binary identical strings. I think the text in 3.4 is sufficient that you'd get the right security properties out of the identity, but I suspect different implementations could get slightly different encoding etc. I have never used peer id, server id or session id, so I'm not sure if anyone cares about that. 3.5: old: tls_unique = tls_unique for the phase 1 outer tunnel as defined by [RFC5929]. new: tls_unique = tls_unique for the phase 1 outer tunnel at the beginning of phase 2 as defined by section 3.1 of [RFC5929]. rationale: The quantity described in section 3.1 of rfc 5929 can change when there is TLS renegotiation. This should avoid that. [Joe] Looks good. To be clear if there is re-negotiation then the re-negotiated TLS unique will be used. Section 3.8-3.10: All of these sections involve peer services in the terms of draft-ietf-abfabf-emu-crypto-bind. I believe the advice in section 4.2 of draft-ietf-emu-crypto-bind applies quite strongly here. In particular, the peer MUST track whether it has authenticated the server. There's text repeated at various points in the TEAP spec that tries to say this, including some text in 3.8 and a hint at 3.10. I think this needs to be more unified. In particular I propose that: * A new section 3.11 titled Mutual Authentication for Peer Services be added: Several TEAP services including server unauthenticated provisioning, PAC provisioning, certificate provisioning and channel binding depend on the peer trusting the TEAP server. Peers need to mutually authenticate the server before these peer services are used. TEAP peers MUST track whether mutual authentication has taken place. Mutual authentication results if the peer trusts the provided server certificate belongs to the server; typically this involves both validating the certificate to a trust anchor andconfirming the entity named by the certificate is the intended server. Mutual authentication also results when the procedures of section 3.3 are used to resume a session in which the server was previously mutually authenticated. Alternatively, if an inner EAP method providing mutual authentication and an Extended Master Session Key (EMSK) is executed and cryptographic binding with the EMSK compound MAC present (section 4.2.13), then the session is mutually authenticated and peer services can be used. TEAP implementations SHOULD Not use peer services by default unless the session is mutually authenticated. TEAP implementations SHOULD have a configuration where authentication fails if mutual authentication cannot be achieved. An additional complication arises when a tunnel method authenticates multiple parties such as authenticating both the peer machine and the peer user to the EAP server. Depending on how mutual authentication is achieved, only some of these parties may have confidence in it. For example if a strong shared secret is used to mutually authenticate the user and the EAP server, the machine may not have confidence that the EAP server is the authenticated party if the machine cannot trust the user not to disclose the shared secret to an attacker. In these cases, the parties who have achieved mutual authentication need to be considered when evaluating whether to use peer services./t * Section 3.8-3.10 explicitly refer to this new section. Some of the text about server authentication already present in these sections can be removed. * The channel binding TLV and the request-action TLV should also refer to 3.11. [Joe] This is a good suggestion. I'm not sure how exactly to incorporate the text into the document at this
Re: [Emu] Comments on draft-ietf-emu-eap-tunnel-method
On Feb 27, 2013, at 7:39 PM, Jim Schaad i...@augustcellars.com wrote: Sam, My responses are inline. May not agree with the authors however. Jim -Original Message- From: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On Behalf Of Sam Hartman Sent: Saturday, February 23, 2013 5:47 PM To: emu@ietf.org Subject: [Emu] Comments on draft-ietf-emu-eap-tunnel-method First, the document has been improved a lot in its clarity since the last time I read it. I'd really like to thank the editors, Jim and everyone else who gave comments for some excellent work. TEAP is by far the best EAP method I've ever reviewed, and I think security of EAP conversations would be significantly improved if people implement and deploy TEAP. Section 3.4: Does the server_id depend on whether the identifier is actually authenticated? That is, let's say the server is using a certificate but the client has no way to validate the certificate back to a trust anchor. However, the client uses some strong inner method and EMSK-based crypto binding to verify the server. Does the subject from the server cert make its way into the server ID in this case? Is it important that implementations get binary identical strings for server_id on both sides of the conversation? I think the text in 3.4 is sufficient that you'd get the right security properties out of the identity, but I suspect different implementations could get slightly different encoding etc. I have never used peer id, server id or session id, so I'm not sure if anyone cares about that. I would expect that the id from the certificate would be returned if the inner method provided mutual authentication and the crypto bindings were successful. At that point one would have a statement about the certificate that says it matches that of any server id stated inside of the tunnel. The certificate would be the one presented by the certificate - could not change without TLS failing. The channel binding would give you validation of the tunnel and mutual auth would give you validation of the server. [Joe] My inclination is to not export the certificate ID in this case. If it is the same as a inner method ID then it will already be exported. If its different its not clear that the name in the certificate should be used for any purpose. I think it would be OK to store the certificate or its associated public key to validate future connections. I don't know what it would be to have binary identical strings on both sides. Only the peer side would get server ids and only the server side would get peer ids. As with you I have never used the ids - so I would not know what they are used for in general either. 3.5: old: tls_unique = tls_unique for the phase 1 outer tunnel as defined by [RFC5929]. new: tls_unique = tls_unique for the phase 1 outer tunnel at the beginning of phase 2 as defined by section 3.1 of [RFC5929]. rationale: The quantity described in section 3.1 of rfc 5929 can change when there is TLS renegotiation. This should avoid that. Section 3.8-3.10: This is a reasonable change. All of these sections involve peer services in the terms of draft-ietf-abfabf- emu-crypto-bind. I believe the advice in section 4.2 of draft-ietf-emu-crypto-bind applies quite strongly here. In particular, the peer MUST track whether it has authenticated the server. There's text repeated at various points in the TEAP spec that tries to say this, including some text in 3.8 and a hint at 3.10. I think this needs to be more unified. In particular I propose that: * A new section 3.11 titled Mutual Authentication for Peer Services be added: Several TEAP services including server unauthenticated provisioning, PAC provisioning, certificate provisioning and channel binding depend on the peer trusting the TEAP server. Peers need to mutually authenticate the server before these peer services are used. TEAP peers MUST track whether mutual authentication has taken place. Mutual authentication results if the peer trusts the provided server certificate belongs to the server; typically this involves both validating the certificate to a trust anchor andconfirming the entity named by the certificate is the intended server. Mutual authentication also results when the procedures of section 3.3 are used to resume a session in which the server was previously mutually authenticated. Alternatively, if an inner EAP method providing mutual authentication and an Extended Master Session Key (EMSK) is executed and cryptographic binding with the EMSK compound MAC present (section 4.2.13), then the session is mutually authenticated and peer services can be used. TEAP implementations SHOULD Not use peer services by default unless the session is mutually authenticated. TEAP implementations SHOULD have a configuration where
Re: [Emu] Comments on draft-ietf-emu-eap-tunnel-method
OK. Based on your description of how peer and server ID are used, I have no concerns about 3.4. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
