Subject: Re: [Emu] Review of draft-ietf-emu-eap-tunnel-method-00

From: "Hao Zhou (hzhou)" <[email-masked]>
Date: Mon, 28 Jan 2013 20:55:00 +0000

Jim:

Sorry for the late response. Will address all of them in the new draft. Individual comments inline below. Thanks.

From: Jim Schaad <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, November 14, 2012 10:25 PM
To: Cisco Employee <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Emu] Review of draft-ietf-emu-eap-tunnel-method-00

From: Hao Zhou (hzhou) [mailto:[email-masked]]
Sent: Thursday, October 04, 2012 10:39 AM
To: Jim Schaad
Cc: [email-masked]<mailto:[email-masked]>
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" <[email-masked]<mailto:[email-masked]>> 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.