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

From: "Jim Schaad" <[email-masked]>
Date: Wed, 14 Nov 2012 19:25:41 -0800

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

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.

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.

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.

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.  

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.