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

["Joel M. Halpern" <[e-mail]>]

Thanks.  That takes care of most of them.  (Including my leaving in a 
redundant comment that was a note to myself during the review.  Sorry 
about that.)

On the AVPs, what I was trying to point out was that the text as written 
was unclear as to whether the same AVPs were used in the clear text as 
in the TLS exchange, or a different set of AVPs (that were not defined.) 
    All it would take is one sentence saying that the clear text AVPs 
use the same attribute identifiers (same attributes?, take your pick on 
the wording) as the AVPs carried in TLS.

My concern on 11.3 and using multiple authentications is that the first 
paragraph says that in general it may be desirable to perform multiple 
authentications.  So when the second paragraph says that this may be 
done when using EAP, the reader is not being told, "and only when using 
EAP".  My suggestion would be to simply add a sentence at the end of the 
first paragraph that reads "Multiple authentication is only supported by 
this protocol in conjunction with EAP."

Yours,
Joel

Lakshminath Dondeti wrote:
> Hi Joel,
> 
> Thank you for your timely and considered review.  Paul's responses below.
> 
> regards,
> Lakshminath
> 
>  > > -----Original Message-----
>  > > From: Lakshminath Dondeti [mailto:[e-mail]]
>  > > Sent: Tuesday, March 25, 2008 7:06 PM
>  > > To: [e-mail]
>  > > 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 <[e-mail]>
>  > > To: Mary Barnes <[e-mail]>
>  > > CC: [e-mail], Lakshminath Dondeti <[e-mail]>,
>  > >    Jari Arkko <[e-mail]>
>  > > References:
>  > > <[e-mail]>
>  > >
>  > > 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
[e-mail]
https://www.ietf.org/mailman/listinfo/gen-art