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 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 > > > > > > _______________________________________________ > > 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
