[Emu] Comments on emu-eap-tunnel-method-02
1. After the first exchange of messages, if the version does not match the agreed on version - what happens? 2. Section 3.2 says that one should be able to do a renegotiate for getting the peers identity certificate. Do the following points need to be made? a) If you are doing a re-negotiation - then you SHOULD not be using an anonymous cipher suite b) Once you have started phase 2, re-negotiation MUST NOT be done. 3. in section 3.3.1 - did you miss changing and EAP-TLS to a TEAP? For example, EAP-TLS... If not, then I would suggest changing to a std track protocol. 4. In section 3.4 - I want to make sure that what I read is what you intend. == If I do multiple (one or more) inner EAP methods, the authenticated peer identity is the set of all of these identities. == If I do zero inner EAP methods and I do a client auth TLS, the authenticated peer identity comes from the certificate. == If I do zero inner EAP methods and do not do a client auth TLS, then I have no authenticated peer identity. -- specifically - should the client auth TLS identity be excluded if I run an inner EAP method -- Specifically - should the all non EAP methods be excluded -- include the TEAP defined user name/password -- Specifically - should any EAP server name established in an EAP method be excluded from its name set? 5. In section 3.8 - potentially ambiguous statement: The request MAY be issued after the peer has determined... Is the request the MAY or the timing of the request the MAY? 6. In section 4.2.3 - What is the registration policy for the Identity-Type field of the Identity-Type TLV? Do there need to be reserved ranges for use by specific Servers - i.e. local use? Or is that insane? 7. In section 4.2.4 - What do I do for an defined value. Do these values only match those of the available through the base document or are other 8. In section 4.2.9 - Are the TLVs to be processed and the EAP to negotiate to be included in the peer response? 9. Does the order of items in the TLV list matter? Or are specific TLVs expected to be processed first. For example what would be the expected order on the Identity-Type TLV and the EAP-Payload TLV? 10. Section 4.2.12.2 says the key is of a specific length, yet there is length field. Why is a specific length mentioned esp as the length was just changed in the last version. I assume this key length is dependent on the PAC type and should not be fixed. 11. Section 4.2.15 - If we change the standard way of doing name preparation, should we be creating a new item, or should we have a byte field that specifies the username/password processing function. 12. Section 5.2 - Does the truncation and expansion to 32-bytes still hold true if the TLS-PRF were to use a new cypher suite that used P_SHA512? Jim ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Comments on emu-eap-tunnel-method-02
Jim: Thanks for the detailed review. My comments are below inline: On 3/21/12 6:15 AM, Jim Schaad i...@augustcellars.com wrote: 1. After the first exchange of messages, if the version does not match the agreed on version - what happens? [HZ] Good catch. Both sides should stick with the version negotiated. I guess we will add some language to describe the behavior handling exceptions. My initial thoughts are both sides should treat it as fatal error and proceed with fatal error processing, e.g., server should just send back EAP-Failure and peer sends back EAP-Nak. 2. Section 3.2 says that one should be able to do a renegotiate for getting the peers identity certificate. Do the following points need to be made? a) If you are doing a re-negotiation - then you SHOULD not be using an anonymous cipher suite b) Once you have started phase 2, re-negotiation MUST NOT be done. [HZ] Good points. I will add them. 3. in section 3.3.1 - did you miss changing and EAP-TLS to a TEAP? For example, EAP-TLS... If not, then I would suggest changing to a std track protocol. [HZ] No. It is meant to say EAP-TLS. I thought EAP-TLS RFC5216 is a std track RFC. 4. In section 3.4 - I want to make sure that what I read is what you intend. == If I do multiple (one or more) inner EAP methods, the authenticated peer identity is the set of all of these identities. == If I do zero inner EAP methods and I do a client auth TLS, the authenticated peer identity comes from the certificate. == If I do zero inner EAP methods and do not do a client auth TLS, then I have no authenticated peer identity. [HZ] Correct except last one. I would say the authenticated peer identity comes from any inner method, not necessary EAP method. So if a password TLV exchange happened, then the authenticated peer identity is coming from that password authentication TLV exchange. I think we will change the word inner EAP method to inner authentication method. -- specifically - should the client auth TLS identity be excluded if I run an inner EAP method [HZ] No. -- Specifically - should the all non EAP methods be excluded -- include the TEAP defined user name/password [HZ] No. -- Specifically - should any EAP server name established in an EAP method be excluded from its name set? [HZ] It could be included as part of the Server-ID if the server is not authenticated as part of the tunnel establishment. I will add some text to address this. 5. In section 3.8 - potentially ambiguous statement: The request MAY be issued after the peer has determined... Is the request the MAY or the timing of the request the MAY? [HZ] Good catch. It is the request MAY. Timing is should be after validating the crypto-binding TLV. I will address that. 6. In section 4.2.3 - What is the registration policy for the Identity-Type field of the Identity-Type TLV? Do there need to be reserved ranges for use by specific Servers - i.e. local use? Or is that insane? [HZ] I missed that in IANA section. It should be Spec Required as others. I don't see need for local use types. 7. In section 4.2.4 - What do I do for an defined value. Do these values only match those of the available through the base document or are other [HZ} I am confused. Are you talking about Section 4.2.4 Result TLV or others? 8. In section 4.2.9 - Are the TLVs to be processed and the EAP to negotiate to be included in the peer response? [HZ] Yes. I will add a sentence or two describe this. 9. Does the order of items in the TLV list matter? Or are specific TLVs expected to be processed first. For example what would be the expected order on the Identity-Type TLV and the EAP-Payload TLV? [HZ] It shouldn't matter. But I would think Identity-Type TLV should precede EAP-Payload TLV. Let me think about maybe some other cases order is important and document that. 10. Section 4.2.12.2 says the key is of a specific length, yet there is length field. Why is a specific length mentioned esp as the length was just changed in the last version. I assume this key length is dependent on the PAC type and should not be fixed. [HZ] You are correct. It shouldn't be fixed, to be crypto-agile. Will fix that. 48 octets are just an example, maybe minimum length. 11. Section 4.2.15 - If we change the standard way of doing name preparation, should we be creating a new item, or should we have a byte field that specifies the username/password processing function. [HZ] Can you provide an example why UTF-8 is not sufficient? Are you proposing adding a namespace or type for the name preparation, as opposed to standard UTF-8? 12. Section 5.2 - Does the truncation and expansion to 32-bytes still hold true if the TLS-PRF were to use a new cypher suite that used P_SHA512? [HZ] Good question. In current draft, the key length of the keying materials to be mixed are somewhat fixed. I didn't see the need to extend it yet. Jim
Re: [Emu] Comments on emu-eap-tunnel-method-02
You might also need to put in an IANA consideration for the use of the TLS Exporter (http://www.iana.org/assignments/tls-parameters/tls-parameters.xml#exporter- labels) Jim -Original Message- From: Hao Zhou [mailto:hz...@cisco.com] Sent: Wednesday, March 21, 2012 11:26 AM To: Jim Schaad; draft-ietf-emu-eap-tunnel-met...@tools.ietf.org Cc: emu@ietf.org Subject: Re: [Emu] Comments on emu-eap-tunnel-method-02 Jim: Thanks for the detailed review. My comments are below inline: On 3/21/12 6:15 AM, Jim Schaad i...@augustcellars.com wrote: 1. After the first exchange of messages, if the version does not match the agreed on version - what happens? [HZ] Good catch. Both sides should stick with the version negotiated. I guess we will add some language to describe the behavior handling exceptions. My initial thoughts are both sides should treat it as fatal error and proceed with fatal error processing, e.g., server should just send back EAP-Failure and peer sends back EAP-Nak. 2. Section 3.2 says that one should be able to do a renegotiate for getting the peers identity certificate. Do the following points need to be made? a) If you are doing a re-negotiation - then you SHOULD not be using an anonymous cipher suite b) Once you have started phase 2, re-negotiation MUST NOT be done. [HZ] Good points. I will add them. 3. in section 3.3.1 - did you miss changing and EAP-TLS to a TEAP? For example, EAP-TLS... If not, then I would suggest changing to a std track protocol. [HZ] No. It is meant to say EAP-TLS. I thought EAP-TLS RFC5216 is a std track RFC. 4. In section 3.4 - I want to make sure that what I read is what you intend. == If I do multiple (one or more) inner EAP methods, the authenticated peer identity is the set of all of these identities. == If I do zero inner EAP methods and I do a client auth TLS, the authenticated peer identity comes from the certificate. == If I do zero inner EAP methods and do not do a client auth TLS, then I have no authenticated peer identity. [HZ] Correct except last one. I would say the authenticated peer identity comes from any inner method, not necessary EAP method. So if a password TLV exchange happened, then the authenticated peer identity is coming from that password authentication TLV exchange. I think we will change the word inner EAP method to inner authentication method. -- specifically - should the client auth TLS identity be excluded if I run an inner EAP method [HZ] No. -- Specifically - should the all non EAP methods be excluded -- include the TEAP defined user name/password [HZ] No. -- Specifically - should any EAP server name established in an EAP method be excluded from its name set? [HZ] It could be included as part of the Server-ID if the server is not authenticated as part of the tunnel establishment. I will add some text to address this. 5. In section 3.8 - potentially ambiguous statement: The request MAY be issued after the peer has determined... Is the request the MAY or the timing of the request the MAY? [HZ] Good catch. It is the request MAY. Timing is should be after validating the crypto-binding TLV. I will address that. 6. In section 4.2.3 - What is the registration policy for the Identity-Type field of the Identity-Type TLV? Do there need to be reserved ranges for use by specific Servers - i.e. local use? Or is that insane? [HZ] I missed that in IANA section. It should be Spec Required as others. I don't see need for local use types. 7. In section 4.2.4 - What do I do for an defined value. Do these values only match those of the available through the base document or are other [HZ} I am confused. Are you talking about Section 4.2.4 Result TLV or others? 8. In section 4.2.9 - Are the TLVs to be processed and the EAP to negotiate to be included in the peer response? [HZ] Yes. I will add a sentence or two describe this. 9. Does the order of items in the TLV list matter? Or are specific TLVs expected to be processed first. For example what would be the expected order on the Identity-Type TLV and the EAP-Payload TLV? [HZ] It shouldn't matter. But I would think Identity-Type TLV should precede EAP-Payload TLV. Let me think about maybe some other cases order is important and document that. 10. Section 4.2.12.2 says the key is of a specific length, yet there is length field. Why is a specific length mentioned esp as the length was just changed in the last version. I assume this key length is dependent on the PAC type and should not be fixed. [HZ] You are correct. It shouldn't be fixed, to be crypto-agile. Will fix that. 48 octets are just an example, maybe minimum length. 11. Section 4.2.15 - If we change the standard way of doing name preparation, should we be creating a new item, or should we have a byte field that specifies the username/password
