Subject: [Emu] Comments on the eap-tunnel-method-00 draft

From: "Jim Schaad" <[email-masked]>
Date: Mon, 17 Oct 2011 15:08:00 -0700

I have gathered these comments over time and therefore some of them are not
fully fleshed out.  If you have any questions I will try and reconstruct my
ideas at the time.

Jim

Version Negotiation - terminate the conversation - w or w/o a fail?
	Edge case - what if peer only supports a higher version than the
server supports?  NAK?

EAP Server Name Checking - On what basis does the client accept or not
accept the EAP server name?    You are suggesting that it is signed by a CA
controlling the intended domain, but what does this mean?   Are you
suggesting that the CA should have a DNS subject alt name in it for the
domain in question?

If no embedded EAP methods run, then no crypto check and thus no version #
checking is done.  Also no checking done if only one inner EAP method is
used as this only sends the Result TLV and not the Crypto-Binding TLV

'serially in a sequence' is redundant - section 3.3.1

Not only does it not allow initiating multiple EAP methods in parallel, it
requires that they not be running in parallel.  This is a more strict
condition

Para #3 - can the peer return an error and treat the failure of a specific
EAP method as a total failure for the overall process - or at least
recommend that it should be an overall failure?

Confused messages in 3.3.1 and 3.3.3 about sending intermediate results and
final results at the same time.  Specifically 3.3.1 says MUST NOT for one
inner EAP method,  but text is not reflected in section 3.3.3

Conflict between 3.3.3 and security considerations (7.5) about sending a
different value in the Result TLV and the clear result in the event of not
doing a Request-Action TLV from the client.  Is the server required to use
the client suggested result in the event it does not perform the request
action - could it use a different failure message or a success message?
Does it matter?

Section 3.4 - Need to address the following issues:
1.  what if both certificates and an inner EAP method are run - what is the
Peer-Id then?
2.  What if multiple inner EAP methods are run - which Peer-Id is used then?
3.  What if client and machine EAP methods are run - which one to use then?
(Internal what are the ids used for?)

Section 3.6 - item #2 - it should be noted that not all failure indications
would be transmitted.  The failure/success of the last EAP method may not be
sent as it gets wrapped into the Result TLV message

Section 3.6.2 - (internal) - if you get a TLV rules violation - does the TLV
itself need to be acknowledged?

Section 3.7 - Can I assume that the identifier value is monotonically
increasing and does not wrap?

Section 3.7 - it might be useful to tell me how to error for a message too
big or response time too long in dealing with fragmentation - are both just
final errors? Or should it potentially be treated as a TLS error?

Section 3.2 - possible clarification.  If all TLVs in a message are marked
optional and none are understood by the peer, then an EMPTY response message
must still be sent to the server.  

Section 4.2.2 - Result TLV MUST NOT be accompanied by Crypto-binding TLV -
not what it says in section 3.3

Section 4.2.3 - NAK TLV should not be accompanied by other TLVs.   Not sure
I understand why.  If I send an EAP plus a vendor w/ mandatory set, should
not I get back a NAK on the vendor plus a result for the EAP?
I might be happy to not do the vendor, but want to distinguish between you
cannot do this vs you choose not to do this.  <Not fully sure that I really
care about this case as long I can assume that if the mandatory bit is set
then I would always fail the overall EAP conversation.>

Section 4.2.10 - How can I know if the server does or does not process the
channel binding TLV?  This may be part of my policy as a peer depending on
circumstances.

Section 4.2.8 -  Currently says that version should be 1 while the version
defined in the intro sections is 2 - would be correct if we change the EAP
method.

---

From: Hao Zhou <[email-masked]>
Date: Wed, 19 Oct 2011 15:31:28 -0400

Jim:

Thanks for reviewing the draft in detail and comments provided. Please see
my response inline below.

