Re: [Emu] TEAP Comments
Jim: Thanks for the detailed review comments. Response inline below. Will try to submit a new rev with these changes soon. On 11/15/12 3:24 PM, Jim Schaad i...@augustcellars.com wrote: Expanding on the issues so that you have full descriptions of the problem from the last message 1. When either an EMSK or MSK is not present in the Crypto-Binding TLV, there is no way to indicate this. At the f2f it was said that this was going to be by setting it to all zeros. If this is the case, then it does need to be noted that there is a 1 in 2^n chance that it will signal the wrong thing leading to an error in binding being generated. It might be better to steal bits from the Sub-Type octet instead. [HZ] We will add a flag bit in sub-type to indicate presence of EMSK and/or MSK MAC. 2. I find that I have probably not correctly understood when the S bit is set. I have been setting the S bit on all fragments (but not fragment responses) of the original Start request and Start response. I have since found text that says it is only sent from the server to the peer. It would be nice to have the one direction comment in the description of the flags as well (section 4.1) [HZ] Will add a sentence to clarify. 3. I would like to have the description of the L bit in section 4.1 expanded to state the following: - It MUST be present for the first fragment of a fragmented message - It MUST NOT be present for any other message The first can be found in section 3.7 (if you hunt) but the second is not stated anywhere [HZ] Will add that. 4. I would like to have the description of the O bit in section 4.1 expanded to state the following: - It MUST be present only in the initial request and response messages. - If the initial message is fragmented, then it MUST be present only on the first fragment. [HZ] Looks ok. Will add. 5. I don't think point 3 below needs expansion, but I may be too close to it. If you disagree please let me know. [HZ] Sounds reasonable. Will add an error TLV with new error code for the signaling mechanism. Jim -Original Message- From: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On Behalf Of Jim Schaad Sent: Wednesday, November 07, 2012 4:48 PM To: emu@ietf.org Subject: [Emu] TEAP Comments I just wanted to make sure that the mail list had at least the basics of what I mentioned in the f2f today 1. The document does not appear to have an indicator that the EMSK was or was not used to generate a confirmation value. I have not done a final check that this is true but I did try and find it a couple of times 2. The flags on the outer packet need to be defined a bit better. a) is the S bit set only on the first fragment of the first message or on all fragments of the first message b) are the two length bits set only on the first message in a fragment sequence or can they be on any of the messages in a fragment sequence (but the values must then be the same in all fragment messages) c) Can the O bit be set only in the first piece of a fragment, or could it be in the last one without being in any previous one d) Should the L bit never be set on a non-fragmented message since it is redundant 3. There needs to be a signaling mechanism when running inner EAP messages to say that a) that this is a reliable transport and therefore there should be no-retries b) If a packet is dropped on the floor by somebody, then some type of signaling mechanism needs to be created to signal this to the other party. Also there should be text saying that re-sending the message does not necessarily make sense as the packet would probably just be re-dropped again c) There needs to be some type of policy on the server for what to do for either failing or continuing a validation - for example should a new EAP method be tried in this case. Jim ___ 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
Re: [Emu] More comments for eap-tunnel-method
I think an optional length of Outer TLV field (controlled by the flag bit) would be preferable. On 10/9/12 7:37 PM, Jim Schaad i...@augustcellars.com wrote: I would be really against the idea that I needed to crack the TLS data blob to figure this out. Either adding a length for the TLS data field, or a length of the Outer TLV data would be preferable to me. If you did the second, then it would only affect processing on the first two messages. Jim -Original Message- From: Hao Zhou (hzhou) [mailto:hz...@cisco.com] Sent: Tuesday, October 09, 2012 12:46 PM To: Jim Schaad; emu@ietf.org; draft-ietf-emu-eap-tunnel- met...@tools.ietf.org Subject: Re: [Emu] More comments for eap-tunnel-method That is the current thinking, and the only concrete use case for Outer TLV now is in the 1st message from server to peer with no TLS data. I am ok with adding another optional TLS data length field. On 10/9/12 3:31 PM, Jim Schaad i...@augustcellars.com wrote: There does not seem to be anything in the TEAP document about the length of the TLS data. Are you suggesting that one should crack the TLS data blob to find the length of that data blob? Jim -Original Message- From: Hao Zhou (hzhou) [mailto:hz...@cisco.com] Sent: Tuesday, October 09, 2012 11:43 AM To: Jim Schaad; emu@ietf.org; draft-ietf-emu-eap-tunnel- met...@tools.ietf.org Subject: Re: [Emu] More comments for eap-tunnel-method Jim: Please see comments inline below. On 10/8/12 1:11 AM, Jim Schaad i...@augustcellars.com wrote: -Original Message- From: Hao Zhou (hzhou) [mailto:hz...@cisco.com] Sent: Thursday, October 04, 2012 2:56 PM To: Jim Schaad; emu@ietf.org; draft-ietf-emu-eap-tunnel- met...@tools.ietf.org Subject: Re: [Emu] More comments for eap-tunnel-method Jim: Thanks for the review. Please see my comments below. On 9/30/12 2:01 PM, Jim Schaad i...@augustcellars.com wrote: 1. Should the Message Length field be present if the TLS Data field is absent? [HZ] According to the text in the draft, the message length field should only be present if the L bit is set, usually for fragmented packets. In those cases, the TLS data field will be present, not absent. The only case TLS data will be absent is when empty TEAP packet it is used to indicate TEAP acknowledgement for either a fragmented message, a TLS Alert message or a TLS Finished message. So the message length field is not needed. We can clarify that in the draft. [JLS] I am not clear - are you saying that the first sever message sent with just TLVs cannot be fragmented? [HZ] No, they can be fragmented. However, currently, Outer TLVs are only allowed in the first 2 messages in TEAP exchanges, 1st server to peer with TEAP start, and 2nd message client to server with Client_hello. It is unlikely the first server message will have lots of outer TLVs that needs the fragmentation (only one or two outer TLV is being defined so far). The 2nd message from client to server with client _hello might if the ticket extension is too big, but unlikely. [JLS] There is a potential issue in the way that the Message Length field is described. For finding the location of the Outer TLVs it provides the length of the TLS Data field, but the internal description says that it gives the length of the message data in the event of a fragmented message. If the first client response message is both fragmented on length and contains TLVs, then the message length field must be the length of the TLS data in order to find the Outer TLV data but that means it is not the length of all of the fragmented data. This is not an issue after the first pair of messages as the Outer TLVs are no longer allowed at that point. [HZ] The message length is the total length of the TEAP packet if fragmented, to provide a hint for the peer to allocate the buffer. The start of the outer TLV can be calculated from the EAP message length and length field inside the TLS data, not dependent on the Message Length field. The current draft text in Section 4.1 Outer TLVs description incorrectly refers to message length field, will need to be corrected. Since Outer TLVs only occur in the first 2 TEAP exchanges, the TLS data is one type and relatively simple, it should not be too hard to figure out the start. [JLS] I presume that the Length needs to be present only if the message is fragmented as a hint to the receiver on the length of the buffer to allocate as I don't remember any error checks that the length of the message match the re-constructed message from the fragments (and if it did then the previous paragraph makes that faulty). Should there be an error check on the message length w/ the length of the re-constructed buffer? [HZ] I don't know if current TLS
Re: [Emu] Client Auth with TLS
Stefan: Actually even if the client is authenticated as part of the TLS tunnel establishment, NEA data can still be passed inside TEAP tunnel. It is designed to carry additional data in Phase 2. The Current TEAP draft supports both of these modes, as in Section 3.2: TEAP implementations MUST support client authentication during tunnel establishment using the TLS ciphersuites specified in Section 3.2 http://tools.ietf.org/html/draft-ietf-emu-eap-tunnel-method-03#section-3.2 . The EAP peer does not need to authenticate as part of the TLS exchange, but can alternatively be authenticated through additional exchanges carried out in Phase 2. The TEAP tunnel protects peer identity information exchanged during phase 2 from disclosure outside the tunnel. Implementations that wish to provide identity privacy for the peer identity must carefully consider what information is disclosed outside the tunnel prior to phase 2. TEAP implementations SHOULD support the immediate renegotiation of a TLS session to initiate a new handshake message exchange under the protection of the current cipher suite. This allows support for protection of the peer's identity when using TLS client authentication. It properly doesn't describes the TLS exchanges as detailed as in EAP-TLS RFC, but something we could improve if desired. On 10/9/12 10:23 AM, Stefan Winter stefan.win...@restena.lu wrote: Hi, I think it is worthwhile to support an mode of operation that supports peer privacy. I've seen this implemented in tunnel methods in two different ways. One with renegotiation as described below and the other as an inner EAP-TLS exchange after an anonymous outer exchange. I don't really have a strong opinion as to which is better at this point. It seems that using an inner EAP-TLS may be more flexible and would offer the same security properties and might be a simpler model. Any opinions on the list? We have a couple of EAP-TLS realms which are also interested in NEA. I usually tell them that NEA data can't be put into the EAP channel with EAP-TLS, and that that is bad luck for them :-) If TEAP uses tunneled EAP-TLS as opposed to renegotiating, the inner EAP would/might allow for carrying extra attributes besides the cert exchange - thus enabling NEA-like exchanges. If my thinking isn't borked, that would mean I'd rather support inner EAP-TLS to enable these usages. Greetings, Stefan On Oct 7, 2012, at 8:43 PM, Jim Schaad wrote: Stefan, Thanks for the input. For the authors, Does this need to be documented as a mode of operation for TEAP or are we going to say that this is not a supported mode? Jim -Original Message- From: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On Behalf Of Stefan Winter Sent: Wednesday, October 03, 2012 11:10 PM To: emu@ietf.org Subject: Re: [Emu] Client Auth with TLS Hi, 3. The client provides the certificate in a protected manner - I had a problem at this point because I don't know enough TLS to properly go through this scenario, and I could not really read documents while driving. If the encrypted certificate extension was used, then there is no issue as the protected certificate would be passed in the initial handshake. However if the client starts the negotiation and then restarts it after it is encrypted, I don't know if this occurs before or after the finish message. If it starts after the finish method then there is an issue with having the server close an anonymous session if the client is then going to provide the certificate encrypted. Help on how this works would be appreciated. FWIW, RFC5216 (EAP-TLS) already has provisions for a protected client credential exchange (for client privacy protection reasons). I didn't ever see it used (anyone?), but it's clearly a foreseen mode of operation. The text describing this is in section 2.1.4: ...In order to avoid disclosing the peer username, an EAP-TLS peer configured for privacy MUST negotiate a TLS ciphersuite supporting confidentiality and MUST provide a client certificate list containing no entries in response to the initial certificate_request from the EAP-TLS server. An EAP-TLS server supporting privacy MUST NOT treat a certificate list containing no entries as a terminal condition; instead, it MUST bring up the TLS session and then send a hello_request. The handshake then proceeds normally; the peer sends a client_hello and the server replies with a server_hello, certificate, server_key_exchange, certificate_request, server_hello_done, etc. For the calculation of exported keying material (see Section 2.3), the master_secret derived within the second handshake is used. An EAP-TLS peer supporting privacy MUST provide a certificate list containing at least one entry in response to the subsequent certificate_request sent by the server. If the EAP-TLS server supporting
Re: [Emu] More comments for eap-tunnel-method
Jim: Please see comments inline below. On 10/8/12 1:11 AM, Jim Schaad i...@augustcellars.com wrote: -Original Message- From: Hao Zhou (hzhou) [mailto:hz...@cisco.com] Sent: Thursday, October 04, 2012 2:56 PM To: Jim Schaad; emu@ietf.org; draft-ietf-emu-eap-tunnel- met...@tools.ietf.org Subject: Re: [Emu] More comments for eap-tunnel-method Jim: Thanks for the review. Please see my comments below. On 9/30/12 2:01 PM, Jim Schaad i...@augustcellars.com wrote: 1. Should the Message Length field be present if the TLS Data field is absent? [HZ] According to the text in the draft, the message length field should only be present if the L bit is set, usually for fragmented packets. In those cases, the TLS data field will be present, not absent. The only case TLS data will be absent is when empty TEAP packet it is used to indicate TEAP acknowledgement for either a fragmented message, a TLS Alert message or a TLS Finished message. So the message length field is not needed. We can clarify that in the draft. [JLS] I am not clear - are you saying that the first sever message sent with just TLVs cannot be fragmented? [HZ] No, they can be fragmented. However, currently, Outer TLVs are only allowed in the first 2 messages in TEAP exchanges, 1st server to peer with TEAP start, and 2nd message client to server with Client_hello. It is unlikely the first server message will have lots of outer TLVs that needs the fragmentation (only one or two outer TLV is being defined so far). The 2nd message from client to server with client _hello might if the ticket extension is too big, but unlikely. [JLS] There is a potential issue in the way that the Message Length field is described. For finding the location of the Outer TLVs it provides the length of the TLS Data field, but the internal description says that it gives the length of the message data in the event of a fragmented message. If the first client response message is both fragmented on length and contains TLVs, then the message length field must be the length of the TLS data in order to find the Outer TLV data but that means it is not the length of all of the fragmented data. This is not an issue after the first pair of messages as the Outer TLVs are no longer allowed at that point. [HZ] The message length is the total length of the TEAP packet if fragmented, to provide a hint for the peer to allocate the buffer. The start of the outer TLV can be calculated from the EAP message length and length field inside the TLS data, not dependent on the Message Length field. The current draft text in Section 4.1 Outer TLVs description incorrectly refers to message length field, will need to be corrected. Since Outer TLVs only occur in the first 2 TEAP exchanges, the TLS data is one type and relatively simple, it should not be too hard to figure out the start. [JLS] I presume that the Length needs to be present only if the message is fragmented as a hint to the receiver on the length of the buffer to allocate as I don't remember any error checks that the length of the message match the re-constructed message from the fragments (and if it did then the previous paragraph makes that faulty). Should there be an error check on the message length w/ the length of the re-constructed buffer? [HZ] I don't know if current TLS implementations do check for that error. Message length is only used for a hint. The EAP-TLS RFC doesn't cover that either. Thought it did provide more detailed description of the message length and L bit description, something we could use for the TEAP draft. 2. There is nothing to say which TLVs can and cannot occur in the Outer TLVs in any easily findable method. Either a table or the string outer in descriptions would be helpful. As an example, does the Authority-ID TLV in the outer TLV make sense? [HZ] We will add that table. 3. I have gone through the fragmentation and did an implementation rather than just reading it. The questions that I have on it now are slightly different. Do TLVs need to be on a fragment boundary? Or do we just build the entire message, fragment it into convenient sizes regardless of the actual content of the message contents and sent the pieces across? If so then the text should probably be re-written to be clearer. Specifically, the message length is not useful for allocating the buffer on the first round trip of messages where one can have a TLV added in to the content. [HZ] Message length covers the whole TEAP packet even if fragmented. TLVs do not need to be on a fragment boundary. Just build the whole message contents and send the pieces across. We will provide some text to clarify this. [JLS] - see note above about finding the start of the Outer TLV data block on the first pair of messages. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] More COmments 2 on eap-tunnel-method
Agree. We will clarify that. On 10/8/12 1:11 AM, Jim Schaad i...@augustcellars.com wrote: -Original Message- From: Hao Zhou (hzhou) [mailto:hz...@cisco.com] Sent: Thursday, October 04, 2012 3:06 PM To: Jim Schaad; emu@ietf.org; draft-ietf-emu-eap-tunnel- met...@tools.ietf.org Subject: Re: [Emu] More COmments 2 on eap-tunnel-method Jim: Please see comments below. On 10/1/12 1:10 PM, Jim Schaad i...@augustcellars.com wrote: I found two that I forgot to include in the last message 1. When exporting the user-id, does there need to be a way to distinguish at export time between the different types of ids that are authenticated by the server? This does not seem to be an issue on the peer as it will only do mutual authentication to servers and thus only have server ids, however a server may authenticate to different types of identities on the peer. At the moment we have identified user and machines as types of entities to be identified, I suppose in the future we could add Ewoks as a different type of entity that could be identified. However the export function of user-ids does not make a distinction between the different types of authenticated entities. Should it do so or should it just export user authentications? [HZ] It helps to export the identities as well as the corresponding identity types (from the Identity Type TLV). Will add text. 2. Is there a map of TLVs that should not be sent together or need to be processed in a specific order? The case I was looking at was for the Identity TLV and the EAP TLV. Is there a difference in how a peer should react for the following? Identity TLV (Send me a machine Identity), EAP TLV (Start the EAP type XX) EAP TLV (Start EAP type XXX), Identity TLV (Send me a machine Identity) Or should these two TLVs never occur in a single message? [HZ] We had some discussion in WG and take the design principal of TLV ordering should not matter. We disallow simultaneous EAP inner methods and/or with Basic Password Authentication, so rest of the TLVs order should not matter. If it does matter, it should be a nested TLV, as in Result TLV and Request-Action TLV. Need to add text to disallow Inner EAP method with parallel Basic Password Authentication TLV. [JLS] If order of TLVs does not matter, then there is an implied order that the TLVs should be processed. That is one should always process the Identity TLV before processing the EAP TLV as the identity TLV is a hint to the type of identity that is to be used in the EAP method. Conversely it might be that these two TLVs should never occur in the same message. Ditto with the Basic Password Authentication TLV and the Identity TLV. Jim Jim ___ 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
Re: [Emu] More comments for eap-tunnel-method
That is the current thinking, and the only concrete use case for Outer TLV now is in the 1st message from server to peer with no TLS data. I am ok with adding another optional TLS data length field. On 10/9/12 3:31 PM, Jim Schaad i...@augustcellars.com wrote: There does not seem to be anything in the TEAP document about the length of the TLS data. Are you suggesting that one should crack the TLS data blob to find the length of that data blob? Jim -Original Message- From: Hao Zhou (hzhou) [mailto:hz...@cisco.com] Sent: Tuesday, October 09, 2012 11:43 AM To: Jim Schaad; emu@ietf.org; draft-ietf-emu-eap-tunnel- met...@tools.ietf.org Subject: Re: [Emu] More comments for eap-tunnel-method Jim: Please see comments inline below. On 10/8/12 1:11 AM, Jim Schaad i...@augustcellars.com wrote: -Original Message- From: Hao Zhou (hzhou) [mailto:hz...@cisco.com] Sent: Thursday, October 04, 2012 2:56 PM To: Jim Schaad; emu@ietf.org; draft-ietf-emu-eap-tunnel- met...@tools.ietf.org Subject: Re: [Emu] More comments for eap-tunnel-method Jim: Thanks for the review. Please see my comments below. On 9/30/12 2:01 PM, Jim Schaad i...@augustcellars.com wrote: 1. Should the Message Length field be present if the TLS Data field is absent? [HZ] According to the text in the draft, the message length field should only be present if the L bit is set, usually for fragmented packets. In those cases, the TLS data field will be present, not absent. The only case TLS data will be absent is when empty TEAP packet it is used to indicate TEAP acknowledgement for either a fragmented message, a TLS Alert message or a TLS Finished message. So the message length field is not needed. We can clarify that in the draft. [JLS] I am not clear - are you saying that the first sever message sent with just TLVs cannot be fragmented? [HZ] No, they can be fragmented. However, currently, Outer TLVs are only allowed in the first 2 messages in TEAP exchanges, 1st server to peer with TEAP start, and 2nd message client to server with Client_hello. It is unlikely the first server message will have lots of outer TLVs that needs the fragmentation (only one or two outer TLV is being defined so far). The 2nd message from client to server with client _hello might if the ticket extension is too big, but unlikely. [JLS] There is a potential issue in the way that the Message Length field is described. For finding the location of the Outer TLVs it provides the length of the TLS Data field, but the internal description says that it gives the length of the message data in the event of a fragmented message. If the first client response message is both fragmented on length and contains TLVs, then the message length field must be the length of the TLS data in order to find the Outer TLV data but that means it is not the length of all of the fragmented data. This is not an issue after the first pair of messages as the Outer TLVs are no longer allowed at that point. [HZ] The message length is the total length of the TEAP packet if fragmented, to provide a hint for the peer to allocate the buffer. The start of the outer TLV can be calculated from the EAP message length and length field inside the TLS data, not dependent on the Message Length field. The current draft text in Section 4.1 Outer TLVs description incorrectly refers to message length field, will need to be corrected. Since Outer TLVs only occur in the first 2 TEAP exchanges, the TLS data is one type and relatively simple, it should not be too hard to figure out the start. [JLS] I presume that the Length needs to be present only if the message is fragmented as a hint to the receiver on the length of the buffer to allocate as I don't remember any error checks that the length of the message match the re-constructed message from the fragments (and if it did then the previous paragraph makes that faulty). Should there be an error check on the message length w/ the length of the re-constructed buffer? [HZ] I don't know if current TLS implementations do check for that error. Message length is only used for a hint. The EAP-TLS RFC doesn't cover that either. Thought it did provide more detailed description of the message length and L bit description, something we could use for the TEAP draft. 2. There is nothing to say which TLVs can and cannot occur in the Outer TLVs in any easily findable method. Either a table or the string outer in descriptions would be helpful. As an example, does the Authority-ID TLV in the outer TLV make sense? [HZ] We will add that table. 3. I have gone through the fragmentation and did an implementation rather than just reading it. The questions that I have on it now are slightly different. Do TLVs need to be on a fragment boundary? Or do we just build the entire message, fragment
Re: [Emu] More comments for eap-tunnel-method
Jim: Thanks for the review. Please see my comments below. On 9/30/12 2:01 PM, Jim Schaad i...@augustcellars.com wrote: 1. Should the Message Length field be present if the TLS Data field is absent? [HZ] According to the text in the draft, the message length field should only be present if the L bit is set, usually for fragmented packets. In those cases, the TLS data field will be present, not absent. The only case TLS data will be absent is when empty TEAP packet it is used to indicate TEAP acknowledgement for either a fragmented message, a TLS Alert message or a TLS Finished message. So the message length field is not needed. We can clarify that in the draft. 2. There is nothing to say which TLVs can and cannot occur in the Outer TLVs in any easily findable method. Either a table or the string outer in descriptions would be helpful. As an example, does the Authority-ID TLV in the outer TLV make sense? [HZ] We will add that table. 3. I have gone through the fragmentation and did an implementation rather than just reading it. The questions that I have on it now are slightly different. Do TLVs need to be on a fragment boundary? Or do we just build the entire message, fragment it into convenient sizes regardless of the actual content of the message contents and sent the pieces across? If so then the text should probably be re-written to be clearer. Specifically, the message length is not useful for allocating the buffer on the first round trip of messages where one can have a TLV added in to the content. [HZ] Message length covers the whole TEAP packet even if fragmented. TLVs do not need to be on a fragment boundary. Just build the whole message contents and send the pieces across. We will provide some text to clarify this. ___ 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
Re: [Emu] More COmments 2 on eap-tunnel-method
Jim: Please see comments below. On 10/1/12 1:10 PM, Jim Schaad i...@augustcellars.com wrote: I found two that I forgot to include in the last message 1. When exporting the user-id, does there need to be a way to distinguish at export time between the different types of ids that are authenticated by the server? This does not seem to be an issue on the peer as it will only do mutual authentication to servers and thus only have server ids, however a server may authenticate to different types of identities on the peer. At the moment we have identified user and machines as types of entities to be identified, I suppose in the future we could add Ewoks as a different type of entity that could be identified. However the export function of user-ids does not make a distinction between the different types of authenticated entities. Should it do so or should it just export user authentications? [HZ] It helps to export the identities as well as the corresponding identity types (from the Identity Type TLV). Will add text. 2. Is there a map of TLVs that should not be sent together or need to be processed in a specific order? The case I was looking at was for the Identity TLV and the EAP TLV. Is there a difference in how a peer should react for the following? Identity TLV (Send me a machine Identity), EAP TLV (Start the EAP type XX) EAP TLV (Start EAP type XXX), Identity TLV (Send me a machine Identity) Or should these two TLVs never occur in a single message? [HZ] We had some discussion in WG and take the design principal of TLV ordering should not matter. We disallow simultaneous EAP inner methods and/or with Basic Password Authentication, so rest of the TLVs order should not matter. If it does matter, it should be a nested TLV, as in Result TLV and Request-Action TLV. Need to add text to disallow Inner EAP method with parallel Basic Password Authentication TLV. Jim ___ 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
Re: [Emu] IMSK derivation issue
Jim: Thanks for pointing out this issue. How about the following text with slight modification with policy control from both sides to prevent downgrade attack. Added text in red. 1. The first sender of the Crypto-Binding TLV needs to create it as follows: a) If the EMSK is not available, then it computes the Compound MAC as is currently documented b) If the EMSK is available, and the sender's policy accepts MSK based MAC, then it computes two Compound MAC values. The first is computed with the EMSK as is currently documented. The second is a Compound MAC that uses the MSK and the Buffer is modified by adding the string EMSK (or something similar). Both MACs are then send to the other Side. c) If the EMSK is available, but the sender's policy doesn't allow downgrade to MSK generated MAC, then it should only send EMSK based MAC. 2. The second sender of the Crypto-Binding TLV then: a) If the EMSK is available and an EMSK Compound MAC was sent validates it and creates a response using the EMSK and sends it back b) If the EMSK is not available and an EMSK compound MAC was sent - it validates the MSK using the modified BUFFER string and sends back a MSK generated response c) If no EMSK Compound MAC was sent, and its policy accepts MSK based MAC, then it validates using the MSK - and if successful generates and returns an MSK generated response. d) If no EMSK Compound MAC was sent, and its policy doesn't accept MSK based MAC, then it handles like an invalid crypto-binding TLV with fatal error. On 9/29/12 4:47 PM, Jim Schaad i...@augustcellars.commailto:i...@augustcellars.com wrote: I agree that the IMSK needs to take into account the existence of the EMSK, however the current text has a severe problem with the way that it is done. It assumes that if the EMSK is exportable on one side, then it will be exportable on the other side as well. I don't believe this is the case. In order for this to work, and to prevent the downgrade attack by a MITM, I believe that the following changes need to be made: 1. The first sender of the Crypto-Binding TLV needs to create it as follows: a) If the EMSK is not available, then it computes the Compound MAC as is currently documented b) If the EMSK is available, then it computes two Compound MAC values. The first is computed with the EMSK as is currently documented. The second is a Compound MAC that uses the MSK and the Buffer is modified by adding the string EMSK (or something similar). Both MACs are then send to the other side. 2. The second sender of the Crypto-Binding TLV then: a) If the EMSK is available and an EMSK Compound MAC was sent validates it and creates a response using the EMSK and sends it back b) If the EMSK is not available and an EMSK compound MAC was sent - it validates the MSK using the modified BUFFER string and sends back a MSK generated response c) If no EMSK Compound MAC was sent, it validates using the MSK - and if successful generates and returns an MSK generated response. If the EMSK compound MAC is removed in transit, then the MSK validated value will fail as the BUFFER string is not modified to recognize that an EMSK Compound MAC was sent. 3. The first send then validates the returned values by: a) If it sent an EMSK Compound value - attempt to validate using the EMSK value. If it fails then go to b else succeed b) Validate using the MSK value using the unmodified buffer. Both sides will then need to remember if the MSK or EMSK value was used for validation in this step, but that is no different than the fact that the MSK is currently being remembered. Jim ___ Emu mailing list Emu@ietf.orgmailto:Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Review - draft-ietf-emu-eap-tunnel-method-00
Jim: Your comments were on draft-ietf-emu-crypto-bind-00.txt, not draft-ietf-emu-eap-tunnel-method? On 9/26/12 12:10 AM, Jim Schaad i...@augustcellars.com wrote: Version 0 of the document is not ready for a last call as security considerations are missing. Other comments 1. I think in figure #1, there would be improved clarity if the line for Pear initiates connection to a service would have the following under the attacker line --|-- to indicate that the attacker is intercepting the traffic at this point and forwarding it. 2. The last paragraph in section 1 need to be re-organized. a) It says there are several strategies, but I can only see two that are outlined here b) It is not clear where the second strategy starts. That is is the technical solution part of the security solution. (yes I know that it is not) c) It is unclear if the cryptographic binding is unable to make the proof to the peer, or if this is just not done because the peer has traditionally not cared that it was so. 3. In section 2 I have a problem with the sentence Channel bindings are used to tell the peer which application service is being connected to. I don't know that this is a good characterization of what is happening with channel bindings esp with the updated RFC in process. The issue I have is that not all of the information about the service is communicated to the peer, and the peer is told information about the service, but still might not know what service it is connected to. I think a better characterization might be Channel bindings are used to provide the peer with information about the application service it is connecting to. 4. I would add an introductory sentence to paragraph #2 in section 2 to say this is the start of an example. 5. In section 3.2.2 - Item #1 seems to be a hardship to get implemented and get right. There is an easy argument that servers can have a policy configured about what inner methods can be used, but imposing it on the peer and making the configuration be server based can be problematic. I think that this issue probably deserves more text. How is the configuration updated and transferred to the peer. 6. In section 3.2.4 - then condition 3 need to tell me where condition 3 is - what section? 7. Missing paran (see Section 3.3. insert 8. In section 3.3 - can the intended intermediary be on the other side - that is between the NAS and the authenticator rather than the peer and the NAS? This is not clear from the text 9. In section 4.2 - there may be another piece of state tracking that should be added. It is not enough to know that mutual authentication has occurred, it might also be important to know who it has occurred with. Thus having performed mutual auth with a user is different than performing mutual auth with a machine and the operations that are allowed to take place may be different. 10. Section 5, 6 and 7 appear to be completely absent in the current draft. Jim ___ 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
Re: [Emu] Looking for reviewers
Simon: Thanks for the review. Good catch on both. We will fix both of them. On 9/25/12 2:02 PM, Simon Josefsson si...@josefsson.org wrote: Alan DeKok al...@deployingradius.com writes: https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tunnel-method/ Section 5.3: The Compound MAC computation is as follows: CMK = CMK[j] Compound-MAC = HMAC-HASH( CMK, BUFFER ) where j is the number of the last successfully executed inner EAP method, HASH is the default hash function or the alternative hash function negotiated in TLS 1.2 [RFC5246], and BUFFER is created after concatenating these fields in the following order: TLS may negotiate MACs that are not based on HMAC. Am I missing some context here, or should this really be something like: The Compound MAC computation is as follows: CMK = CMK[j] Compound-MAC = MAC( CMK, BUFFER ) where j is the number of the last successfully executed inner EAP method, MAC is the MAC function negotiated via TLS 1.2 [RFC5246], and BUFFER is created after concatenating these fields in the following order: Section 5.1: derivation is teap seesion key seed. The length of the session key Is this typo intentional? I see it repeated in the IANA considerations as well. /Simon ___ 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
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
Re: [Emu] 答复: Re: 答复: RE: Re: New draft on mutual crypto binding problem
Well, the AAA server terminates the tunnel is doing the crypto-binding, os it will need the EMSK key from the inner method AAA. However, EMSK, according to RFC5247, is never shared with a third party. So, it is possible to transport some transient keys derived from the EMSK between the AAA servers. The TEAP draft-02 uses the transient key derived from inner method EMSK if available. However, no stander defined protocol exists today to do the transport. That's the missing piece. From: zhou.suj...@zte.com.cnmailto:zhou.suj...@zte.com.cn zhou.suj...@zte.com.cnmailto:zhou.suj...@zte.com.cn Date: Monday, July 9, 2012 10:57 PM To: Cisco Employee hz...@cisco.commailto:hz...@cisco.com Cc: emu@ietf.orgmailto:emu@ietf.org emu@ietf.orgmailto:emu@ietf.org, emu-boun...@ietf.orgmailto:emu-boun...@ietf.org emu-boun...@ietf.orgmailto:emu-boun...@ietf.org, Sam Hartman hartmans-i...@mit.edumailto:hartmans-i...@mit.edu, Zhangdacheng (Dacheng) zhangdach...@huawei.commailto:zhangdach...@huawei.com Subject: 答复: Re: 答复: RE: Re: [Emu] New draft on mutual crypto binding problem Regards~~~ -Sujing Zhou Hao Zhou (hzhou) hz...@cisco.commailto:hz...@cisco.com 写于 2012-07-10 00:33:21: We are talking about the case of separation of outer EAP method and inner method (intermediate AAA terminates the EAP tunnel and have a separate AAA server for the inner method). Since EMSK from the inner method never leaves the AAA server where it is generated, (nor it is designed to be transported or a protocol exists to transport the EMSK or key derived from it between AAA servers), EMSK based crypto- binding will potentially break this use case. Well，in this case where tunnel server and EAP authentication server are separated, and it is required to combine TK and EMSK together, cann't it resolved by either specifying how to transport EMSK to another AAA or specifying how to transport TK to another AAA? From: zhou.suj...@zte.com.cnmailto:zhou.suj...@zte.com.cn zhou.suj...@zte.com.cnmailto:zhou.suj...@zte.com.cn Date: Tuesday, July 3, 2012 12:04 AM To: Zhangdacheng (Dacheng) zhangdach...@huawei.commailto:zhangdach...@huawei.com Cc: emu@ietf.orgmailto:emu@ietf.org emu@ietf.orgmailto:emu@ietf.org, emu-boun...@ietf.orgmailto:emu-boun...@ietf.org emu- boun...@ietf.orgmailto:boun...@ietf.org, Sam Hartman hartmans-i...@mit.edumailto:hartmans-i...@mit.edu, Cisco Employee hz...@cisco.commailto:hz...@cisco.com Subject: 答复: RE: Re: [Emu] New draft on mutual crypto binding problem Regards~~~ -Sujing Zhou Zhangdacheng (Dacheng) zhangdach...@huawei.commailto:zhangdach...@huawei.com 写于 2012-07-03 11:41:49: I think you try to ask why ESMK can be used to detect the attackers who try to impersonate other honest servers. Unlike MSK, EMSK will never be transported over the network and then cannot be accessed by attackers. Therefore, it is possible for a peer to use EMSK to detect an attacker who tries to perform the attacks illustrated in the draft. That is what I understand, but EMSK-based crypto binding can still be transported through intermediate AAA servers between home AAA server and peer, right? Ｉdon't understand Hao Zhou's concern here. From: zhou.suj...@zte.com.cnmailto:zhou.suj...@zte.com.cn [mailto:zhou.suj...@zte.com.cn] Sent: Tuesday, July 03, 2012 11:27 AM To: Sam Hartman Cc: draft-hartman-emu-mutual-crypto-b...@tools.ietf.orgmailto:draft-hartman-emu-mutual-crypto-b...@tools.ietf.org; emu@ietf. org; emu-boun...@ietf.orgmailto:emu-boun...@ietf.org; Sam Hartman; Hao Zhou Subject: 答复: Re: [Emu] New draft on mutual crypto binding problem How does EMSK break intermediate AAA servers？ Regards~~~ -Sujing Zhou emu-boun...@ietf.orgmailto:emu-boun...@ietf.org 写于 2012-06-29 02:25:44: Hao == Hao Zhou hz...@cisco.commailto:hz...@cisco.com writes: Hao Sam: Hao This is a well thought and well written draft, it covers a lot of background Hao and aspect of the attacks and mitigations. However, I have few comments: Thanks! You listed a set of drawbacks to EMSK-based crypto binding. Hao A. Mutual crypto-binding required the use of EMSK, not all existing EAP Hao method generate and export EMSK. It will also break intermediate AAA Hao servers. More importantly, it would only work for an EAP method that Hao generates keys. Part of the goal of Tunnel Method is to protect weak Hao authentication or EAP method, this would not benefits them. These drawbacks to EMSK-based cryptographic binding are documented; thanks. Hao D. Enforcing server policy would be another good way to go, if server can Hao demand tunnel method only, eliminate the chance of inner method MSK being Hao sent to the attacker. As discussed in the draft, you actually need a number of conditions beyond just that. However I agree server policy is another
Re: [Emu] Potential Notes in EAP-FAST Documents
Jouni:
Thanks for the feedback.
To clarify, EAP-FAST-MSCHAPv2 is only being used during anonymous
provisioning mode, in other cases, the normal EAP-MSCHAPv2 is being
used. This is mentioned in draft-cam-winget-eap-fast-provisioning
Section 3.2.3 and reflects current implementations. The design is to
specifically minimize the risk associated with an anonymous tunnel,
which does not apply to an authenticated tunnel.
As for the ISK derivation from EAP-MSCHAPv2, a further clarification is
probably helpful. As discussed, EAP-MSCHAPv2 documentation doesn't
really describe how MSK is generated, only referencing RFC3079. RFC3079
only describes how two 128-bit keys are generated, but leaves out how
these two keys are combined to form the MSK. This leaves it to be
defined in a tunnel method specific way. It seems that EAP-FAST may have
defined a combining algorithm different with the other method.
Here is what we propose to add to draft-cam-winget-eap-fast-provisioning
Section 3.2.3 to clarify the issue.
The inner session key (ISK) generation for EAP-FAST-MSCHAPv2 and
EAP-MSCHAPv2 used inside EAP-FAST MUST follow the steps below. Two 128
bit master keys MasterSendKey and MasterReceiveKey are generated
according to the RFC3079. They are combined to form the ISK, with
MasterSendKey taking the first 16 octets and MasterReceiveKey taking the
last 16 octets.
As for the GTC comment, you are right that EAP-FAST-GTC is being used in
all cases inside EAP-FAST. So your suggestion of removing during
authentication or changing it to always is fine.
-Original Message-
From: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On
Behalf Of Jouni Malinen
Sent: Wednesday, February 11, 2009 3:13 PM
To: Tim Polk
Cc: emu@ietf.org; i...@ietf.org IESG
Subject: Re: [Emu] Potential Notes in EAP-FAST Documents
On Wed, Feb 11, 2009 at 09:26:14AM -0500, Tim Polk wrote:
Second, I will be offering the following text for IESG
notes on both
documents. The notes clearly state the drawbacks for EAP type code
reuse and define an acceptable path for future protocol developers.
This looks like an appropriate text to add. However, I would
request a small clarification on the exact scope of the
different EAP-MSCHAPv2 and EAP-GTC behavior. As far as
EAP-FAST-MSCHAPv2 vs. EAP-MSCHAPv2 is concerned, I would
expect that EAP-FAST-MSCHAPv2 is actually used both for
unauthenticated (anonymous) and server-authenticated
provisioning while the proposed note seemed to indicate that
the different behavior is implied by the use of an anonymous
tunnel. See below for suggested changes to resolve this.
I'm assuming that the implicit challenges derived from the
TLS handshake are not used in the EAP-FAST authentication,
i.e., normal authentication would be using something that is
closer to EAP-MSCHAPv2, not EAP-FAST-MSCHAPv2. However, I
think that even that use of EAP-MSCHAPv2 differs a bit from
the way it is used in other protocols, e.g., as far as key
derivation is concerned, but this would have been more of a
comment for RFC 4851 than these two drafts that are now discussed.
Anyway, since the key derivation from inner method is used
also during provisioning, it would be useful to specify the
exact process used to derive ISK from EAP-FAST-MSCHAPv2
(especially the order of send/recv MS-MPPE keys which seems
to differ from the way this is used in PEAPv0 with cryptobinding).
-- draft-cam-winget-eap-fast-provisioning -
The EAP method EAP-FAST-MSCHAPv2 reuses the EAP type
code assigned to
EAP-MSCHAPv2 (26) for authentication within an
anonymous TLS tunnel.
s/an anonymous TLS tunnel/the EAP-FAST tunnel during provisioning/
In
order to minimize the risk associated with an anonymous tunnel,
changes
to the method were made that are not interoperable with EAP-
MSCHAPv2.
This use of anonymous tunnel sounds fine.
Since EAP-MSCHAPv2 does not support method-specific version
negotiation,
the use of EAP-FAST-MSCHAPv2 is implied by the use of
an anonymous
EAP-FAST tunnel.
s/of an anonymous EAP-FAST tunnel/inside the EAP-FAST tunnel
during provisioning/
This behavior may cause problems in implementations
where the use of unaltered EAP-MSCHAPv2 is needed inside an
anonymous
EAP-FAST tunnel. Since such support requires special case
execution of
a method within a tunnel, it also complicates implementations
that use
the same method code both within and outside of the tunnel
method.
That anonymous should likely be replaced, too, but I don't
have a good proposal for this one. Maybe s/an anonymous/the/
The implementation complexity comes both from different
tunneling methods using different versions of EAP-MSCHAPv2
and from the different use within EAP-FAST depending on state
(provisioning vs.
authentication).
draft-zhou-emu-fast-gtc --
Re: [Emu] Potential Notes in EAP-FAST Documents
Dave and Dorothy: We don't believe there are interoperability issues, as the intended informational RFCs clearly describe the protocol and packet format over the wire for these inner methods specifically when running inside EAP-FAST. The so called interoperability issue raised is at most an implementation issue, only applies to certain software environments where the same inner methods are used both inside and outside EAP-FAST, and could be worked around. This is demonstrated by the numerous existing client and server implementations already deployed in the field (most of which support these inner methods both inside and outside EAP-FAST), and lack of reporting of this issue. The intent of these drafts is informational and to clearly document the existing implementations started 5 years ago. Assigning new EAP types isn't going to solve any interoperability problems, but is likely to generate new ones. If we were to redesign today, certainly we would probably take a different approach to make the software implementation easier. We are open to all of your suggestions for enhancements on the next version of EAP-FAST. We believe these drafts have documented these potential points of confusion. The difference between EAP-MSCHAPVv2 inside and outside EAP-FAST is documented in draft-cam-winget-eap-fast-provisioning. As for EAP-FAST-GTC, the draft-zhou-emu-fast-gtc documents the difference it has with EAP-GTC in turns of handling password authentication. As for regular OTP or token authentication, the implementation could strip the labels and pass the rest to the regular EAP-GTC state machine. How GTC handles the token exchanges is outside the scope of this draft (under defined in RFC3748). If you do see areas of requiring more description of the differences, we are certainly open to suggestions. From: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On Behalf Of David Mitton Sent: Tuesday, February 03, 2009 12:32 PM To: dstanley1...@gmail.com Cc: hous...@vigilsec.com; i...@ietf.org; emu@ietf.org Subject: Re: [Emu] Potential Notes in EAP-FAST Documents I'm sorry, I haven't responded earlier either, but I would like to pile on with some of my comments. When I read the Cisco EAP-FAST GTC description and was similarly shocked by the nature of the changes, and how poorly they technically met their own rationale. Encoding the REQ= and RESP= into Request and Response text, is absolutely useless, since the data flow is unidirectional and known to the requester/responder peers. And then claiming that is more efficent because the username and OTP are combined in one response, really ignores the issue that GTC doesn't define what the appropriate response is. And they did nothing to clue the client as to what is being requested, or the format of the response. Given that, a Client can only strip the useless cybercrud, and continue with the normal GTC state machine which is let the user type something in and send it. A more robust OTP implementation may have several different inputs that it wants from the user besides for username and OTP. (BTW; username could be derived from the EAP Identity) There are possible next token challenges, new PIN assignment (user or system generated) and followup re-authentications. Their protocol did nothing to codify a standard for interoperation where a sequence of requests were enumerated or named, and response items were described. I'm all for documenting practice, but this design/implementation doesn't really seem to solve anything and just creates more confusion. Dave Mitton Feb 3, 2009 11:13:36 AM, dstanley1...@gmail.com wrote: The interoperability concern with existing EAP-MSCHAPv2 and EAP-GTC implementations and incorrect re-use of EAP Types must be addressed/corrected prior to publication. One solution is to (a) Get a new, correct type number for use by the method in the published document, and change the name of the method (could use name-CR for corrected/revision, or similar). This eliminates the interoperability concern with existing methods, and uniquely identifies the IETF published method. and (b) Add descriptive text in the document to explain the difference between this IETF published method and similar deployed methods - to meet the desire to document deployed methods. Dorothy Stanley On Mon, Feb 2, 2009 at 6:56 PM, Glen Zorn glenz...@comcast.net wrote: Dear EMU WG: These two
Re: [Emu] EMU charter revision,
I like Bernard's text better. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bernard Aboba Sent: Wednesday, April 30, 2008 7:54 PM To: Joseph Salowey (jsalowey); emu@ietf.org Subject: Re: [Emu] EMU charter revision, [Joe] Jari had asked to keep this open to TLS. I think he was suggesting it could be done as a TLS extension and would not require tunneling. I agree that we do not want to extend EAP-TLS to do tunneling. How about: - Enable a TLS-based EAP method to support channel bindings. This item will not generate a new method, rather it will focus on supporting EAP channel bindings within the tunnel method. The possiblity of adding channel bindings to EAP-TLS through a TLS extension or other standard TLS mechanism may also be investigated. [BA] I think we only want one mechanism for support of channel bindings in TLS-based methods. So it's ok to investigate a TLS extension vs. other mechanisms for supporting channel bindings, but I'd suggest we only want to choose one path. So my suggestion would be to modify the text as follows: - Enable a TLS-based EAP method to support channel bindings. This item will not generate a new method, rather it will focus on adding support for EAP channel bindings. Potential mechanisms for addition of support for channel bindings will be investigated, including tunneling of channel binding parameters, or a TLS extension or other standard TLS mechanism. ___ 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
Re: [Emu] EMU charter revision
Dan: Now you have changed to argue that tunnel method is not the right solution for the use case EMU is targeted on, instead of arguing your proposed password should be included as addition to the tunnel method. I thought working on and standardizing the tunnel method is the WG consensus for few IETF meetings now, are you going to challenge that now? Maybe this also contributes to the snail race of tunnel method. As for the password method you proposed, I was at the last IETF meeting and you can also verify from he meeting minutes. The consensus is to have more security reviews and the IPR analysis. Also, since the use case it targeted maybe more broader than the EMU WG, it was suggested to bring up in SAAG as well, as multiple WGs can benefit from it. But the direction from the AD is to finish existing work first. Why are we keeping bring this up? -Original Message- From: Dan Harkins [mailto:[EMAIL PROTECTED] Sent: Monday, April 28, 2008 12:45 PM To: Hao Zhou (hzhou) Cc: Yoav Nir; emu@ietf.org Subject: Re: [Emu] EMU charter revision Hold on a second there Hao. A security proof was never a requirement. I'm not aware of any other IETF protocols that required security proofs or even have security proofs. There is no formal proof required of the tunneled methods and I think it would be very difficult to do one. One of the problems with the tunneled solution is the consistency principle described in Hugo Krawczyk's SIGMA paper. The tunneled methods violate that security requirement. And the fact that these things can be repeatedly tunneled ad nauseum amplifies that violation. A use case? Surely you have noticed the friction between usability and security. Security needs bootstrapping of some sort and typically that is problematic for many people especially when they need to bootstrap a large number of distinct security associations. So they cut corners. How are these corners cut? Do not verify server certificate. That's why that little check box exists. Because people don't want to enroll everybody/everything into a CA. So they use a self-signed certificate and check the Do not verify server certificate check box. And then they send a password over this encrypted tunnel. So the use case is robust security that cannot be provisioned insecurely. It's scalable and doesn't require the cutting of corners by administrators who are too busy (or frankly lazy) to do it the Correct Way. I have used the it's their network and if they aren't so concerned about security then who am I to force a workload on them comments in the past but it really is disingenuous. There are frightfully many deployments of password-authentication-through- encrypted-TLS-tunnel that use self-signed certificates and then something analogous to PAP. And they are done that way because there isn't a viable standard alternative. That is the use case for EAP-pwd. Oh, and it can satisfy the consistency principle too. :-) Dan. On Mon, April 28, 2008 8:10 am, Hao Zhou (hzhou) wrote: Yoav: I thought we had clear consensus in IETF 71 WG meeting and instructed by the AD that while Dan's proposal is an interesting one, but it doesn't work with the legacy password databases and thus out-of the scope of the charter. Until we have the proof of security analysis and clear of IPR issues, the WG is going to work on the tunnel method. I think this is the use case, legacy password database, the working group is currently working on and Gene is talking about Can you also explain why in the three use case you cited, EAP-GTC or MD5 doesn't meet the requirements, as they are all running inside an authenticated and encrypted tunnel? From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Yoav Nir Sent: Monday, April 28, 2008 8:13 AM To: emu@ietf.org Subject: Re: [Emu] EMU charter revision Gene Chang said: Dan, I am not sure I am able to clearly understand the end result you seek. It seems there is a clear consensus for a tunneled method. Are you pushing for the addition of a tunneled method? Ok... I am easily baited. What would you like to see to achieve more than a snail race? I am assuming we both believe the term snail race is a pejorative. Thus I ask you, how do we do better? I clearly hear your comment that there have been a paucity of comments, if nothing else, simply to affirm we are on track. I agree with the proposed charter. I am open to a discussion to add a non-tunneled method if there is sufficient demand. A non-tunneled method does not seem to promise enough features for the use cases that interest me
Re: [Emu] EMU charter revision
Joe: I approve the current charter revision and am willing to contribute to the tunnel method. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joseph Salowey (jsalowey) Sent: Tuesday, February 19, 2008 2:15 PM To: Joseph Salowey (jsalowey); emu@ietf.org Subject: Re: [Emu] EMU charter revision The response to the charter revision has been underwhelming. I am a bit concerned that we do not have enough participation to complete the tunnel method work (most of the recent discussion has been about other methods). I would like to get an idea of the number working group members that approve of working on the tunnel method items and are able to participate in the development of requirements and specifications as contributors and/or reviewers. Please respond to this message and state whether you approve of the current charter revision and what capacity you would be willing to contribute towards tunneled method development: contributor, reviewer or not able to contribute. I have submitted an internet draft attempt at an outline of requirements for tunneled methods (http://www.ietf.org/internet-drafts/draft-salowey-emu-eaptunn el-req-00. txt) that I hope can provided a starting point for discussions on the list and in the Philadelphia meeting. Thanks, Joe -Original Message- From: Joseph Salowey (jsalowey) Sent: Monday, February 04, 2008 9:13 PM To: emu@ietf.org Subject: EMU charter revision Below is a revised charter update based on the discussion on the list. I have left the password based method item as a tunnel method because this represents the consensus the working group has reached. I also believe the working group will have to focus on the tunnel method related items for the near term to make progress. This does not mean that we cannot work on additional methods as working group items in the future. Please review the charter update and post any issues you have with the carter. Please also indicate if you have reviewed the proposed charter and have no issues. It is difficult to judge working group consensus unless there are sufficient responses. Thanks, Joe Description of Working Group: The Extensible Authentication Protocol (EAP) [RFC 3748] is a network access authentication framework used in the PPP, 802.11, 802.16, VPN, PANA, and in some functions in 3G networks. EAP itself is a simple protocol and actual authentication happens in EAP methods. Over 40 different EAP methods exist. Most of these methods are proprietary methods and only a few methods are documented in RFCs. The lack of documented, open specifications is a deployment and interoperability problem. In addition, none of the EAP methods in the standards track implement features such as key derivation that are required for many modern applications. This poses a problem for, among other things, the selection of a mandatory to implement EAP method in new network access technologies. For example, no standards track methods meet new requirements such as those posed in RFC 4017, which documents IEEE 802.11 requirements for EAP methods. This group is chartered to work on the following types of mechanisms to meet RFC 3748 and RFC 4017 requirements: - An update to RFC 2716 to bring EAP-TLS into standards track, clarify specification, interoperability, and implementation issues gathered over the years, and update the document to meet the requirements of RFC 3748, RFC 4017, and EAP keying framework documents. Backwards compatibility with RFC 2716 is a requirement. - A mechanism based on strong shared secrets that meets RFC 3748 and RFC 4017 requirements. This mechanism should strive to be simple and compact for implementation in resource constrained environments. - A mechanism to support extensible communication within a TLS protected tunnel that meets RFC 3748 and RFC 4017 requirements. This mechanism must support channel bindings in order to meet RFC 4962 requirements and it must provide cryptographic algorithm agility. This mechanism will support meeting the requirements of an enhanced TLS mechanism, a password based authentication mechanism, and additional inner authentication mechanisms. - Enable a TLS-based EAP method to support channel bindings. So as to enable RFC 2716bis to focus solely on clarifications to the existing protocol, this effort will be handled in a separate document. This item will not generate a new method, rather it will enhance EAP-TLS or the TLS based tunnel method work item. - A mechanism meeting RFC 3748 and RFC 4017 requirements that makes use of existing password databases such as AAA databases. This item will be based on the tunnel method work item. Goals and Milestones:
RE: [Emu] WG consensus on charter update
Joe: I am ok with the updated charter, with the following minor comments: 1. Should we add crypto-agility to the requirements of tunnel method? And maybe strong shared secret method as well? 2. Move this paragraph right after the tunnel method paragraph, as it reference the tunnel method above. This way if causes less confusion with the TLS based channel binding method. A mechanism meeting RFC 3748 and RFC 4017 requirements that makes use of existing password databases such as AAA databases. This item will be based on the above tunnel method. 3. TLS based channel binding paragraph: Enable a TLS-based EAP method to support channel bindings. So as to enable RFC 2716bis to focus solely on clarifications to the existing protocol, this effort will be handled in a separate document. This item will not generate a new method, rather it will enhance EAP-TLS or the TLS based tunnel method. What does will not generate a new method mean? If we enhance EAP-TLS, we are likely need to create a new method ID (the current one doesn't have a version field). Even if we do, likely we will create backward compatibility issue. Sound like the tunnel method is better, so we creating minimum new EAP methods. If we choose the TLS based tunnel method, the requirements already cover the channel binding. Why don't we just make the decision now and say it is part of the tunnel method, or at least make the minimum operation mode of the tunnel method is just TLS with channel binding? -Original Message- From: Joseph Salowey (jsalowey) Sent: Thursday, January 24, 2008 12:45 PM To: emu@ietf.org Subject: [Emu] WG consensus on charter update So far I have only seen responses from Dan Harkins on the proposed charter update ( http://www1.ietf.org/mail-archive/web/emu/current/msg00712.html ) Please respond on the list if you have reviewed the charter and have comments or if you approve of the current text. Also make sure to review the milestones. Thanks, Joe ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
RE: [Emu] Password Method Consensus
I can help. -Original Message- From: Joseph Salowey (jsalowey) Sent: Tuesday, October 30, 2007 2:29 PM To: emu@ietf.org Subject: [Emu] Password Method Consensus We have working group consensus to move forward with working on a tunneled EAP method in order to provide the basis for a password based EAP method. The next steps are to revise the working group charter to include the tunneled EAP method item and make sure we have a good set of requirements to work against. I believe we already have a good start at requirements. Any volunteers to help document and track the requirements? Joe ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
RE: [Emu] Moving forward with the EMU password method
Me too. I like to see a standard based tunneling method, that supports crypto-binding, crypto-agility, internationalization, as well as a standard framework for extension within the tunnel. -Original Message- From: Ryan Hurst [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 03, 2007 7:16 PM To: Ray Bell; Stephen Hanna; Joseph Salowey (jsalowey); emu@ietf.org Subject: RE: [Emu] Moving forward with the EMU password method I also favor #2, I like Steve have found customers reluctant to deploy new methods if we can satisfy the goals with a method that's broadly deployed (with some tweaks) I think we will have more success than if we define a new one. -Original Message- From: Ray Bell [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 03, 2007 3:26 PM To: 'Stephen Hanna'; 'Joseph Salowey (jsalowey)'; emu@ietf.org Subject: RE: [Emu] Moving forward with the EMU password method I favor option 2 as well Ray -Original Message- From: Stephen Hanna [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 03, 2007 12:55 PM To: Joseph Salowey (jsalowey); emu@ietf.org Subject: RE: [Emu] Moving forward with the EMU password method I favor option 2. There are tunneling EAP methods already in widespread use that can meet the requirements with a few extensions (e.g. EAP-TTLSv0 with the extensions documented in draft-hanna-eap-ttls-agility-00.txt). Customers are understandably reluctant to deploy new EAP methods so it's much more likely that they will use the results of our work if we use an existing EAP method instead of defining a new method. Thanks, Steve -Original Message- From: Joseph Salowey (jsalowey) [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 03, 2007 11:03 AM To: emu@ietf.org Subject: [Emu] Moving forward with the EMU password method At the IETF in Chicago we had a hum as to the direction we should take with the password based method. I would like to clarify the choices and determine working group consensus on the list. The two directions are given below please express you preference by 10/25. Option 1 - Password based method - this option restricts the work item to what is currently in the charter. The resulting method would have a new method ID and selecting this method would mean selecting a password based exchange that meets the requirements we already set forth. The method may use an existing method as its base. Option 2 - Tunneling method - this option requires clarifying the charter to work on a tunneling method which would then be used to meet the password method requirements. This would include making sure we have a valid set of requirements to work with. The working group may select an existing method as its base and have backwards compatibility as a goal, however whether the method uses the same method ID and any modifications to the method will be determined by working group and IETF consensus. Thanks, Joe ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
RE: [Emu] Crypto-binding in TTLS-v0
Lakshminath: Do you mean channel binding, not compound binding? I thought crypto-binding is compound-binding. I think publishing a widely deployed EAP method is orthogonal to publishing a new method meeting EMU charter. I agree publishing the existing method as deployed is something needs to be done quickly. I am still doubtful that adding the extra stuff required to meet the charter (crypto-binding, crypto-agility, synchronized result indication, internationalization), to the existing method can be done without breaking backward compatibility. If indeed breaks it, then the argument of TTLS is widely deployed doesn't stand anymore. The new method or new version of the old method still needs to be implemented and deployed. -Original Message- From: Lakshminath Dondeti [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 22, 2007 12:45 AM To: Alan DeKok Cc: Sam Hartman; emu@ietf.org Subject: Re: [Emu] Crypto-binding in TTLS-v0 I would like to see the crypto-binding stuff (not compound binding -- as others have noted, we don't have consensus on that topic) and extensibility (how to add new attributes) specified. That should not take more than 1-2 months to write-up, review and finalize :). That should also be least disruptive to existing implementations. I would also like to see TTLS-v0 published very soon. regards, Lakshminath On 8/21/2007 9:38 PM, Alan DeKok wrote: Sam Hartman wrote: So, if EMU is going to base its work on something existing, it is probably important for EMU to take on the entire method. If consensus is to use EAP-TTLS, then I would suggest publishing the base EAP-TTLS document pretty much as-is as a standards-track document. The additional EMU requirements can be addressed in a separate document. This process lets us get something done quickly. I would prefer to void spending years talking about a new EAP method, followed by years of trying to get it widely deployed. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
RE: [Emu] Crypto-binding in TTLS-v0
There is an EAP-FAST module for EAPHost plug-in, which currently uses three hard coded inner methods, EAP-GTC, EAP-MSCHAPv2 and EAP-TLS. But it can be extended to work with EAPHost supplicant interface to load any inner method registered with EAPHost. Will you have a POTP plug-in soon? The problem is to find a server that supports provisioning with POTP. I can work with you to make it happen. -Original Message- From: Gene Chang (genchang) Sent: Thursday, August 16, 2007 11:36 AM To: [EMAIL PROTECTED]; emu@ietf.org Subject: RE: [Emu] Crypto-binding in TTLS-v0 Dave, There is an EAP-FAST implementation on FreeRADIUS from Jouni Malinan. I don't know how much testing has already gone into the module. I don't know of a client side implementation with APIs for you to integrate the SecurID PAC provisioning. Gene -- -- Eugene Chang (genchang) WNBU, Technical Leader Office: 603-559-2978 Mobile: 781-799-0233 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, August 16, 2007 11:01 AM To: emu@ietf.org Subject: RE: [Emu] Crypto-binding in TTLS-v0 I with Alan on this. I still haven't seen one yet either. But I'd love to see a version of EAP-FAST that I _could_ work with. Meaning; - it runs with something more accessible than the Cisco ACS server, preferably an open source or reference copy. Maybe even an Windows/IAS plugin. - there is a Windows EAPhost supplicant availible, preferably with interfaces for tunnelled methods and/or interfaces for the ID we wrote for SecurID PAC provisioning. draft-cam-winget-eap-fast-potp-provisioning-00.txt (hmm... time to renew that) If you have any of this, let me know. Dave Mitton, RSA - Security Division of EMC. Original Message From: [EMAIL PROTECTED] Date: Aug 16, 2007 10:13 To: Alan DeKok[EMAIL PROTECTED], Nancy Winget (ncamwing) [EMAIL PROTECTED] Cc: Ryan Hurst[EMAIL PROTECTED], emu@ietf.org Subj: RE: [Emu] Crypto-binding in TTLS-v0 Alan, It is not unusual for developers to be unaware of the breath of the EAP-FAST market adoption. It has been growing under the radar for a lot of people since market research firms do not track market share of different EAP methods. Part of the misperception that EAP-FAST has no market presence has been because no one has been drawing attention to the adoption success of EAP-FAST. I am hoping to assemble some public data to shed a light on the secret life of EAP-FAST. Gene -- -- Eugene Chang (genchang) WNBU, Technical Leader Office: 603-559-2978 Mobile: 781-799-0233 -Original Message- From: Alan DeKok [mailto:[EMAIL PROTECTED] Sent: Thursday, August 16, 2007 8:46 AM To: Nancy Winget (ncamwing) Cc: Ryan Hurst; emu@ietf.org Subject: Re: [Emu] Crypto-binding in TTLS-v0 Nancy Winget (ncamwing) wrote: Thanks Alan, I am glad to see that the evaluation is continuing on the thread.I think both TTLS and EAP-FAST are being widely deployed and both merit consideration. I think EAP-FAST has been considered, and has little support. I've never seen an EAP-FAST deployment, and most people I talk to haven't seen one, either. Most people I talk to don't plan on supporting EAP-FAST any time soon. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
RE: [Emu] Issue with RFC 2716bis key generation
Is there any reason not to use the approach in RFC2716Bis? This guarantees backward compatibility and require less computation. From: Bernard Aboba [mailto:[EMAIL PROTECTED] Sent: Thursday, June 07, 2007 3:05 PM To: emu@ietf.org Subject: [Emu] Issue with RFC 2716bis key generation It has been pointed out by Paul Funk that the key generation formula specified in RFC 2716bis could cause backward compatibility problems once TLS v1.2 is introduced. The formula in -09 is as follows: MSK(0,63)= TLS-PRF-64(TMS, client EAP encryption, client.random || server.random) EMSK(0,63) = second 64 octets of: TLS-PRF-128(TMS, client EAP encryption, client.random || server.random) IV(0,63) = TLS-PRF-64(, client EAP encryption, client.random || server.random) The issue here is that RFC 2716 Section 3.5 specifies a different approach: MSK(0,63) = first 64 octets of: TLS-PRF-128(TMS, client EAP encryption, client.random || server.random) EMSK(0,63) = second 64 octets of: TLS-PRF-128(TMS, client EAP encryption, client.random || server.random) IV(0,63) = TLS-PRF-64(, client EAP encryption, client.random || server.random) With the current TLS PRF, these two approaches are identical. However, this is not necessarily true for all PRFs that could conceivably be negotiated within TLS v1.2. The text from RFC 2716 Section 3.5 reads as follows: Since the normal TLS keys are used in the handshake, and therefore should not be used in a different context, new encryption keys must be derived from the TLS master secret for use with PPP encryption. For both peer and EAP server, the derivation proceeds as follows: given the master secret negotiated by the TLS handshake, the pseudorandom function (PRF) defined in the specification for the version of TLS in use, and the value random defined as the concatenation of the handshake message fields client_hello.random and server_hello.random (in that order), the value PRF(master secret, client EAP encryption, random) is computed up to 128 bytes, and the value PRF(, client EAP encryption, random) is computed up to 64 bytes (where is an empty string). The peer encryption key (the one used for encrypting data from peer to EAP server) is obtained by truncating to the correct length the first 32 bytes of the first PRF of these two output strings. The EAP server encryption key (the one used for encrypting data from EAP server to peer), if different from the client encryption key, is obtained by truncating to the correct length the second 32 bytes of this same PRF output string. The client authentication key (the one used for computing MACs for messages from peer to EAP server), if used, is obtained by truncating to the correct length the third 32 bytes of this same PRF output string. The EAP server authentication key (the one used for computing MACs for messages from EAP server to peer), if used, and if different from the peer authentication key, is obtained by truncating to the correct length the fourth 32 bytes of this same PRF output string. The peer initialization vector (IV), used for messages from peer to EAP server if a block cipher has been specified, is obtained by truncating to the cipher's block size the first 32 bytes of the second PRF output string mentioned above. Finally, the server initialization vector (IV), used for messages from peer to EAP server if a block cipher has been specified, is obtained by truncating to the cipher's block size the second 32 bytes of this second PRF output. ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
RE: [Emu] Thoughts on Password-based EAP Methods
What is the difference between defining a new method vs. a new version of the existing EAP method that is not backward compatible? I don't see how the implementation issue will go away. Some one still needs to implement it and customers need to deploy it. Might be more confusing to define another version of TTLS, as there are two version defined already, version 0 and 1. It seems to me much cleaner to start from a standard based EAP method handling password-only, and gradually extending it over time. -Original Message- From: Ryan Hurst [mailto:[EMAIL PROTECTED] Sent: Monday, April 02, 2007 3:48 PM To: Joseph Salowey (jsalowey); Bernard Aboba; emu@ietf.org Subject: RE: [Emu] Thoughts on Password-based EAP Methods I believe there were many issues with how PEAP progressed, if we are careful we could prevent the same things from happening with TTLS. Ryan -Original Message- From: Joseph Salowey (jsalowey) [mailto:[EMAIL PROTECTED] Sent: Monday, April 02, 2007 12:36 PM To: Bernard Aboba; emu@ietf.org Subject: RE: [Emu] Thoughts on Password-based EAP Methods I'm not sure that adding yet another version to TTLS specifically for supporting passwords will make things better for customers. Multiple versions certainly has caused quite a confusion in PEAP. -Original Message- From: Bernard Aboba [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 27, 2007 8:07 AM To: emu@ietf.org Subject: [Emu] Thoughts on Password-based EAP Methods After listening to the IETF 68 presentation on a password-based EAP method, I would like to voice some concerns. Today we already have an over abundance of such methods. These include PEAPv0, PEAPv1, EAP-TTLSv0, EAP-TTLSv1, and EAP-FAST. In my discussions with customers, I invariably hear complaints about this explosion, and about various interoperability and compatibility problems that it causes. Simply put, customers do not want yet another password-based EAP method; they want a single method that is widely implemented and interoperable. I am concerned that by defining yet another password-based authentication mechanism, EMU WG will be making this problem worse, not better. Creating yet another mechanism which differs little from the existing ones also seems to have very little chance of being implemented. There is a better alternative that EMU WG should consider. This is to choose an existing method for inclusion on the IETF Standards Track, rather than creating a new one. In order to maintain backward compatibility, this would require that the owners give up change control to the IETF. I would suggest that the best candidate for this would be EAP-TTLSv0, since it is very widely implemented, and has an existing certification program in WFA. Also, EAP-TTLSv0 had previously been on the Standards Track in the PPPEXT WG, before work on EAP methods was removed from the PPPEXT WG charter and the EAP WG was formed. In terms of steps to be taken, this would require the following actions: a. Review and publication of the existing EAP-TTLSv0 specification as an RFC. The goal here would be to document EAP-TTLSv0 as it exists today. b. Agreement by the authors to give up change control to the IETF. c. EMU WG efforts to publish an EAP-TTLSv0 bis document, specifying additional capabilities (such as Channel Bindings). ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
RE: [Emu] Thoughts on Password-based EAP Methods
Bernard: I am not sure reusing one of the existing EAP methods is the right approach. All three EAP method mentioned, EAP-TTLS/PEAP/EAP-FAST all has something that are outside the scope of the charter, which means we have to take some of them out. Not unitl we change the charter, then we can pick one of them and declare victory. Some (if not all) are also missing some features required, like crypto-agility, etc. This means we will change the existing protocol and make it not backward compatible. There will be the same issue with implementation whether a new EAP method or a modified EAP method. I think part of the benefits of defining a new standard EAP method, people will want to implement it, as opposed to implement according to some expired draft. The design team are aware of TTLS and is working towards something that will probably be similar and much simpler. We try to strive for something simple but extensible, then over time we can enhance it as it is in IETF control. EAP-TTLS itself also has its own issues: 1. It's internal AVP uses Radius attribute, I am not sure that' a good idea. 2. There is also TTLSv1 draft, which is quite different than v0. I am not sure about there are actual implementations or not. But if we create another modified TTLS from TTLSv0, it might create confusions. 3. The patent issue mentioned by Pascal. -Original Message- From: Bernard Aboba [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 27, 2007 11:07 AM To: emu@ietf.org Subject: [Emu] Thoughts on Password-based EAP Methods After listening to the IETF 68 presentation on a password-based EAP method, I would like to voice some concerns. Today we already have an over abundance of such methods. These include PEAPv0, PEAPv1, EAP-TTLSv0, EAP-TTLSv1, and EAP-FAST. In my discussions with customers, I invariably hear complaints about this explosion, and about various interoperability and compatibility problems that it causes. Simply put, customers do not want yet another password-based EAP method; they want a single method that is widely implemented and interoperable. I am concerned that by defining yet another password-based authentication mechanism, EMU WG will be making this problem worse, not better. Creating yet another mechanism which differs little from the existing ones also seems to have very little chance of being implemented. There is a better alternative that EMU WG should consider. This is to choose an existing method for inclusion on the IETF Standards Track, rather than creating a new one. In order to maintain backward compatibility, this would require that the owners give up change control to the IETF. I would suggest that the best candidate for this would be EAP-TTLSv0, since it is very widely implemented, and has an existing certification program in WFA. Also, EAP-TTLSv0 had previously been on the Standards Track in the PPPEXT WG, before work on EAP methods was removed from the PPPEXT WG charter and the EAP WG was formed. In terms of steps to be taken, this would require the following actions: a. Review and publication of the existing EAP-TTLSv0 specification as an RFC. The goal here would be to document EAP-TTLSv0 as it exists today. b. Agreement by the authors to give up change control to the IETF. c. EMU WG efforts to publish an EAP-TTLSv0 bis document, specifying additional capabilities (such as Channel Bindings). ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
