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