> Edge case - what if peer only supports a higher version than the
[HZ] It depends. Server might want to proceed with other EAP type
negotiation by proposing a different EAP type, or terminate the conversation
with an EAP-Failure. I will clarify that in the next rev.

> suggesting that the CA should have a DNS subject alt name in it for the
[HZ] It's up to client's policy, especially if the server cert is issued by
a public CA. Client needs not only verify that the server cert presented is
a valid cert signed by the trusted CA, but also the server name presented in
the cert is matching the domain it tried to authenticate with. A FQDN in the
CN or SAN would be a way to do it.
 
> checking is done.
[HZ] That's true.

>Also no checking done if only one inner EAP method is
[HZ] That's not true. Crypto-binding would still be exchanged with Result
TLV. Actually using of the Result TLV in lieu of IM-Result TLV is for legacy
reason in EAP-FAST, which could be removed in next rev since we are
designing a new EAP method.
> 'serially in a sequence' is redundant - section 3.3.1
[HZ] Ok. The text is trying to distinguish from running multiple EAP methods
in parallel.

> requires that they not be running in parallel.  This is a more strict
[HZ] For simplicity, otherwise implementation would need to trace when the
1st method finishes and applies the key from the authentication to the
crypto-binding. Supporting them in complete sequence makes it simpler and
securer, as 2nd method might not be safe to run if the crypto-binging after
1st method fails.

> recommend that it should be an overall failure?
[HZ] Yes it can. It is actually described in Section 3.6.2, peer can send up
some Fatal Error TLV and Result TLV to indicate the end.

> inner EAP method,  but text is not reflected in section 3.3.3
[HZ] I think we can change to always send IM result after each inner EAP
method, if only one inner method, then Result TLV could be sent as well. See
explanation above.
> action - could it use a different failure message or a success message?
[HZ] Server is supposed to send the suggested Result code in Request-Action
TLV if it refuse to do the action, this way peer will get notify about the
final result and in-sync with the clear text EAP-Success/Failure packet.
Probably doesn't matter what the server sends, client would set the final
result base on its policy.

> 1.  what if both certificates and an inner EAP method are run - what is the
[HZ] Good question. There were some discussions on this. The new draft rev
will propose to use the first authenticated peer identity. The WG can
discuss more on this.
> 2.  What if multiple inner EAP methods are run - which Peer-Id is used then?
[HZ] Same as above.
> (Internal what are the ids used for?)
[HZ] Again, good question. Same as above.
> sent as it gets wrapped into the Result TLV message
[HZ] Should be fixed with the change on IM result TLV.
> itself need to be acknowledged?
[HZ] Probably no need to, as it is fatal and other side probably already
terminated the tunnel.

> increasing and does not wrap?
[HZ] Yes. We shouldn't exceed the maximum number (256) for Identifier in a
single EAP authentication, at least I hope not.

> final errors? Or should it potentially be treated as a TLS error?
[HZ] Most likely it will be TLS error if one side is having trouble to
receive or assemble the whole message. Additional error code could be
defined to convey this.
 
> must still be sent to the server.
[HZ] yes. I will add that.

> not what it says in section 3.3
[HZ] It says " A Result TLV indicating failure", as it doesn't matter
anymore, the whole EAP authentication will fail. Section 3.3 is talking
about a successful Result TLV.

> then I would always fail the overall EAP conversation.>
[HZ] Correct, I am not sure there is value sending back the other TLVs, as
the authentication should be failed if the mandatory to implement is not
supported.

> channel binding TLV?  This may be part of my policy as a peer depending on
[HZ] Currently, the Channel-binding TLV is an optional TLV, doesn't require
acknowledgement, and is designed to be only one way, for client to send some
channel binding data to the server for verification purpose. There is no
feedback provided. The indication of whether the server supports
channel-binding and/or validated the channel-binding could be conveyed in
other TLVs to be added, if the WG agrees to be valuable.
 
