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

From: "Hao Zhou (hzhou)" <[email-masked]>
Date: Thu, 4 Oct 2012 17:39:07 +0000

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.

2.  Section 3.3 s/descried/described/
[HZ] Ok.

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.

4. In section 3.6.1 - It is not clear that an EAP-Failure packet is sent
when 1) the server sends a fatal alert to the peer, 2) the peer requests a
restart via a ClientHello and 3) the peer declines to permit the restart
to
occur.
[HZ] We will clarify that EAP-Failure packet will be sent in those cases.

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.

6.  In section 3.6.2 - Why SHOULD not MUST send clear text EAP-Failure?
[HZ] We will change it to MUST.

7.  In section 3.6 - do we need to discuss the question of errors in the
outer EAP layer that is carrying the TLVs which contain the TLS content?
This is a distinct location from the current list of where to handle
errors.
There is going to be a distinction (possibly) between errors that occur
during phase 1 and errors during phase 2.  Should the error return reflect
if the error occurred inside or outside of the TLS tunnel?
[HZ] Good catch. We will add some language to clarify dealing with outer
packet errors. Something like:
1. If Outer TLVs are wrong, they will be ignored.
2. If others (version, length, flags, etc.) are wrong, the entire EAP
packet will be ignored.

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

b) If a peer issues a PAC request, but the server has not yet satisfied
it's
policy, does the server remember the PAC request and send back the
response
after the internal policy has been satisfied or should it send back an
error
saying that policy has not yet been satisfied along with additional TLVs
to
attempt and satisfy that policy?
[HZ] The server remembers that and issues the PAC after its policy is
satisfied. We will clarify that.

c) What should a peer do if it receives a PAC TLV with an unknown
attribute?
[HZ] Ignore that.

9.  In section 3.9 - there is leaking on the POP, but not on identity at
this point.  I believe that there needs to be a requirement that an EAP
method needs to be run which will provide an identity proof on the client
prior to a certificate being issued.  You may or may not then want to add
text that says that the subject name(s) in the certificate request need to
be checked against the set of authenticated identities prior to the
certificate being issued.
[HZ] Good point. We will add some that.

10. In section 3.10 - It is unclear to me if the Server Unauthenticated
mode
is because the server or the peer is unauthenticated at this point in
time.
The cipher suite would indicate that the server is not authenticated,
however what about the case of the server providing an authenticated id to
the peer, but the peer is unable to validate the identity of the server
for
some reason.  This is also a Server Unauthenticated mode.
[HZ] Yes. It covers both cases. We will add language to clarify that.

11.  In section 4.1 - I would like to see a discussion that says that the
following situation can never occur.  The initial EAP message from the
peer
to the server (or the response) plus the Outer TLV data plus the EAP
message
headers exceeds the underlying packet size of the transport.  In the event
that it does, I am not sure how one finds the Outer TLV data start and
where
the fragmentation would occur to get the Outer TLV data between the peer
and
the server.
[HZ] I think it should work as defined. The start of the Outer TLVs should
be derived from the EAP message length and length of the TLS data.

12.  Section 4.2 - I understand what is happening with an EMPTY TEAP
message
being sent in response to a list of TLVs that are marked optional,
however I
question if the statement that is MUST be sent is correct.  There are two
reasons for the question:

a.  A server could send a RESULT TLV in response to a message from the
client that contains no TLVs that are either mandatory or recognized.
[HZ] Good catch. We will clarify that.

b.  I am (very slightly) worried about the fact that the response is not
authenticated by the tunnel in many manner.  I would think that a NAK to
any
of the TLVs would be a better response if no other TLV messages are to be
sent.  The entity sending the TLV should know if it marked it as mandatory
or not.  The NAK is not the same as an Error TLV.
[HZ] Agree. A NAK  TLV should be sent in this case. We will clarify.

13.  Section 4.2.2 - Should "Type" in the outdented list be "TLV Type"?
s/filed/field/
[HZ] Yes. We will correct that.

14.  Section 4.2.2 - Can multiple Authority-ID TLVs be transmitted to a
peer?
[HZ] No. It is mentioned in Section 4.3, Table of TLVs rules.

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.

16.  Section 4.2.4 - I don't understand the default in the event that an
unknown value is sent in the status field.  If there is an ERROR TLV in
the
message, should I not use that error code rather than change it?
[HZ] No. The error code in the Error TLV if being sent with the Result TLV might mean something, but since the peer doesn't understand the Status field, and most likely will not understand the error code. Sending back Unexpected_TLVs_Exchanged error code is probably appropriate.

17. Section 4.2.6 - Do we need a discussion about how to produce/deal with
vender specific errors?  Do you expect that vender specific TLVs will have
an error mechanism built into them to return an error code?
[HZ] We expect the vendor TLV will have its own error handling mechanism or use the standard error codes defined.

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.

