Subject: [Emu] Submitted 10

From: Sam Hartman <[email-masked]>
Date: Wed, 19 Oct 2011 16:09:08 -0400

I believe I've addressed all of Alan's comments with the exception of
removing the RADIUS diagram from 5.3.
Thanks Alan for the comments!

--Sam

---

From: Glen Zorn <[email-masked]>
Date: Thu, 20 Oct 2011 10:40:17 +0700

> removing the RADIUS diagram from 5.3.

Great, so what are we supposed to do now?  WGLC was issued on
draft-ietf-emu-chbind-09.  The last call is not complete.  Shall we just
start over?  This creation of a moving target wouldn't be so annoying if
you were a newbie but you are anything but that...

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

---

From: Sam Hartman <[email-masked]>
Date: Thu, 20 Oct 2011 09:55:17 -0400

>>>>> "Glen" == Glen Zorn <[email-masked]> writes:

    >> removing the RADIUS diagram from 5.3.

    Glen> Great, so what are we supposed to do now?  WGLC was issued on
    Glen> draft-ietf-emu-chbind-09.  The last call is not complete.
    Glen> Shall we just start over?  

Documents are updated to reflect feedback during last calls all the
time. It happens in WGs I chair; it happened with documents for which I
was the AD; I've been asked to do it by ADs and other chairs.
Obviously, sometimes it is done wrong.

My thinking is that Alan's comments had been outstanding for a while,
seemed fairly obvious and with the exception of the question about
encoding of responses were non-contraversial.

None of them seemed to require a second last call.
By submitting 10 I've made  a version with the changes folded in
available for review.

What I did is clearly permitted by the process.  The chairs may of
course decide I made an error and that one of Alan's comments didn't
have sufficient consus. They can ask me to (or do it themselves)
resubmit 09 as 11, ask me to remove some text, or give more specific
guidance.  We may also discover that I incorrectly applied Alan's
comment.

You still had the options you had before. You can review 09 if you like
and send comments on 09. You can reply to Alan's comments and respond to
them.

You have some additional options now.  If you haven't started reviewing
yet you can start with 10.  If you'd like you can review the diff
between 10 and 9. You can review 9 and 10 separately if you have a lot
of free time on your hands.  You can ignore the whole thing.  You get a
chance to see Alan's context in the text. You can better appreciate them
and if you find a problem bring it up.

If you have trouble finding 09 or a diff between 09 and 10 let me know;
I bet we can find one if we work together.

If you have an objection to text in 9, text in 10, changes between the
two bring it up.  Objections of this form without an objection to actual
text are not constructive.

---

From: Glen Zorn <[email-masked]>
Date: Fri, 21 Oct 2011 15:57:36 +0700

> was the AD; I've been asked to do it by ADs and other chairs.

Drivers run red lights all the time, too.

> encoding of responses were non-contraversial.