> defined in the intro sections is 2 - would be correct if we change the EAP
[HZ] It's the version number of the Crypto-binding TLV, not the EAP version
number. The theory is that we could enhance the crypto-binging TLV format in
the future if desired.
> 
> 
> 
> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 19 Oct 2011 12:55:28 -0700 (PDT)

Hi Hao,

  About 6 weeks ago I sent in some detailed comments, notably
the request for a new TLV to pass a PKCS#10 to the server to go
along with the existing TLV that sends a PKCS#7 to the peer, and
for a server unauthenticated provisioning mode, and never heard
from the editors of the tunnel method draft.

  Do you have any response to those comments?

  regards,

  Dan.

---

From: Hao Zhou <[email-masked]>
Date: Wed, 19 Oct 2011 16:00:15 -0400

Dan:

Thanks for the review comments. Sorry for not responding right away. The
current plan is that we will publish a new revision today with the name
change and etc, and Joe will start an issue list including the comments you
made, as it will require some WG discussion, and then we will make another
revision once we have consensus on them.

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 19 Oct 2011 16:54:59 -0700

> -----Original Message-----
> From: Hao Zhou [mailto:[email-masked]]
> Sent: Wednesday, October 19, 2011 12:31 PM
> To: Jim Schaad; [email-masked]
> Cc: [email-masked]
> Subject: Re: [Emu] Comments on the eap-tunnel-method-00 draft
> 
> Jim:
> 
> > I have gathered these comments over time and therefore some of them
> > are not fully fleshed out.  If you have any questions I will try and
> > reconstruct my ideas at the time.
> >
> > Jim
> >
> >
> >

Yes - but in this case I would expect a NAK from the client - possibly
proposing other methods.  Is this correct?

> > suggesting that the CA should have a DNS subject alt name in it for
> > the domain in question?
> >
> [HZ] It's up to client's policy, especially if the server cert is issued
by a public
> CA. Client needs not only verify that the server cert presented is a valid
cert
> signed by the trusted CA, but also the server name presented in the cert
is
> matching the domain it tried to authenticate with. A FQDN in the CN or SAN
> would be a way to do it.
> 
> > If no embedded EAP methods run, then no crypto check and thus no
> > version # checking is done.
> [HZ] That's true.

Ok - this would be in violation of the last paragraph in section 3.1 which
says that the version numbers MUST be done.

> 
> >Also no checking done if only one inner EAP method is  used as this
> >only sends the Result TLV and not the Crypto-Binding TLV
> >
TLV.
> Actually using of the Result TLV in lieu of IM-Result TLV is for legacy
reason in
> EAP-FAST, which could be removed in next rev since we are designing a new
> EAP method.

Please tell me where it says this is done.  All I can see is that one CAN
send intermediate-result, result and crypto-binding TLVs in the same
message.  (Unless of course only one is sent in which case the
Intermediate-Reuslt TLV MUST NOT be sent).   However these is nothing that
says that the Crypto-binding TLV would be sent after the first and only EAP
method - or indeed after a sequence of EAP methods.

> > Not only does it not allow initiating multiple EAP methods in
> > parallel, it requires that they not be running in parallel.  This is a
> > more strict condition
> >

Do you ever expect a version to allow multiple EAP sequences to be run at
the same time?  If not then just the statement that they MUST be executed
serially is probably sufficient.

> 
> > Para #3 - can the peer return an error and treat the failure of a
> > specific EAP method as a total failure for the overall process - or at
> > least recommend that it should be an overall failure?
> >
> [HZ] Yes it can. It is actually described in Section 3.6.2, peer can send
up some
> Fatal Error TLV and Result TLV to indicate the end.

Ok - either I don't see the text or my comment is not sufficiently clear.

Consider:
Client is running EAP-BLAH and returns inside of the EAP-BLAH method a
failure. 
If the client wants an overall failure rather than leaving it up to the
server, does it send both the Result TLV failure and the EAP-Message w/ the
failure - or just the result TLV failure or is this not reasonable for the
client?