19.  Section 4.2.9 - After reading this, sketching out some scenarios and
so
forth, I find that I do not like the text and result being pushed here at
all.  My problems start, in some respects, with the name of the TLV as it
does not map to how I would like to see this TLV treated.  I would propose
the following set of changes:
a) The name of the TLV be changed from Request-Action TLV to
Provisional-Result TLV
[HZ] I am open with the name change, but think Request-Action probably capture the essence better.

b) It needs to be made clear that the TLV can be sent from either the
server
to the peer or the peer to the server.  It is my belief that presently it
is
only sent from the peer to the client and only in response to a successful
Result TLV.
[HZ] Ok. I agree that we can extend that to be bidirectional and for either success and failure Result TLV.

c)  The receiving entity MUST process the TLV.
[HZ] Ok.

d)  The processing for the TLV is as follows:
   i) The entity MAY choose to process (or start?) any of the TLVs that
are
included in the message.
  ii) If the entity chooses NOT to process any TLV in the list, the
Provisional-Result TLV is treated as a Result TLV with the code "status"
  iii) If multiple Provisional-Result TLVs are in the body, the session
can
continue if ANY of TLV in any Provisional-Result TLV is processed.
  iv) If multiple Provisional-Result TLVs are in the body and no sub-TLV
is
processed, then the most fatal status should be used.  If a status is
found
which is not understood by the entity, then it should be treated as a
fatal
TLV.
[HZ] Ok.

The current text allows for the following:
The server sends a Success to the peer
The peer says please do this or go to fatal
The server sends a clear success outside of the tunnel.
[HZ] That's not correct. The last exchange in the tunnel should be an agreed upon Result TLV exchange, before the tunnel is torn down and a clear text EAP success is sent.

I wonder if the capability needs to be added to say, please start this
TLV.
So that a server can say, If you don't start a Channel binding TLV, I will
make this a failure return code, if you want to start the channel binding
TLV then I am open to giving you a success return code.
OK - so this is kind of there, but only one value can be placed there.
One cannot say do either an EAP negotiation or process this TLV.
[HZ] That's true. Only one request.

20. Section 4.2.12.4 - What does it mean to have an I-ID validation
enforcement for PAC session renewal?  Does it mean that the final message
is
not sent unless an appropriate ID is presented?  Does it have to be an EAP
authentication or is password based authentication sufficient?  Should a
PAC
be invalidated on the server side (oops how do you do that) if it a PAC is
presented and then the appropriate ID is not given?
[HZ] The I-ID in the PAC is used to validate that the correct user is being authenticated and using his PAC. If they don't match, then the authentication will be rejected as if the authentication failed, with the normal flow including the final Result TLV and clear text EAP failure being sent. It can be either the EAP authentication or the password based authentication. The PAC is not invalidated if the I-ID doesn't match the authenticated identity, the authentication will be rejected.

21.  In section 4.2.12.6 - Is this supposed to be at the top level or
embedded in the PAC-TLV?
[HZ] Yes.

22.  In section 4.2.16 - PKCS#7 has been superseded by CMS - the
references
should be to CMS and not to PCKS#7
[HZ] Ok with me. Any other feedback from the WG?

23.  In IANA - Need to add the Request-Action TLV to the list of status
codes
[HZ] It is included in the Result TLV, Intermediate Result TOV status code registry in the IANA section. I think it makes sense to have the same one.

24.  In IANA - Should the Vender ID of the Vender-Specific TLV be kept in
a
registry?
[HZ] Vendor ID per the draft, is the SMI Network Management Private Enterprise Code already managed by IANA.

Jim

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of
Alan DeKok
Sent: Tuesday, September 25, 2012 8:04 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [Emu] Looking for reviewers
   We'd like to get the final two documents into last call before the
next
meeting.  Therefore, we're looking for reviewers:
https://datatracker.ietf.org/doc/draft-ietf-emu-crypto-bind/
https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tunnel-method/
   Please post reviews to the list.  If all goes well, we can get updated
documents issued before the next meeting.
   Thanks to everyone for their help.
   Alan DeKok.
_______________________________________________
Emu mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/emu

_______________________________________________
Emu mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/emu

---

From: "Jim Schaad" <[email-masked]>
Date: Sun, 7 Oct 2012 21:53:03 -0700

Hao, comments in line

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:

Or

allowed.

[HZ] Ok.

methods.

for

as server-id values?

to

occur.

[JLS] Just to be clear – this is a single case not three cases.  It is a
sequence of events that should lead to the EAP-Failure packet.

is

transmission or receipt of a fatal alert message, both parties immediately
close the connection.", so restart is not desired

alert cases.

