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 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. > > If this is true - then I agree it is a flaw. > > I think that one could send a channel-binding TLV with no data to request > that a client send channel binding data back. This should not cause any > significant problems. > > One could then have > Channel-binding server->peer - no data > Channel-binding peer->server - here is my data > Channel-binding server->peer - here is my data > > However I believe that the client can initiate this by just sending the > channel binding TLV in the clear and not in a request if the client wants to > initiate it. > >> >> section 7.3: >> Please update references to draft-hartman-emu-mulutal-crypto-bind to >> draft-ietf-emu-mutual-crypto-bind >> >> >> section 7.6: >> >> Replace peer MUST validate with peer SHOULD validate. 3.10 is an example >> where the peer SHOULDN't validate, and no one is going to make that a >> MUST so let's not lie. I'd also like to see the requirement for >> implementations to support matching the realm of a NAI against a dns name >> in the subjectAltName to be a MUST not a SHOULD. I think we have strong >> evidence that we need an interoperable way to name EAP servers. >> Note that's MUST implement, not MUSt use. >> >> --Sam >> _______________________________________________ >> 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 _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
