Subject: [Gen-art] A *new* batch of IETF LC reviews - 20 Mar 2007

From: "Mary Barnes" <[email-masked]>
Date: Thu, 20 Mar 2008 23:07:33 -0500

Hi all,

Here's the link to the new LC assignments for this week:
http://www.alvestrand.no/ietf/gen/art/reviewers-080320-lc.html

The assignments are captured in the spreadsheets: 
http://www.alvestrand.no/ietf/gen/art/gen-art.html 
http://www.alvestrand.no/ietf/gen/art/gen-art-by-reviewer.html 

The standard template is included below.

Thanks, 
Mary. 

-------------------------------------------------------------------

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: 
Reviewer: 
Review Date:  
IETF LC End Date: 
IESG Telechat date: (if known)

Summary:

Comments:

_______________________________________________
Gen-art mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/gen-art

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 21 Mar 2008 19:26:51 -0400

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?

---

From: Lakshminath Dondeti <[email-masked]>
Date: Tue, 25 Mar 2008 21:58:45 -0700

Hi Joel,

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

regards,
Lakshminath

 > > -----Original Message-----
 > > From: Lakshminath Dondeti [mailto:[email-masked]]
 > > Sent: Tuesday, March 25, 2008 7:06 PM
 > > To: [email-masked]
 > > 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-masked]>
 > > To: Mary Barnes <[email-masked]>
 > > CC: [email-masked], Lakshminath Dondeti <[email-masked]>,
 > >    Jari Arkko <[email-masked]>
 > > References:
 > > <[email-masked]>
 > >

[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.

 > > something else, how is it known.)  A bit of explanatory text would

[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.

 > > negotiated by TLS, as part of carrying TLS over TTLS.

[pf] It already does, in the immediately preceding section 7.7.

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

 > > "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:
>     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 
>     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:

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 26 Mar 2008 01:34:43 -0400

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:
> 1    To ensure that receivers understand that there might be data 
> following the Start
> specifying
>> 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:
>> specifying the information to be exchanged.  It is not clear to me 
>> what is meant by "application" here.  Does this mean the different 
>> else?  (If something else, how is it known.)  A bit of explanatory 
>> text would probably help.
>>
>> Minor:
>> 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.)
>>
>>