Hi Joel, Thank you for your timely and considered review. Paul's responses below.
regards, Lakshminath > > -----Original Message----- > > From: Lakshminath Dondeti [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, March 25, 2008 7:06 PM > > To: [EMAIL PROTECTED] > > Subject: [Fwd: Re: [Gen-art] IETF LC review: draft-funk-eap-ttls-v0-04.txt] > > > > > > > > -------- Original Message -------- > > Subject: Re: [Gen-art] IETF LC review: draft-funk-eap-ttls-v0-04.txt > > Date: Fri, 21 Mar 2008 19:26:51 -0400 > > From: Joel M. Halpern <[EMAIL PROTECTED]> > > To: Mary Barnes <[EMAIL PROTECTED]> > > CC: [email protected], Lakshminath Dondeti <[EMAIL PROTECTED]>, > > Jari Arkko <[EMAIL PROTECTED]> > > References: > > <[EMAIL PROTECTED]> > > > > I have been selected as the General Area Review Team (Gen-ART) > > reviewer for this draft (for background on Gen-ART, please see > > http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). > > > > Please resolve these comments along with any other Last Call comments > > you may receive. > > > > > > Document: EAP Tunneled TLS Authentication Protocol Version 0 > > Reviewer: Joel M. Halpern > > Review Date: 21-March-2008 > > IETF LC End Date: 2-April-2008 > > IESG Telechat date: N/A > > > > Summary: This document is ready for publication as an Informational RFC. > > If a revision is to be done, it would make sense to consider the first > > two comments below, and see if the minor comments can be usefully addressed. > > > > Comments: > > There are two sets of AVPs defined by this document. One set goes in > > the EAP-TTLS Start packet from the server to the client. The other set > > are used in the inner TLS protected exchange. The first set are > > referenced in section 9.2. But as far as I can tell, there is no > > description of what valid AVPs may appear here. Even if they are the > > same AVPs as go inside, some text explaining this in section 9.2 would > > be helpful. [pf] Section 9.2 indicates that AVPs may be sent in the clear in the initial Start packet from the server. I don't know if any implementation uses this feature. Possible uses are indicated in the text. While there is no currently defined use case, the purpose of including this text was: 1 To ensure that receivers understand that there might be data following the Start indication, so they won't reject the packet on that basis. 2 To define the format of any such data to prevent overloading and consequent misinterpretation. Future specs can define uses for Start packet AVPs, within the confines that are currently specified. > > Section 7.2 talks about the application utilizing EAP-TTLS specifying > > the information to be exchanged. It is not clear to me what is meant by > > "application" here. Does this mean the different authentication > > mechanisms that the client can select? Or something else? (If > > something else, how is it known.) A bit of explanatory text would > > probably help. [pf] "Application" here simply means whatever pre-conceived use TTLS is being put to, that is, a context understood by client and server; e.g. 802.11, WiMA, IKEv2. Such "applications" are free to specify particular AVP exchanges required to enable features of the application. > > > > Minor: > > The text in section 7.8 talks about the different versions of TLS > > that can be used. It would be useful (assuming I have correctly > > understood the protocol) if the text noted that these versions are > > negotiated by TLS, as part of carrying TLS over TTLS. [pf] It already does, in the immediately preceding section 7.7. > > Section 11.3 on multiple authentication methods could use a couple > > of extra words at the front. Something like "When the client has > > selected EAP for authentication, the AAA/H server may request multiple > > forms of Authentication." Otherwise, the reader tries to tie this to > > the entirety of 11.2 (client specified authentication) and may get very > > confused before finding at the end of the section the note that this > > only applies to EAP. (Leave the note. Just add text at the beginning.) [pf] The first sentence of the second paragraph does say "using EAP", indicating that this is an EAP-related mechanism. The final note reinforces this. > > > > > > I presume I will find out how the communicating parties agree on what > > "application" is utilizing EAP-TTLS some time after section 7.2? [pf] No, "application" is assumed to be implicit. For example, the client knows what type of network it is authenticating to, and the server either because it is deployed to handle a particular application or because the carrier protocol tells it (e.g. Service-Type in RADIUS). > > > > > > On 3/21/2008 4:26 PM, Joel M. Halpern wrote: > I have been selected as the General Area Review Team (Gen-ART) > reviewer for this draft (for background on Gen-ART, please see > http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). > > Please resolve these comments along with any other Last Call comments > you may receive. > > > Document: EAP Tunneled TLS Authentication Protocol Version 0 > Reviewer: Joel M. Halpern > Review Date: 21-March-2008 > IETF LC End Date: 2-April-2008 > IESG Telechat date: N/A > > Summary: This document is ready for publication as an Informational RFC. > If a revision is to be done, it would make sense to consider the first > two comments below, and see if the minor comments can be usefully > addressed. > > Comments: > There are two sets of AVPs defined by this document. One set goes > in the EAP-TTLS Start packet from the server to the client. The other > set are used in the inner TLS protected exchange. The first set are > referenced in section 9.2. But as far as I can tell, there is no > description of what valid AVPs may appear here. Even if they are the > same AVPs as go inside, some text explaining this in section 9.2 would > be helpful. > Section 7.2 talks about the application utilizing EAP-TTLS > specifying the information to be exchanged. It is not clear to me what > is meant by "application" here. Does this mean the different > authentication mechanisms that the client can select? Or something > else? (If something else, how is it known.) A bit of explanatory text > would probably help. > > Minor: > The text in section 7.8 talks about the different versions of TLS > that can be used. It would be useful (assuming I have correctly > understood the protocol) if the text noted that these versions are > negotiated by TLS, as part of carrying TLS over TTLS. > Section 11.3 on multiple authentication methods could use a couple > of extra words at the front. Something like "When the client has > selected EAP for authentication, the AAA/H server may request multiple > forms of Authentication." Otherwise, the reader tries to tie this to > the entirety of 11.2 (client specified authentication) and may get very > confused before finding at the end of the section the note that this > only applies to EAP. (Leave the note. Just add text at the beginning.) > > > I presume I will find out how the communicating parties agree on what > "application" is utilizing EAP-TTLS some time after section 7.2? > > > > > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
