Re: [Emu] Review of draft-ietf-emu-eap-tunnel-method-00
I think that picks up all of my current comments. Looking forward to seeing the draft update. Jim From: Hao Zhou (hzhou) [mailto:hz...@cisco.com] Sent: Wednesday, October 10, 2012 11:15 AM To: Jim Schaad Cc: emu@ietf.org Subject: Re: [Emu] Review of draft-ietf-emu-eap-tunnel-method-00 Jim: Please see comments below inline. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] Review of draft-ietf-emu-eap-tunnel-method-00
1. In section 3.2.3, it says that a new PAC can be requested after a full TLS handshake. Can one be requested following an abbreviated handshake? Or do you just re-use the existing PAC? 2. Section 3.3 s/descried/described/ 3. Section 3.4 - Is it possible to have multiple server ids after the authentication - one from the tunnel and others from the inner EAP methods. I realize that most EAP methods don't send a sender id, but some (IBAKE for example) currently do. Also, the client might have an idea of what the sender id is from configuration. If so, do these all need to get exported as server-id values? 4. In section 3.6.1 - It is not clear that an EAP-Failure packet is sent when 1) the server sends a fatal alert to the peer, 2) the peer requests a restart via a ClientHello and 3) the peer declines to permit the restart to occur. 5. In section 3.6.1 - Is the restart only an issue for fatal alerts, or is it a problem for all alerts? 6. In section 3.6.2 - Why SHOULD not MUST send clear text EAP-Failure? 7. In section 3.6 - do we need to discuss the question of errors in the outer EAP layer that is carrying the TLVs which contain the TLS content? This is a distinct location from the current list of where to handle errors. There is going to be a distinction (possibly) between errors that occur during phase 1 and errors during phase 2. Should the error return reflect if the error occurred inside or outside of the TLS tunnel? 8. In section 3.8 - I have the following questions a) In the text The request MAY be issued, I don't understand the MAY at this point. Is it supposed to say that the request can be issued either before or after the authentication has finished, or is it saying that the peer has the option of issuing or not issuing the request, but must wait until the authentication level has been reached? b) If a peer issues a PAC request, but the server has not yet satisfied it's policy, does the server remember the PAC request and send back the response after the internal policy has been satisfied or should it send back an error saying that policy has not yet been satisfied along with additional TLVs to attempt and satisfy that policy? c) What should a peer do if it receives a PAC TLV with an unknown attribute? 9. In section 3.9 - there is leaking on the POP, but not on identity at this point. I believe that there needs to be a requirement that an EAP method needs to be run which will provide an identity proof on the client prior to a certificate being issued. You may or may not then want to add text that says that the subject name(s) in the certificate request need to be checked against the set of authenticated identities prior to the certificate being issued. 10. In section 3.10 - It is unclear to me if the Server Unauthenticated mode is because the server or the peer is unauthenticated at this point in time. The cipher suite would indicate that the server is not authenticated, however what about the case of the server providing an authenticated id to the peer, but the peer is unable to validate the identity of the server for some reason. This is also a Server Unauthenticated mode. 11. In section 4.1 - I would like to see a discussion that says that the following situation can never occur. The initial EAP message from the peer to the server (or the response) plus the Outer TLV data plus the EAP message headers exceeds the underlying packet size of the transport. In the event that it does, I am not sure how one finds the Outer TLV data start and where the fragmentation would occur to get the Outer TLV data between the peer and the server. 12. Section 4.2 - I understand what is happening with an EMPTY TEAP message being sent in response to a list of TLVs that are marked optional, however I question if the statement that is MUST be sent is correct. There are two reasons for the question: a. A server could send a RESULT TLV in response to a message from the client that contains no TLVs that are either mandatory or recognized. b. I am (very slightly) worried about the fact that the response is not authenticated by the tunnel in many manner. I would think that a NAK to any of the TLVs would be a better response if no other TLV messages are to be sent. The entity sending the TLV should know if it marked it as mandatory or not. The NAK is not the same as an Error TLV. 13. Section 4.2.2 - Should Type in the outdented list be TLV Type? s/filed/field/ 14. Section 4.2.2 - Can multiple Authority-ID TLVs be transmitted to a peer? 15. Section 4.2.3 - I assume that there should only be one Identity-Type TLV in a TEAP packet. Should a request for authentication be present in the packet as well? If multiple are allowed then information about how to treat this should be included. What should the peer respond with if it does have an identity of the type? This is not explicitly stated. 16. Section 4.2.4 - I don't understand the default in the event that an unknown value
Re: [Emu] Review of draft-ietf-emu-eap-tunnel-method
Sam: A new draft TEAP-03 was submitted. Please review and make sure all of your issues raised below are addressed in this draft. Thanks. On 3/25/12 7:50 AM, Sam Hartman hartmans-i...@mit.edu wrote: 1) TEAP extends TLS RFC 5077 In section 2, TEAP discusses using phase 2 TLVs to include a TLS session ticket and an associated secret key. RFc 5077 only permits session tickets to be sent using the session ticket message. I believe that this is an extension to TLS that would need to go through the TLS working group. My preference is to remove TLS tickets sent via a manner other than the session ticket handshake message. If support for this is needed a better solution that does not involve changing TLS would be to provision a key for use with a TLS preshared key ciphersuite. 2) TEAP server is separate architectural element from inner server So, in section 2 the document says that the TEAP server and inner server are separate architectural elements. However, in section 1 a design goal was avoiding MITM attacks. To meet that goal and to have an architecture where these servers are separate, a lot more clarity is required around what a MITM is and what is an acceptable intermediate. I also suspect significant security analysis will be required on this point. Let's start by coming up with a clear definition of what a MITM is for this protocol and work from there. Section 7.3 is inadequate. It does not clearly explain who is involved in the trust relationship. IN particular, does the peer need to trust the intermediate, or do the inner servers need to trust the intermediate or both? I think it depends for different vulnerabilities. In order to understand the architectural implications of this I'd like to ask those who want to support this architectural separation to go through every reference to MITM or man-in-the-middle or mutual authentication in the document. For each reference, answer the following questions: A) Who is negatively affected if the attack is possible or the security claim not maintained? (eap server, peer, intermediate, combination) B) for security claims especially those about inner methods. Which parties need to confirm the claim in order to avoid the harm identified in A above? I also think we need clarity around mutual authentication and what that means especially when looking at compositions. 3) Section 3.2: resistance to MITM attack The specification refers to inner methods providing resistance to man-in-the-middle attacks as if this is an RFC 3748 security claim. I assume this refers to the discussion in section 7.4 of RFC 3748. I don't think that claim is strong enough to provide secure composition of inner methods with anonymous ciphersuites. This is related and possibly a superset of the problems discussed in draft-hartman-emu-mutual-crypto-binding). Clearly checking the certificates is an inadequate solution for anonymous TLS ciphersuites. 4) Section 3.2.2: overly much detail on TLS workings I think that having something called a PAC which is really just a TLS session ticket is undesirable. I don't think we need a new name for TLS concepts we're reusing. I am concerned that we specify so much information about how TLS session resumption works. What if future versions of TLS change that? What if our spec is inconsistent with TLS? I recommend we remove most of the information about server and client TLS session resumption and fall back to full vs abbreviated handshakes. 5) Section 3.3.3: confused I'm confused when I read section 3.3.3 on protected negotiation indication. I don't understand when an intermediate result TLV is or is not required for the peer and server. Also, shouldn't the crypto binding TLV always be required here? 6) Section 3.3.3: please require peers reject EAP success without protected negotiation. I think it is very important that we mandate peers implementing TEAP MUST not treat an EAP success packet prior to the peer and server reaching protected result indication as successful. When peers do this (as many do with existing methods) it permits several bid-down attacks. Se the new text in one of the most recent channel bindings specs for an example. 7) Section 3.3.3: How does a peer do channel binding What should a peer do if it wishes to perform channel binding and server sends back a protected success? Request-action seems inefficient for this because the first message is the channel binding request coming from the client to server. 8) Examples with section 3.3 I think that section 3.3 could benefit from several examples: 1) A peer wishes to use a client certificate but wishes to hide its identity and thus use renegotiation. The server requests some inner method in the first phase 2 message before the client can start renegotiation at TLS. Show an example flow of how this works out and how the parties get back in sync. 2) A peer wishes to use an inner eap method even when the server is happy to offer success in the
[Emu] Review of draft-ietf-emu-eap-tunnel-method
1) TEAP extends TLS RFC 5077 In section 2, TEAP discusses using phase 2 TLVs to include a TLS session ticket and an associated secret key. RFc 5077 only permits session tickets to be sent using the session ticket message. I believe that this is an extension to TLS that would need to go through the TLS working group. My preference is to remove TLS tickets sent via a manner other than the session ticket handshake message. If support for this is needed a better solution that does not involve changing TLS would be to provision a key for use with a TLS preshared key ciphersuite. 2) TEAP server is separate architectural element from inner server So, in section 2 the document says that the TEAP server and inner server are separate architectural elements. However, in section 1 a design goal was avoiding MITM attacks. To meet that goal and to have an architecture where these servers are separate, a lot more clarity is required around what a MITM is and what is an acceptable intermediate. I also suspect significant security analysis will be required on this point. Let's start by coming up with a clear definition of what a MITM is for this protocol and work from there. Section 7.3 is inadequate. It does not clearly explain who is involved in the trust relationship. IN particular, does the peer need to trust the intermediate, or do the inner servers need to trust the intermediate or both? I think it depends for different vulnerabilities. In order to understand the architectural implications of this I'd like to ask those who want to support this architectural separation to go through every reference to MITM or man-in-the-middle or mutual authentication in the document. For each reference, answer the following questions: A) Who is negatively affected if the attack is possible or the security claim not maintained? (eap server, peer, intermediate, combination) B) for security claims especially those about inner methods. Which parties need to confirm the claim in order to avoid the harm identified in A above? I also think we need clarity around mutual authentication and what that means especially when looking at compositions. 3) Section 3.2: resistance to MITM attack The specification refers to inner methods providing resistance to man-in-the-middle attacks as if this is an RFC 3748 security claim. I assume this refers to the discussion in section 7.4 of RFC 3748. I don't think that claim is strong enough to provide secure composition of inner methods with anonymous ciphersuites. This is related and possibly a superset of the problems discussed in draft-hartman-emu-mutual-crypto-binding). Clearly checking the certificates is an inadequate solution for anonymous TLS ciphersuites. 4) Section 3.2.2: overly much detail on TLS workings I think that having something called a PAC which is really just a TLS session ticket is undesirable. I don't think we need a new name for TLS concepts we're reusing. I am concerned that we specify so much information about how TLS session resumption works. What if future versions of TLS change that? What if our spec is inconsistent with TLS? I recommend we remove most of the information about server and client TLS session resumption and fall back to full vs abbreviated handshakes. 5) Section 3.3.3: confused I'm confused when I read section 3.3.3 on protected negotiation indication. I don't understand when an intermediate result TLV is or is not required for the peer and server. Also, shouldn't the crypto binding TLV always be required here? 6) Section 3.3.3: please require peers reject EAP success without protected negotiation. I think it is very important that we mandate peers implementing TEAP MUST not treat an EAP success packet prior to the peer and server reaching protected result indication as successful. When peers do this (as many do with existing methods) it permits several bid-down attacks. Se the new text in one of the most recent channel bindings specs for an example. 7) Section 3.3.3: How does a peer do channel binding What should a peer do if it wishes to perform channel binding and server sends back a protected success? Request-action seems inefficient for this because the first message is the channel binding request coming from the client to server. 8) Examples with section 3.3 I think that section 3.3 could benefit from several examples: 1) A peer wishes to use a client certificate but wishes to hide its identity and thus use renegotiation. The server requests some inner method in the first phase 2 message before the client can start renegotiation at TLS. Show an example flow of how this works out and how the parties get back in sync. 2) A peer wishes to use an inner eap method even when the server is happy to offer success in the first message. Show how many result indications are required. 3) Show how channel bindings interact with the result indications. 8) Section 3.4: what is a peer ID? Section 3.4 needs a reference to
