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 point. Maybe we should have a section "3.8 Peer Services" which has this text and have the original 3.8-3.10 as subsections. > 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. > [Joe] We should have a section that explicitly discusses channel binding as section 3.x. We should include a mechanism for the server to initiate bindings. > section 7.3: > Please update references to draft-hartman-emu-mulutal-crypto-bind to > draft-ietf-emu-mutual-crypto-bind > > [Joe] OK > 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. > [Joe] Looks OK, we probably should indicate when the its OK not to do the validation and what the consequences are for not doing the validation. Jim's recent message may add to the certificate validation piece. > --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