> 
> > Confused messages in 3.3.1 and 3.3.3 about sending intermediate
> > results and final results at the same time.  Specifically 3.3.1 says
> > MUST NOT for one inner EAP method,  but text is not reflected in
> > section 3.3.3
> >

> > Conflict between 3.3.3 and security considerations (7.5) about sending
> > a different value in the Result TLV and the clear result in the event
> > of not doing a Request-Action TLV from the client.  Is the server
> > required to use the client suggested result in the event it does not
> > perform the request action - could it use a different failure message or
a
> success message?
final
> result and in-sync with the clear text EAP-Success/Failure packet.

Based on my reading I would not have thought that the server was to send a
SECOND (and yes different) Result TLV in this case.

> > 1.  what if both certificates and an inner EAP method are run - what
> > is the Peer-Id then?
discuss
> more on this.

What are you referring to for same as above?

> > Section 3.6 - item #2 - it should be noted that not all failure
> > indications would be transmitted.  The failure/success of the last EAP
> > method may not be sent as it gets wrapped into the Result TLV message
> >

> > Section 3.6.2 - (internal) - if you get a TLV rules violation - does
> > the TLV itself need to be acknowledged?
> >

> 
> > Section 3.7 - it might be useful to tell me how to error for a message
> > too big or response time too long in dealing with fragmentation - are
> > both just final errors? Or should it potentially be treated as a TLS
error?
> [HZ] Most likely it will be TLS error if one side is having trouble to
receive or
> assemble the whole message. Additional error code could be defined to
> convey this.
> 

But this would be a limitation on the EAP method rather than on TLS.

> > Section 3.2 - possible clarification.  If all TLVs in a message are
> > marked optional and none are understood by the peer, then an EMPTY
> > response message must still be sent to the server.
> >

> 
> > Section 4.2.2 - Result TLV MUST NOT be accompanied by Crypto-binding
> > TLV - not what it says in section 3.3
> >
anymore,
> the whole EAP authentication will fail. Section 3.3 is talking about a
successful
> Result TLV.

> > I understand why.  If I send an EAP plus a vendor w/ mandatory set,
> > should not I get back a NAK on the vendor plus a result for the EAP?
> > I might be happy to not do the vendor, but want to distinguish between
> > you cannot do this vs you choose not to do this.  <Not fully sure that
> > I really care about this case as long I can assume that if the
> > mandatory bit is set then I would always fail the overall EAP
> > conversation.>
> >
the
> authentication should be failed if the mandatory to implement is not
> supported.

> 
> > Section 4.2.10 - How can I know if the server does or does not process
> > the channel binding TLV?  This may be part of my policy as a peer
> > depending on circumstances.
> >
> acknowledgement, and is designed to be only one way, for client to send
> some channel binding data to the server for verification purpose. There is
no
> feedback provided. The indication of whether the server supports channel-
> binding and/or validated the channel-binding could be conveyed in other
> TLVs to be added, if the WG agrees to be valuable.
> 

Sam - do you see this as being an issue for abfab?

> > Section 4.2.8 -  Currently says that version should be 1 while the
> > version defined in the intro sections is 2 - would be correct if we
> > change the EAP method.
> >
> number. The theory is that we could enhance the crypto-binging TLV format
> in the future if desired.

Ok - I just misread this.

Jim

---

From: Sam Hartman <[email-masked]>
Date: Wed, 19 Oct 2011 20:22:20 -0400

>>>>> "Jim" == Jim Schaad <[email-masked]> writes:
    >> > Section 4.2.10 - How can I know if the server does or does not
    >> process > the channel binding TLV?  This may be part of my policy
    >> as a peer > depending on circumstances.
    >> >
   >> [HZ] Currently, the Channel-binding TLV is an optional TLV,
   >> doesn't
 require
   >> acknowledgement, and is designed to be only one way, for client
   >> to send some channel binding data to the server for verification
   >> purpose. There is
