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
