Looking for a piece of information. Are there cases in TLS before 1.3 where the PRF and the MAC are not inferred from the cipher suite that was negotiated?
I think it would be surprising if the cipher suite was not obtainable. The question would be if these are ever independent of the suite there could be a problem. Jim > -----Original Message----- > From: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On Behalf Of > Joseph Salowey (jsalowey) > Sent: Thursday, November 07, 2013 4:38 PM > To: emu@ietf.org > Cc: draft-ietf-emu-eap-tunnel-met...@tools.ietf.org; emu- > cha...@tools.ietf.org; Stephen Farrell > Subject: Re: [Emu] Stephen Farrell's Discuss on draft-ietf-emu-eap-tunnel- > method-07: (with DISCUSS and COMMENT) > > I'd like to hear from the working group on this. > > I think Stephen is raising a fair point that trying to use the TLS PRF in this way > creates a very tight binding between a TLS implementation and a TEAP > implementation that may make implementations difficult depending upon the > interfaces provided by a TLS library. I think its very possible that some > libraries would not provide this information. If you think reusing the TLS PRF > is a good idea then please state why. If you think we should define a PRF > please indicate what approach you think we should take. > > Thanks, > > Joe > > > On Nov 7, 2013, at 4:15 PM, Stephen Farrell <stephen.farr...@cs.tcd.ie> > wrote: > > > > > Hi Joe, > > > > On 10/04/2013 05:58 PM, Joseph Salowey (jsalowey) wrote: > >> > > > > Apologies for the glacial response. > > > > Your suggestion for point 3 looks fine. Point 1 is already a comment. > > > > But point 2 needs a bit more discussion. > > > > The concern is that you're doing a layering violation and we know that > > the layer below (TLS) is changing, possibly in a way that'd impact on > > this. Why not just pick a KDF? > > > > S. > > > >> On Oct 4, 2013, at 7:07 AM, Stephen Farrell > >> <stephen.farr...@cs.tcd.ie> > >> wrote: > >> > >>> > >>> 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? > >>> > >> [Joe] The TLS 1.2 the PRF is no longer fixed and it depends upon the > ciphersuite. In most TLS implementations I'm aware of you can find the > ciphersuite. While this does not directly give you the PRF it does allow you to > determine what it is. THis does mean that a TEAP implementation would need > to have a mapping between ciphersuite and PRF. THis means that if a new > ciphersuite is defined TEAP implementations would need to make changes to > support it. If the PRF is an existing PRF then adapting to the new Ciiphersuite > is a simple addition to the mapping table which an implementation could > accommodate a configuration instead of a code change. If a new PRF is > needed then some code change is required to adapt the new PRF. The > thinking here is that the new PRF would have some benefit so you would want > to use it in TEAP as well as TLS. This does make TEAP tightly tied to a TLS > implementation. > >> > >> Is it your worry that changes in TLS 1.3 would make it not possible for a > TEAP implementation to to determine which PRF to use which would prevent > interop? What sort of change are you anticipating in TLS 1.3 that would > disrupt this? > >> > >> > >>>>> (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:-) > >>> > >> > >> [Joe] I might be me that is confused. I was focused on the MTI security > mechanism, which I think we have consensus not to specify for this practice. I > think ti would be good to say that if you are going to do this you must provide > some sort of protection: > >> > >> If the request is to change the SHOULD to a MUST then I think that would > be OK (but I'd like to make sure the working group is OK with this): > >> > >> "The TEAP > >> encrypting/decrypting gateway MUST, at a minimum, provide support > >> for IPsec or similar protection in order to provide confidentiality > >> for the portion of the conversation between the gateway and the EAP > >> server. " > >> > >> > >> > >>> 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 _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