> no
   >> channel- binding and/or validated the channel-binding could be
   >> conveyed in other TLVs to be added, if the WG agrees to be
   >> valuable.
   >> 

Jim>Sam - do you see this as being an issue for abfab?

It's an issue for EMU actually.
See  Section 5.3 of draft-ietf-emu-chbind.
Channel binding must be two-way and must follow the semantics of that
section.

And yes, draft-ietf-abfab-gss-eap depends on those semantics.

---

From: Hao Zhou <[email-masked]>
Date: Wed, 19 Oct 2011 23:15:14 -0400

Rereading the updated chbind draft, it has already defined the mechanism for
two way communication and tunnel EAP draft just defined a TLV container to
carry the Channel binding data defined in Section 5.3, so we should be ok.
No change is needed on the tunnel EAP draft on this, other maybe called out
Section 5.3.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 20 Oct 2011 08:48:59 -0400

>>>>> "Hao" == Hao Zhou <[email-masked]> writes:

    Hao> Rereading the updated chbind draft, it has already defined the
    Hao> mechanism for two way communication and tunnel EAP draft just
    Hao> defined a TLV container to carry the Channel binding data
    Hao> defined in Section 5.3, so we should be ok.  No change is
    Hao> needed on the tunnel EAP draft on this, other maybe called out
    Hao> Section 5.3.

And to indicate it's two-way.

---

From: "Hao Zhou (hzhou)" <[email-masked]>
Date: Thu, 20 Oct 2011 09:49:03 -0500

Jim:

Please see inline.

-----Original Message-----
From: Jim Schaad [mailto:[email-masked]]
Sent: Wed 10/19/2011 7:54 PM
To: Hao Zhou (hzhou); [email-masked]; Sam Hartman
Cc: [email-masked]
Subject: RE: [Emu] Comments on the eap-tunnel-method-00 draft

Yes - but in this case I would expect a NAK from the client - possibly
proposing other methods.  Is this correct?
[HZ] Yes, a NAK with other proposed EAP method if available. Will clarify in next rev.

by a public
cert
is

[HZ] Good point. Seems like we need to crypto-binding every time if we want to protect the version number, EAP type, and outer TLVs.  Will discuss and fix in next rev.

TLV.
reason in

[HZ] It is described in Section 4.2.8, 
"The Crypto-Binding TLV MUST be included with the Intermediate-Result
   TLV to perform Cryptographic Binding after each successful EAP method
   in a sequence of EAP methods.  The Crypto-Binding TLV can be issued
   at other times as well."

We will clarify to make it clear that it MUST be done after each successful EAP method even if it's only one in the sequence.

[HZ] Ok.
up some

Consider:
[HZ] I would send both the EAP message failure and Result TLV failure, this way the server would have the indication that not only the EAP method failed, but also peer wants to fail the whole EAP. More information client sends to the server is probably better.

a
final

[HZ] You are right. The current spec says server just send clear text EAP-Success and Failure if it ignores the Request-Action.
To answer your original question, it's better that server use the one suggested by the client, as the client's state machine would be in the state of expecting the same clear text EAP success or failure. I don't know how many implementations actually reject the clear text EAP success or failure if it doesn't match the protected result, but it's safer for them to be in sync. Of course, EAP-Failure probably doesn't matter as the physical link might be severed afterward. 

discuss

What are you referring to for same as above?
[HZ] Question 1 and 2 in this section. basically, they are the same question, multiple identities authenticated, what to use for Peer-ID.

error?
receive or

But this would be a limitation on the EAP method rather than on TLS.
[HZ] It's actually an implementation or device limitation. EAP is not designed to carry large bulk of data, so I hope we don't run into too large fragmentation issues.

anymore,
successful

the

no

Sam - do you see this as being an issue for abfab?
[HZ] I have addressed this in another email thread. Will clarify it's bidirectional as defined in ChBind draft section 5.3.

Jim