[JLS]  It may just be me, but this seems to be a bit odd from my point of
view.  It is not clear that in the event of a non-fatal alert that there is
any need for the two parties to start a new negotiation that would ensue
upon getting a Hello restart.  There is a question in terms of closing the
connection if the TLS document means just the TLS session or the
encapsulating transport is to be shut down as well.  If it means the latter
then it makes sense that you could request a new TLS negotiation without
having to build all of the EAP transport frame work (i.e the entire RADIUS
session?).

Please re-look at this and ensure that this is really what you mean.

errors.

packet will be ignored.

[JLS} Looks reasonable.

determined that..."?

[JLS] That does deal with the immediate issue.  However the fact that you
need to do the Crypt-Binding TLV for tunnel validation does imply that an
EAP method that generates a key is a requirement before being able to get a
PAC.  Is this what is intended?  Should you be able to get a PAC just from
validating the tunnel with the server and knowing the servers name from it’s
certificate?

it's

response

error

to

attribute?

[HZ] Ignore that.

[JLS] Please be detailed – ignore the attribute or ignore the PAC.

 

mode

time.

for

 

peer

message

where

and

the server.

[JLS] I have gotten a better understanding – I may have suggested text
elsewhere

message

however I

any

s/filed/field/

peer?

[JLS} That says that you cannot send multiple Authority IDs in a single
message, what about in multiple messages?

the

treat

have

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

the

[HZ] No. The error code in the Error TLV if being sent with the Result TLV
might mean something, but since the peer doesn't understand the Status
field, and most likely will not understand the error code. Sending back
Unexpected_TLVs_Exchanged error code is probably appropriate.

[JLS] I was assuming that the client did understand the error code,
otherwise I agree that using a well understood error is correct behavior.

[HZ] We expect the vendor TLV will have its own error handling mechanism or
use the standard error codes defined.

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

so

Provisional-Result TLV

[HZ] I am open with the name change, but think Request-Action probably
capture the essence better.

server

is

Result TLV.

[HZ] Ok. I agree that we can extend that to be bidirectional and for either
success and failure Result TLV.

[HZ] Ok.

are

included in the message.

can

is

found

fatal

TLV.

[HZ] Ok.

[HZ] That's not correct. The last exchange in the tunnel should be an agreed
upon Result TLV exchange, before the tunnel is torn down and a clear text
EAP success is sent.

[JLS] Just to be clear, you are saying that the conversation will look like

Server à Result TLV (Success)

                  Request-Action (Status-Bletch, foobar) ß Client

Server à Result TLV (Success)

               Result TVL (Success) ß Client (knows that the server must not
be willing to do what was asked.

The server COULD send back the Bletch code if it decides to process the
Request-Action TLV from the client.  The client could send back Bletch even
if the server does not send it the second time.

TLV.

[JLS] Since you can only have one Request-Action TLV for a given status
code, but presumably multiple Request-Action TLV with different status
codes,  that seems slightly restrictive.    However, I can deal with this.  

[JLS] Difference in opinion in the document.  The text in 4.2.9 says that
multiple with different status codes ok, but the table says  0-1 in a single
message

is

PAC

[HZ] The I-ID in the PAC is used to validate that the correct user is being
authenticated and using his PAC. If they don't match, then the
authentication will be rejected as if the authentication failed, with the
normal flow including the final Result TLV and clear text EAP failure being
sent. It can be either the EAP authentication or the password based
authentication. The PAC is not invalidated if the I-ID doesn't match the
authenticated identity, the authentication will be rejected.

embedded in the PAC-TLV?

[HZ] Yes.

[JLS] I think the correct response is – “I don’t understand the question”
It is only embedded and I don’t know why I ever thought  it would be at the
top level.

references

codes

[HZ] It is included in the Result TLV, Intermediate Result TOV status code
registry in the IANA section. I think it makes sense to have the same one.

[JLS] – my bad, I missed that it was in the list.

a

registry?

[HZ] Vendor ID per the draft, is the SMI Network Management Private
Enterprise Code already managed by IANA. 

Yes – I just missed that the first time around – sorry

Jim

-----Original Message-----

From: [email-masked] [mailto:[email-masked]] On Behalf Of

Alan DeKok

To: [email-masked]

next

   Alan DeKok.

Emu mailing list

[email-masked]

Emu mailing list

[email-masked]

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 10 Oct 2012 11:42:25 -0700

I think that picks up all of my current comments.  Looking forward to seeing
the draft update.

Jim

From: Hao Zhou (hzhou) [mailto:[email-masked]] 
Sent: Wednesday, October 10, 2012 11:15 AM
To: Jim Schaad
Cc: [email-masked]
Subject: Re: [Emu] Review of draft-ietf-emu-eap-tunnel-method-00

Jim:

Please see comments below inline.

---

From: "Hao Zhou (hzhou)" <[email-masked]>
Date: Wed, 10 Oct 2012 18:15:21 +0000

Jim:

From: Jim Schaad <[email-masked]<mailto:[email-masked]>>
Date: Monday, October 8, 2012 12:53 AM
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

Hao, comments in line

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:

[JLS] Just to be clear – this is a single case not three cases.  It is a sequence of events that should lead to the EAP-Failure packet.
[HZ] ok.

[JLS]  It may just be me, but this seems to be a bit odd from my point of view.  It is not clear that in the event of a non-fatal alert that there is any need for the two parties to start a new negotiation that would ensue upon getting a Hello restart.  There is a question in terms of closing the connection if the TLS document means just the TLS session or the encapsulating transport is to be shut down as well.  If it means the latter then it makes sense that you could request a new TLS negotiation without having to build all of the EAP transport frame work (i.e the entire RADIUS session?).

Please re-look at this and ensure that this is really what you mean.
[HZ] Good point. I think the draft text is written in the way to allow restart for all alerts. I think the text is modeled after the EAP-TLS RFC 5216 and is fine.

[JLS} Looks reasonable.

[JLS] That does deal with the immediate issue.  However the fact that you need to do the Crypt-Binding TLV for tunnel validation does imply that an EAP method that generates a key is a requirement before being able to get a PAC.  Is this what is intended?  Should you be able to get a PAC just from validating the tunnel with the server and knowing the servers name from it’s certificate?
[HZ] If there is an inner EAP method, then it makes sense to validating the crypto binding to ensure the tunnel integrity and the inner EAP method. Otherwise, requesting PAC after validating the server is fine. Will add text to clarify.

c) What should a peer do if it receives a PAC TLV with an unknown
attribute?
[HZ] Ignore that.
[JLS] Please be detailed – ignore the attribute or ignore the PAC.
[HZ] Ignore the attribute.

