Hi Joe, Sorry for the slow response and if I've missed anything...
On 09/25/2013 07:21 AM, Joseph Salowey (jsalowey) wrote: > > On Aug 14, 2013, at 10:58 AM, Stephen Farrell > <stephen.farr...@cs.tcd.ie> wrote: > >> Stephen Farrell has entered the following ballot position for >> draft-ietf-emu-eap-tunnel-method-07: Discuss >> >> When responding, please keep the subject line intact and reply to >> all email addresses included in the To and CC lines. (Feel free to >> cut this introductory paragraph, however.) >> >> >> Please refer to >> http://www.ietf.org/iesg/statement/discuss-criteria.html for more >> information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found >> here: >> http://datatracker.ietf.org/doc/draft-ietf-emu-eap-tunnel-method/ >> >> >> >> ---------------------------------------------------------------------- >> >> DISCUSS: >> ---------------------------------------------------------------------- >> >> >> >> These discuss points are more questions I'd really like >> answered than blocking points (depending on the answers I guess:-) >> but I expect should be easily resolved. >> >> (1) 3.4: when x.500 names or SubjectAltNames are "exported" is it >> clear how those are formatted? Maybe a pointer to where that's >> defined would be good in case implementers get it wrong. You might >> also want to warn here (or somewhere) about names that contain a >> null byte in case that attack is used e.g. with a TLS server cert >> subject name like "CN=www.paypal.com\0.badguy.com" Even though >> that's really a PKI failure, not detecting it here would be bad >> too. >> > > [Joe] We could add a note about the null, is there some text in an > existing document we could reuse? That one's a comment now. > >> (2) 5.2, at the end: this adds a dependency on the TLS-PRF. I >> don't suppose TLS1.3 will be a big enough change for that to be a >> problem, but what if it was? E.g. if someone convinced the TLS WG >> to use IKE instead? Do you really need the same PRF or could you >> pick one for TEAP and remove the dependency? Same question for the >> MAC in 5.3. >> > > [Joe] We chose to have the dependence so we would rely on the same > crypto-algorithms as TLS so our crypto agility would track with TLS. > We figured TLS would track advances in cryptography better than EMU. Well, two things - if TLS 1.3 makes changes then that could mean that this has to run over TLS 1.2 or earlier to get interop and that seems like a bad plan. And secondly, is there really a good API to see what PRF has been used by TLS for a given session in common TLS implementations? >> (3) 7.3: you have a MAY for this separation but also define what >> would become a cleartext password set of TLVs on the link between >> the two boxes here. Could you not at least REQUIRE protection (e.g. >> using IPsec) of that link if the basic password method will be >> used? >> > > [Joe] Sam's comments pretty much reflect the working group consensus > on this topic. I thought Sam was saying that it'd be good to add a recommendation but I didn't see new text on that, did I miss it, or am I confused? (Which is common:-) Cheers, S. > >> >> ---------------------------------------------------------------------- >> >> COMMENT: >> ---------------------------------------------------------------------- >> >> >> >> - 3.2: You're allowing TLS compression. Is there the >> potential for something like a CRIME attack here? I guess not, >> given that there's no way to programatically get a peer or inner >> method server to send attacker-chosen data. Is that correct? (Just >> checking.) >> > > [Joe] In general no. The closest thing I can think of is NEA which > can use a method such as TEAP for transport, but I don't think this > would allow an attacker to launch a CRIME attack. > >> - 3.2.2: Since a PAC-lifetime is a wall-clock time then it would >> provide a way to correlate old and new sessions (i.e. act as a >> fingerprint) if its ever carried in clear. Can that happen? >> > > [Joe] The PAC-lifetime is carried in the PAC-Info which is always > send under the protection of the TLS tunnel. Only the PAC-Opaque is > sent outside the tunnel. > >> - 3.3.3, 1st para: what does "clear text" mean here? Do you mean >> within the TLS tunnel or not? I hope you do mean within the TLS >> tunnel, but I think you need to be clear(er) in any case. >> > > [Joe] Clear text means outside the TLS tunnel. EAP state machine > requires that the EAP-Success or EAP-Failure be sent independently of > the method. This is why TEAP has its own protected result indication > and why this section states that the Peer must not accept a cleartext > success or failure before the protected results are received. > >> - 3.8: this says mutual auth "results" if the peer trusts the >> server cert belongs to the server - that sounds wrong, isn't it? >> > > [Joe] I think this section is terminology challenged. It should > basically replace mutual server authentication with just server > authentication. > > "Several TEAP services including server unauthenticated > provisioning, PAC provisioning, certificate provisioning and channel > binding depend on the peer trusting the TEAP server. Peers MUST > authenticate the server before these peer services are used. > > TEAP peers MUST track whether server authentication has taken place. > Server authentication results if the peer trusts the provided server > certificate. Typically this involves both validating the certificate > to a trust anchor and confirming the entity named by the certificate > is the intended server. Server authentication also results when the > procedures of Section 3.3 are used to resume a session in which the > the peer and 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 is 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 server authenticated. TEAP peer implementations MUST > have a configuration where authentication fails if server > 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 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 participate in the authentication need to be > considered when evaluating whether to use peer services. " > > > >> - 3.8.1: I think you need an s/MAY/MUST/ here - you say the request >> "MAY be issued only ..." but I think you mean "MUST be issued >> only..." >> > > [Joe] Yes. How about: > > "The peer MUST successfully authenticated the EAP server and > validated the Crypto-Binding TLV as defined in Section 4.2.13 before > issuing the request" > > >> >> - 3.8.2: Just checking, and I may be wrong here. Say if I establish >> a TLS server-auth tunnel and then renegotiate to get TLS >> client-auth (with id privacy) as well, and then the Peer wants to >> get a new cert. This calls for the tls-unique for the initial >> server-auth TLS session to be used in the pkcs#10. Am I reading it >> right? Is that ok? I think it is, but just want to check since its >> pretty confusing;-) >> > > [Joe] This is meant to use the same mechanism as EST. It is > currently out of sync with the latest version. It should line up: > > In order to provide linking identity and proof-of-possession by > including information specific to the current authenticated TLS > session within the signed certification request, the peer generating > the request SHOULD obtain the tls-unique value from the TLS subsystem > as defined in Channel Bindings for TLS [RFC5929]. The TEAP peer > operations between obtaining the tls_unique value through generation > of the CSR that contains the current tls_unique value and the > subsequent verification of this value by the TEAP server are the > "phases of the application protocol during which application- layer > authentication occurs" that are protected by the synchronization > interoperability mechanism described in the Channel Bindings for TLS > [RFC5929] section 3.1 interoperability notes. When performing > renegotiation, TLS "secure_renegotiation" [RFC5746] MUST be used. > > The tls-unique value is base 64-encoded as specified in Section 4 of > [RFC4648] and the resulting string is placed in the certification > request challenge-password field ( [RFC2985], Section 5.4.1). The > challenge-password field is limited to 255 bytes (section 7.4.9 of > [RFC5246] indicates that no existing cipher suite would result in an > issue with this limitation). If tls-unique information is not > embedded within the certification request the challenge-password > field MUST be empty to indicate that the peer did not include the > optional channel-binding information (any value submitted is > verified by the server as tls-unique information). > > The server SHOULD verify the tls-unique information. This ensures > that the authenticated TEAP peer is in possession of the private key > used to sign the certification request. > > > >> - The secdir review [1] raised a couple of questions that I think >> would be good to answer. Did I miss that answer? >> > > [Joe] No, I missed the review. Response in progress. > >> [1] >> http://www.ietf.org/mail-archive/web/secdir/current/msg04106.html >> >> >> _______________________________________________ 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
