Re: [Gen-art] IETF LC review: draft-funk-eap-ttls-v0-04.txt

Hi Joel,

Thank you for your timely and considered review.  Paul's responses below.

regards,
Lakshminath

 > > -----Original Message-----
 > > From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com]
 > > Sent: Tuesday, March 25, 2008 7:06 PM
 > > To: PaulFunk@alum.mit.edu
 > > 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 <jmh@joelhalpern.com>
 > > To: Mary Barnes <mary.barnes@nortel.com>
 > > CC: gen-art@ietf.org, Lakshminath Dondeti <ldondeti@qualcomm.com>,
 > >    Jari Arkko <jari.arkko@piuha.net>
 > > References:
 > > <F66D7286825402429571678A16C2F5EE02834C94@zrc2hxm1.corp.nortel.com>
 > >
 > > 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
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art