Thank you for your authoritative reading of WG consensus.  If the
problems (and their solutions were so obvious, why were they present in
the draft at all?  In fact, they become "non-controversial" at the end
of last call, not in the middle.

> What I did is clearly permitted by the process.  

I could have sworn that the process WRT a WG Draft was that it was
changed only by direction of the Chair(s) as a result of the
determination of WG consensus, rather than at the whim of the editor.
Maybe a different process?

> The chairs may of

Apparently I was unclear: the specific text to which I am objecting is
-10.  All of it.

---

From: Dave Nelson <[email-masked]>
Date: Fri, 21 Oct 2011 09:22:48 -0400

> Apparently I was unclear: the specific text to which I am objecting is

Ooo.  Someone woke up exceptionally grumpy this morning.

Regards,

Dave

David B. Nelson
Sr. Software Architect
Elbrys Networks, Inc.
www.elbrys.com
+1.603.570.2636

---

From: Alan DeKok <[email-masked]>
Date: Fri, 21 Oct 2011 16:01:56 +0200

Glen Zorn wrote:
> the draft at all?

  No draft is perfect on first writing.  Even the IESG may offer
feedback to improve a document.

> Maybe a different process?

  I have no problem with a document being updated in WGLC due to
feedback on the list.  This has happened with other WG's, too.

> Apparently I was unclear: the specific text to which I am objecting is

  Curious.

  Alan DeKok.

---

From: Hao Zhou <[email-masked]>
Date: Fri, 21 Oct 2011 15:12:30 -0400

Sam:

My review comments:

1. Section 3, paragraph 1, should " far removed" be "far remoted"?
2. Section 3, bottom of Page 6, should "virtual Lads (VLANs)" be "virtual
LANs (VLANs)"?
3. Section 5.1, page 14, paragraph 2, should "I2" be "i2"?
4. So, client sends channel-binding data automatically or by its
configuration, not per server request? It seems inefficient for peer send a
big chunk of i1 without knowing whether the server supports channel binding
or what information is needs. Might be better if server can request it and
specific information before the peer sends it.
5. Section 7, should the title be Channel-binding AVP instead, as it talks
all about AVP, not TLV?

---

From: Sam Hartman <[email-masked]>
Date: Fri, 21 Oct 2011 15:33:51 -0400

I'll respond to the question of channel binding support now.  I think
the current text permits an EAP method to not send channel binding if it
knows the server fails to support it.  If your method can discover that
and optimistically avoid sending channel binding that's fine.

I think we discussed the flow in a fair bit of detail and I think we
have consensus on the current flow including the lack of server telling
the peer which channel binding attributes it supports.  As an
individual, I do not support opening that up again, although if there is
WG consensus to make a change we should do so.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 21 Oct 2011 21:36:17 +0200

> WG consensus to make a change we should do so.

  I think there's been a lot of discussion on the document.  We need to
get closure quickly.  This means not re-opening issues which were
previously discussed and decided.

  Alan DeKok.

---

From: Hao Zhou <[email-masked]>
Date: Fri, 21 Oct 2011 15:55:54 -0400

I wasn't aware of previous discussion and decision on this already. Sorry
for bringing this up. Proceed with the current draft.

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 21 Oct 2011 13:13:37 -0700

I want to make sure that we have distinguished between the two statements

1.  The server says that I don't support these specific attributes and
2.  The server does not tell me that it did or did not do matching of some
attributes.

The first I think is totally optional, but the second is necessary for the
tunnel draft and should be made explicit in this draft as something that
needs to be done.  I will be reading this document with this in mind.

Jim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Sam Hartman
> Sent: Friday, October 21, 2011 12:34 PM
> To: Hao Zhou
> Cc: Sam Hartman; [email-masked]
> Subject: Re: [Emu] Submitted 10
> 
> I'll respond to the question of channel binding support now.  I think the
> current text permits an EAP method to not send channel binding if it knows
> the server fails to support it.  If your method can discover that and
> optimistically avoid sending channel binding that's fine.
> 
> I think we discussed the flow in a fair bit of detail and I think we have
> consensus on the current flow including the lack of server telling the
peer
> which channel binding attributes it supports.  As an individual, I do not
> support opening that up again, although if there is WG consensus to make a
> change we should do so.

---

From: Hao Zhou <[email-masked]>
Date: Fri, 21 Oct 2011 16:20:43 -0400

Jim:

The chbind draft already has that covered by the use of the code. Tunnel
method defines the channel-binding TLV that wraps the channel data defined
in chbind draft, so I think we are ok.

---

From: Sam Hartman <[email-masked]>
Date: Fri, 21 Oct 2011 16:29:59 -0400

>>>>> "Jim" == Jim Schaad <[email-masked]> writes:

    Jim> I want to make sure that we have distinguished between the two
    Jim> statements 1.  The server says that I don't support these
    Jim> specific attributes 

    Jim> and 2.  The server does not tell me that it
    Jim> did or did not do matching of some attributes.

    Jim> The first I think is totally optional, but the second is
    Jim> necessary for the tunnel draft and should be made explicit in
    Jim> this draft as something that needs to be done.  

I think section 5.3 clearly requires that a peer learn whether the
server did do matching and if so, what attributes it successfully
matched.  We don't currently have a way for the server to say "these
attributes didn't match." That's kind of tricky and I'd prefer that to
be a future work item.  I've left extensibility for it.

Also, the client's request to the server is integrity protected.

I believe we should require and would appreciate you checking that we do
require:

1) A client supporting channel binding to a server supporting channel
binding will get channel binding. An attacker cannot downgrade to no
channel binding. I believe that by doing channel binding over an
integrity-protected channel we get that.

2) If you do channel binding the client will learn the result and will
learn which attributes it sent were considered and met whatever
consistency check the server did. This is a little vaguely worded
because there's a lot of latitude for server policy.