RE: [Emu] Moving forward with the EMU password method
I also favor option 2. There are already several tunneling EAP methods in widespread use. There is already concern that there are too many alternatives. We should avoid introducing a new EAP method. It would be better to (a) use an existing EAP method, (b) merge some of the existing methods, or (c) if necessary, perfect an existing method to meet our needs. Gene Eugene Chang (genchang) Office: 603-559-2978 Mobile: 781-799-0233 -Original Message- From: Stephen Hanna [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 03, 2007 3: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
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
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] EAP-GPSK and Client-Side DoS Attacks
I think the problem is real, although not catastrophic. I would prefer not to remove the identity from the key derivation so either option 2 or 3 is good. I think 2 is maybe a little bit cleaner and 3 is less of a change to the existing draft. Since we do not have many implementations yet I would slightly favor 2. -Original Message- From: Tschofenig,Hannes (NSN - DE/Germany - MiniMD) [mailto:[EMAIL PROTECTED] Sent: Thursday, September 20, 2007 1:51 AM To: emu@ietf.org Subject: [Emu] EAP-GPSK and Client-Side DoS Attacks Hi all, What is the issue? The first message from the server to the peer is not authenticated. This may allow some kind of denial of service attack against the peer. The peer should be ready to accept new sessions from the same server, so the peer must store one server nonce and one peer nonce for each message 1 it receives. An attacker can then flood the network with fake message 1s to overflow the peer's buffer. This issue is similar to an issue found in the 802.11i 4-way handshake. When receiving message 1, the peer checks to see if it has open conversations with the server listed in the message. If it does, then it will reuse the peer nonce it already sent. In addition, it will not store the server nonce, since the server nonce comes back in message 3. Message 3 then contains almost all the information necessary to validate the MAC. It is only missing the ID_Server. There seem to be three ways to solve this which are discussed in the next paragraph. 1) The first is to drop ID_Server from the input string, allowing the peer to check the MAC without the ID. This might require another NIST review. 2) The second is to add ID_Server to message 3. 3) Thirdly, the peer could iterate through its list of associated servers trying to find one which matches. This allows the peer to store state per server instead of storing state per message. Since the peer has a fixed (for the duration of a DoS attack) and limited number of associated servers, this fixes the attack. Initially, I was a bit curious about the need to allocate state on the client side with an injected Message 1 by the adversary. The text in Section 4.2 of [1] was, however, convincing that the end host needs to keep state information of multiple sessions even if it only accepts a single one since otherwise you would be able to put the client into a blocking state. [1] focuses on a case where only a single nonce is used in message 3 whereas in EAP-GPSK both nonces are present in message 3. When the client receives message (3) then it needs to derive keying material based on the following info: RAND_Peer, ID_Peer, RAND_Server, ID_Server, RAND_Peer, RAND_Server is in message 3 provided by the server and ID_Peer is known to the peer. The EAP peer may have multiple identities too. Hence, in EAP-GPSK at least the ID_Server attribute is missing in message 3. Now, the question is how many EAP server identities a client has. I suspect only a single one, with the realm name for the entire domain (with respect to a particular credential) and how many identities the client uses. In any case, I agree with the assessment and the need to document something in the draft. Do you agree that the problem is real? If yes, what type of solution approach would the group prefer? Ciao Hannes Reference: [1] Changhua He, John C. Mitchell. Analysis of the 802.11i 4-Way Handshake. In Proceedings of the Third ACM International Workshop on Wireless Security (WiSe'04), pages 43-50. Philadelphia, PA, Oct. 2004 ___ 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] EAP-GPSK Key Derivation Function
I think this is a good approach. -Original Message- From: Charles Clancy [mailto:[EMAIL PROTECTED] Sent: Thursday, September 20, 2007 4:11 AM To: Tschofenig,Hannes (NSN - DE/Germany - MiniMD) Cc: emu@ietf.org Subject: Re: [Emu] EAP-GPSK Key Derivation Function All, My suggestion is adding the following to the GPSK document: - For AES ciphersuite say keys MUST be 128 bits in length or longer, and longer keys be truncated to 128 bits for use - For HMAC ciphersuite say keys MUST be 256 bits in length or longer, and longer keys be truncated to 256 bits for use - RECOMMEND that 256 bit keys be provisioned in all cases to provide enough entropy for all current and many possible future ciphersuites - Add a new section describing requirements on future ciphersuites that addresses necessary security requirements and describes their need to specify PSK sizes and how they deal with different-length keys -- t. charles clancy, ph.d. | [EMAIL PROTECTED] | www.cs.umd.edu/~clancy Tschofenig, Hannes (NSN - DE/Germany - MiniMD) wrote: Hi all, What is the issue? The derivation of MK uses 0x00 as a key for the KDF. Here is the key derivation step: MK = GKDF-16 (zero, PL || PSK || CSuite_Sel || inputString) ^ Here is the problem. Here is what Charles recognized during the discussion: I just looked though the definition of CMAC, the MAC used in one of our two ciphersuites, and the zero key looks like it might cause some problems. Unlike the HMAC ciphersuites, it doesn't simply concatenate the key with the data input. The first step is to compute: k0=E_k(0x00) k1=k0*x mod p(x) k2=k1*x mod p(x) These values would always be fixed. During the CBC operation, they are XOR'd with the final message block. k1 is XOR'd if the final message block's length matches the encryption block length. k2 is used otherwise on a message padded with 1000...b. I think what using an all-zero key does is reduce the security of CMAC to the security of CBC-MAC with an all-zeros IV. While the ramifications of this are debatable for our applications, it's still probably not a great idea. Currently we can't use the PSK as the input to the first KDF because its length may not match the selected ciphersuite's block length. We wanted to try to do was have a ciphersuite that could be implemented using only AES. Do you agree that the problem is real? If yes, then we believe that there are the following solution steps: 1) We would need some way to normalize the length of the PSK for the selected ciphersuite. We could define an additional cryptographic primitive in every ciphersuite that does this derivation, such as SHA256-128 for the AES ciphersuite and SHA256 for the HMAC ciphersuite. 2) We could switch to a different KDF, for example to the one used for IKEv2. Can you come up with other solution approaches? Which solution approach should we pick? Ciao Hannes ___ 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
