Subject: [Emu] Barry Leiba's Discuss on draft-ietf-emu-eap-tunnel-method-07: (with DISCUSS and COMMENT)

From: "Barry Leiba" <[email-masked]>
Date: Mon, 12 Aug 2013 09:05:08 -0700

Barry Leiba has entered the following ballot position for
draft-ietf-emu-eap-tunnel-method-07: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-emu-eap-tunnel-method/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I'm going to raise Spencer's comment to a DISCUSS: I find the version
negotiation in Section 3.1 to be somewhat confusingly written.  Possibly
it will be implemented correctly because people generally know how to
code version negotiation -- but I don't think the text here makes it
clear.

First, you seem to be using "EAP peer" and "TEAP peer" interchangably. 
Please make sure you're consistent in your usage, and if there really is
a difference then make that clear and explain it.  You similarly say "EAP
server" and "TEAP server" -- again, are they the same, or different
enities?

Second, I'm confused by "server" and "peer".  Peers talk with peers; when
there's a server, there's a client.  What does it mean to have a server
and a peer (in the document in general, and in this negotiation in
particular)?

Now, I think you're trying to say this:
1. The server gives the highest version it supports.
2. The client does one of three things:
2a. Sends a response that echos the server's version.
2b. Sends a response that offers a lower version.
2c. Sends a Nak, and we're done here (perhaps we continue with something
else).
3. For 2b, the server does one of two things:
3a. Accepts the client's version and continues.
3b. [Does something else; see Spencer's comment.]

Now, I like this approach, in that both the client and server can refuse
an earlier version (which perhaps has security flaws), so that's nice. 
But I think the wording of the negotiation process ought to be fixed to
make it clearer, and that what happens in case 3b, especially, needs to
be clearer.

I also think that numbering the list(s) will help, though you don't have
to use my numbering (and if you can make it clear without numbers, that's
fine).

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I note that the shepherd writeup included key information about reviews
from outside the working group.  Thanks for that; it's very useful.

In Section 3.3.2, it might be useful to (briefly) note *why* one SHOULD
NOT use EAP-FAST-GTC.

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Mon, 12 Aug 2013 19:24:44 +0000

Hi Barry,

Comments inline below/ 
On Aug 12, 2013, at 9:05 AM, Barry Leiba <[email-masked]>

> http://datatracker.ietf.org/doc/draft-ietf-emu-eap-tunnel-method/

[Joe]  TEAP and EAP are interchangeable in this case.  We'll clean up this section. 

> and a peer (in the document in general, and in this negotiation in

[Joe] EAP Peer refers to the client.  This is EAP specific terminology, I don't know why EAP uses peer instead of client, but I think its important for us to stay consistent with EAP terminology. 

> to use my numbering (and if you can make it clear without numbers, that's

[Joe] How about the following text?  

Version negotiation proceeds as follows:

1. In the first EAP-Request sent with EAP type=TEAP, the TEAP server MUST set the version field to the highest version it supports.

2a. If the TEAP peer supports the proposed version, it responds with an EAP-Response of EAP type=TEAP including the version number proposed by the TEAP server.

2b. If the TEAP peer does not support the proposed version but supports a lower version, it responds with an EAP-Response of EAP type=TEAP and sets the version field its highest supported version.

2c. If the TEAP peer only supports versions higher than the version proposed by the TEAP server, then use of TEAP will not be possible.  In this case, the TEAP peer sends back an EAP-Nak either to negotiate a different EAP type or to indicate no other EAP types are a available.

3a.  If the TEAP server does not support the version number proposed by the TEAP peer, it it MUST either terminate the conversation with an EAP-Failure or negotiate a new EAP type.  

3b.  If the TEAP server does support the version then the conversation continues using the version proposed by the TEAP peer.

[Joe]  Modified text: 

The use of EAP-FAST-GTC as defined in RFC 5421 [RFC5421] is NOT RECOMMENDED with TEAPv1 because EAP-FAST-GTC is not compliant with EAP-GTC defined in [RFC3748].

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

---

From: Barry Leiba <[email-masked]>
Date: Mon, 12 Aug 2013 22:01:20 +0200

> [Joe]  TEAP and EAP are interchangeable in this case.  We'll clean up this section.

Thanks.

> [Joe] EAP Peer refers to the client.  This is EAP specific terminology, I don't know
> why EAP uses peer instead of client, but I think its important for us to stay consistent
> with EAP terminology.

You're right; 'nuff said on this one, and thanks for the explanation.

> 1. In the first EAP-Request sent with EAP type=TEAP, the TEAP server
> MUST set the version field to the highest version it supports.
>
> 2a. If the TEAP peer supports the proposed version, it responds with an
> EAP-Response of EAP type=TEAP including the version number proposed
> by the TEAP server.
>
> 2b. If the TEAP peer does not support the proposed version but supports a
> lower version, it responds with an EAP-Response of EAP type=TEAP and
> sets the version field its highest supported version.
>
> 2c. If the TEAP peer only supports versions higher than the version proposed
> by the TEAP server, then use of TEAP will not be possible.  In this case, the
> TEAP peer sends back an EAP-Nak either to negotiate a different EAP type
> or to indicate no other EAP types are a available.
>
> 3a.  If the TEAP server does not support the version number proposed by the
> TEAP peer, it it MUST either terminate the conversation with an EAP-Failure
> or negotiate a new EAP type.
>
> 3b.  If the TEAP server does support the version then the conversation
> continues using the version proposed by the TEAP peer.

That looks clear to me; thanks for addressing this!

> The use of EAP-FAST-GTC as defined in RFC 5421 [RFC5421] is NOT
> RECOMMENDED with TEAPv1 because EAP-FAST-GTC is not compliant
> with EAP-GTC defined in [RFC3748].

Perfect.  Again, thanks.

Barry