[JLS] I have gotten a better understanding – I may have suggested text elsewhere

14.  Section 4.2.2 - Can multiple Authority-ID TLVs be transmitted to a
peer?
[HZ] No. It is mentioned in Section 4.3, Table of TLVs rules.
[JLS} That says that you cannot send multiple Authority IDs in a single message, what about in multiple messages?
[HZ] Authority ID is only to be sent in the first server to peer TEAP message, so shouldn't be multiple messages. Will clarify in the Outer TLV rule section to be added.

16.  Section 4.2.4 - I don't understand the default in the event that an
unknown value is sent in the status field.  If there is an ERROR TLV in
the
message, should I not use that error code rather than change it?
[HZ] No. The error code in the Error TLV if being sent with the Result TLV might mean something, but since the peer doesn't understand the Status field, and most likely will not understand the error code. Sending back Unexpected_TLVs_Exchanged error code is probably appropriate.
[JLS] I was assuming that the client did understand the error code, otherwise I agree that using a well understood error is correct behavior.
[HZ] Still, peer encounters an unknown or unexpected TLV, which is a different error than what the other side wants to convey on the error tlv.

Server --> Result TLV (Success)
                  Request-Action (Status-Bletch, foobar) <-- Client
Server --> Result TLV (Success)
               Result TVL (Success) <-- Client (knows that the server must not be willing to do what was asked.

The server COULD send back the Bletch code if it decides to process the Request-Action TLV from the client.  The client could send back Bletch even if the server does not send it the second time.
[HZ] Not quite. Status-Bletch indicates the result if the server does not process the action requested by the peer. So if the server does not process the request, then it will look like this:
Server --> Result TLV (Success)
                  Request-Action (Status-Bletch, foobar) <-- Client
Server --> Result TLV (Status-Bletch)
               Result TVL (Status-Bletch)

If the server processes the request and succeeds, it will look like this:
Server --> Result TLV (Success)
                  Request-Action (Status-Bletch, foobar) <-- Client
.. Process TLVs or start another EAP
Server --> Result TLV (Success)
               Result TVL (Success) <-- Client

[JLS] Since you can only have one Request-Action TLV for a given status code, but presumably multiple Request-Action TLV with different status codes,  that seems slightly restrictive.    However, I can deal with this.

[JLS] Difference in opinion in the document.  The text in 4.2.9 says that multiple with different status codes ok, but the table says  0-1 in a single message

[HZ] Good catch, will fix.

21.  In section 4.2.12.6 - Is this supposed to be at the top level or
embedded in the PAC-TLV?
[HZ] Yes.
[JLS] I think the correct response is – “I don’t understand the question”  It is only embedded and I don’t know why I ever thought  it would be at the top level.
[HZ] Yes, it is embedded in PAC-TLV. I meant that it should be at the top level, meaning first TLV.

Jim