Re: [Emu] Comments on draft-ietf-emu-eap-tunnel-method-05 - Set #2
HI Jim, Thanks for bringing this up. I think it might be better to address this in a separate document since I think it can have more general applicability than TEAP. I'll add this to the TEAP discussion in Orlando. Comments inline below: On Mar 4, 2013, at 6:13 PM, Jim Schaad i...@augustcellars.commailto:i...@augustcellars.com wrote: I have been doing my best not to send this message but it has finally slipped out. I keep wondering if we need to do something much more explicit in terms of both identifying and purposing the certificates that are being used for this method. Question #1 – Do we expect that the client certificates would only be used for this purpose and not for general purpose TLS client authentication? I would be shocked if this was not true for the server certificates. If so does this mean that we should define an EKU for the purpose of doing EAP Tunnel Method (allow it to be used for all of the previous and future versions thus being generic)? [Joe] Both cases exist in deployments today, there are cases where server and client certificates are used for both HTTPS and EAP. It is more common on the client side. I believe EAP-TLS specifies the same EKUs as TLS for HTTP. I've always found it a bit strange, but I don't think ti has presented a serious deployment issue. I think it would be reasonable to define a new EKU, but I'd like to understand how it would or wouldn't work with what is out there. Question #2 – Do we want to try and solve the question Sam has raised about naming of entities in certificates. This would mean defining a new OtherName extension to PKIX for the purpose of placing NAIs into certificates. This would allow for an NAI of the form “@realm” to be placed in a server certificate to define that it is the EAP server for the realm. This does assume that there will not be two different servers which are disjoint servicing the same realm but that would be a very unusual case. [Joe] Being able to identify the realm and NAI would be good. For the realm does this need to be distinct from DNS name? Jim ___ Emu mailing list Emu@ietf.orgmailto:Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu ___ 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
Re: [Emu] Comments on draft-ietf-emu-eap-tunnel-method
On Mar 1, 2013, at 7:15 AM, Sam Hartman hartmans-i...@mit.edu wrote: Jim == Jim Schaad i...@augustcellars.com writes: There doesn't seem to be a way for a server to request channel binding. If that's true we should probably add the following: Since a server cannot indicate a desire for channel binding, clients that Jim have channel binding data to send SHOULD include channel-binding TLV in a request-action TLV if mutual authentication (section 3.11) succeeded. Jim If this is true - then I agree it is a flaw. Jim I think that one could send a channel-binding TLV with no data Jim to request that a client send channel binding data back. This Jim should not cause any significant problems. If that's permitted then it should be explicitly documented. I think that if this is permitted, everyone who implements channel binding needs to be required to support this. Jim One could then have Channel-binding server-peer - no data Jim Channel-binding peer-server - here is my data Channel-binding Jim server-peer - here is my data Again, let's document this if it is permitted. It's clear the spec is unclear if you and I read if differently. [Joe] THis is a reasonable request. We'll need to make sure there is no ambiguity in the use of the empty message. Should this be covered in RFC 6677? Jim However I believe that the client can initiate this by just Jim sending the channel binding TLV in the clear and not in a Jim request if the client wants to initiate it. My reading is that you cannot send a channel binding outside of a request. This needs clarification as well if we're reading it differently. [Joe] I'm not sure what you are asking here. What is meant be sending the CB TLV in the clear and not in a request? do you mean a request-action TLV? ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Comments on draft-ietf-emu-eap-tunnel-method
Joseph == Joseph Salowey (jsalowey) jsalo...@cisco.com writes: [Joe] THis is a reasonable request. We'll need to make sure there is no ambiguity in the use of the empty message. Should this be covered in RFC 6677? RFC 6677 doesn't talk about how you decide you're going to do channel binding. I had mostly assumed you'd throw it in with some other message I guess, although once you consider crypto binding that gets more complex because you want CB after crypto binding some of the time. Note that I'm not requesting any specific behavior. I'm simply requesting that you document either that a server cannot request CB (must start with client) or document how a server requests cb. The message defined in RFC 6677 always has a code, so an empty message is clearly not a 6677 message. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Comments on draft-ietf-emu-eap-tunnel-method
-Original Message- From: Sam Hartman [mailto:hartmans-i...@mit.edu] Sent: Monday, March 04, 2013 6:19 PM To: Joseph Salowey (jsalowey) Cc: Sam Hartman; Jim Schaad; emu@ietf.org Subject: Re: [Emu] Comments on draft-ietf-emu-eap-tunnel-method Joseph == Joseph Salowey (jsalowey) jsalo...@cisco.com writes: [Joe] THis is a reasonable request. We'll need to make sure there is no ambiguity in the use of the empty message. Should this be covered in RFC 6677? RFC 6677 doesn't talk about how you decide you're going to do channel binding. I had mostly assumed you'd throw it in with some other message I guess, although once you consider crypto binding that gets more complex because you want CB after crypto binding some of the time. Note that I'm not requesting any specific behavior. I'm simply requesting that you document either that a server cannot request CB (must start with client) or document how a server requests cb. The message defined in RFC 6677 always has a code, so an empty message is clearly not a 6677 message. I agree - this is behavior that is described in this document and not in RFC 6677 - this is a how do you do it not a what is included type question. Jim ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] Comments on draft-ietf-emu-eap-tunnel-method-05 - Set #2
I have been doing my best not to send this message but it has finally slipped out. I keep wondering if we need to do something much more explicit in terms of both identifying and purposing the certificates that are being used for this method. Question #1 - Do we expect that the client certificates would only be used for this purpose and not for general purpose TLS client authentication? I would be shocked if this was not true for the server certificates. If so does this mean that we should define an EKU for the purpose of doing EAP Tunnel Method (allow it to be used for all of the previous and future versions thus being generic)? Question #2 - Do we want to try and solve the question Sam has raised about naming of entities in certificates. This would mean defining a new OtherName extension to PKIX for the purpose of placing NAIs into certificates. This would allow for an NAI of the form @realm to be placed in a server certificate to define that it is the EAP server for the realm. This does assume that there will not be two different servers which are disjoint servicing the same realm but that would be a very unusual case. Jim ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Comments on draft-ietf-emu-eap-tunnel-method
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. 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 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
[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. 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: 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. Section 4.2.7: Replace the definition of data with The data field contains a channel-binding message as defined in section 5.3 of RFC 6677. Will the channel binding data (client to server) ever be outside of a request-action TLV? If not, it's probably worth pointing this out. There doesn't seem to be a way for a server to request channel binding. If that's true we should probably add the following: Since a server cannot indicate a desire for channel binding, clients that have channel binding data to send SHOULD include channel-binding TLV in a request-action TLV if mutual authentication (section 3.11) succeeded. section 7.3: Please update
