Jim: Sorry for the late response. Will address all of them in the new draft. Individual comments inline below. Thanks.
From: Jim Schaad <i...@augustcellars.com<mailto:i...@augustcellars.com>> Date: Wednesday, November 14, 2012 10:25 PM To: Cisco Employee <hz...@cisco.com<mailto:hz...@cisco.com>> Cc: "emu@ietf.org<mailto:emu@ietf.org>" <emu@ietf.org<mailto:emu@ietf.org>> Subject: RE: [Emu] Review of draft-ietf-emu-eap-tunnel-method-00 From: Hao Zhou (hzhou) [mailto:hz...@cisco.com] Sent: Thursday, October 04, 2012 10:39 AM To: Jim Schaad Cc: emu@ietf.org<mailto:emu@ietf.org> Subject: Re: [Emu] Review of draft-ietf-emu-eap-tunnel-method-00 Jim: Thanks very much for your detailed review. Please see the comments below. We will respond to your other emails shortly. On 9/28/12 9:18 PM, "Jim Schaad" <i...@augustcellars.com<mailto:i...@augustcellars.com>> wrote: 1. In section 3.2.3, it says that a new PAC can be requested after a full TLS handshake. Can one be requested following an abbreviated handshake? Or do you just re-use the existing PAC? [HZ] RFC5077 does not specify that client can request a new ticket after sending the TLS ticket, if the client is resuming a session using the session ticket, then it cannot request a new session ticket based on resumed session. We will add some language to clarify that it is not allowed. [JLS] I am not currently seeing this text. [HZ] Sorry, we missed that. Will add to Draft 05. 3. Section 3.4 - Is it possible to have multiple server ids after the authentication - one from the tunnel and others from the inner EAP methods. I realize that most EAP methods don't send a sender id, but some (IBAKE for example) currently do. Also, the client might have an idea of what the sender id is from configuration. If so, do these all need to get exported as server-id values? [HZ] Good catch. We will add a sentence similar to peer-ID, where multiple server IDs need to be exported. [JLS] The text for this is potentially confusing. Identity types are currently only defined for peer identities and not for server identities. [HZ] Good catch again, Will fix it. 5. In section 3.6.1 - Is the restart only an issue for fatal alerts, or is it a problem for all alerts? [HZ] Restart is only allowed for non-fatal alerts, per TLS RFC. "Upon transmission or receipt of a fatal alert message, both parties immediately close the connection.", so restart is not desired in this case. We will clarify that restart is only allowed in non-fatal alert cases. [JLS] I don’t currently see this text modification. [HZ] Will add that now. 8. In section 3.8 - I have the following questions a) In the text "The request MAY be issued", I don't understand the MAY at this point. Is it supposed to say that the request can be issued either before or after the authentication has finished, or is it saying that the peer has the option of issuing or not issuing the request, but must wait until the authentication level has been reached? [HZ] It's the later. How about add "only" in front "after the peer has determined that..."? [JLS] yes this deals with the main problem. I would suggest that the sentence this is included in be review for grammar. [HZ] Ok, will remove "if an inner EAP authentication occurs to ensure that the TLS tunnel's integrity is Intact" from the sentence to make it parses better and more accurate. 15. Section 4.2.3 - I assume that there should only be one Identity-Type TLV in a TEAP packet. Should a request for authentication be present in the packet as well? If multiple are allowed then information about how to treat this should be included. What should the peer respond with if it does have an identity of the type? This is not explicitly stated. [HZ] That's correct, only one Identity-Type TLV is allowed.The requested Identity type MUST comes with an EAP request or Basic-Password-Auth-Req. If the peer has the requested identity type, it should send back the same identity type TLV in the response. We missed this and will add this clarification. [JLS] I don’t know that text exists to say that the MUST in the second sentence is true. [HZ] Will add that sentence now. 18. Section 4.2.8 - Do we need to talk about the question of having some Vender TLVs be marked as mandatory and others not. Are we using the same TLV structure with the same rules for mandatoriness. If the mandatory bit is set, does that mean that I need to recognize the vendor-id or all combinations of vender-id/Vender-TLV type? [HZ] Yes. If the mandatory bit is set on the Vendor-Speific TLV, then the peer need to recognize the vendor ID and all combination of the vendor TLVs. The Vendor TLV format is up to the vendor to define, as specified by the current draft. [JLS] After looking at this I think that I disagree. If a Venter TLV is marked as mandatory, then the vender ID needs to be recognized and you need understand how to deal with it. The vender should specify it’s own mandatory requirements internally. So top level bit would not cover all combinations of the vendor TLVs. [HZ] Sounds reasonable. Will change.
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
