Subject: Re: [Emu] Working Group Last Call for draft-ietf-emu-chbind-09

From: Alan DeKok <[email-masked]>
Date: Sun, 02 Oct 2011 09:17:02 +0200

Sam Hartman wrote:
> I'm happy to make changes regarding your comments; a couple of them were
> not directly actionable but I can make best guesses.  Most of them were
> directly actionable and I agree the changes improve the text.
> I'd appreciate comments from the groups on whether we start codes at 2
> or 1.

  It's just a suggestion... there's no serious reason to switch.

>     Alan> 5.3.3.  Radius Namespace
> 
>     Alan>   I suggest leaving out all re-definition of RADIUS AVPs.
>     Alan> Instead, refer to RFC 2865 Section 5.  Say that the
>     Alan> NS-Specific data is RADIUS attributes, in the RADIUS attribute
>     Alan> format.  But the RADIUS packet header (code, length,
>     Alan> authenticator) is not included.
> 
> I'd prefer to keep the definition in.

  Why?  The specifications for RADIUS are publicly available.  I don't
see the purpose in duplicating that text.

> Unfortunately, as discussed in the text, we need to be able to send
> empty attributes in channel binding response.

  It's not clear:

   Some RADIUS container specifications forbid sending
   attributes with no value.  This prohibition not withstanding, these
   attributes SHOULD be sent with no value in channel binding responses.

  Sentence (1) is wrong.  RFC 2865 specifically forbids sending
attributes with no value.

> I understand RADIUS has no meaning for empty attributes, but I think we
> have a justified meaning for expressing that.

  The document contains no justification for empty responses.  Looking
for the word "response", I can't even find text which explains what the
EAP peer does with the empty response.

> I think the text is correct as is.

  The text should be clarified that zero-length attributes are
specifically forbidden by RADIUS.

> It's a SHOULD because we may specify cases where you include value or
> where you don't fully understand the container format.
> The definition of channel binding responses indicates that by default
> you SHOULD send the attribute without a value and explains why. (You
> don't want to echo back all that data.)

  There's a lot to discuss here.  The amount of "all that data" is
probably small, so it might not matter to echo it.

  And I'm still not sure why it's being echoed.  Does it serve as an
ACK, that the attribute was checked by the EAP server?

  From the document:

   The EAP server receives the channel binding data and performs the
   validation.  The EAP method provides a way to return a response; the
   channel binding response uses the same basic format as the channel
   binding data.

  OK.... so what does the response *mean*?

  For me, echoing a copy of an attribute (value and all) means that the
server validated the attribute.  Echoing nothing means that the server
doesn't know what to do with the attribute.  Echoing an attribute with
an empty value means... what?

  Alan DeKok.

---

From: Sam Hartman <[email-masked]>
Date: Tue, 18 Oct 2011 10:26:39 -0400

>>>>> "Alan" == Alan DeKok <[email-masked]> writes:

    Alan>   For me, echoing a copy of an attribute (value and all) means
    Alan> that the server validated the attribute.  Echoing nothing
    Alan> means that the server doesn't know what to do with the
    Alan> attribute.  Echoing an attribute with an empty value
    Alan> means... what?

It means the server validated the attribute.  I think there are several
important reasons not to echo the value in the attribute.

1) Space.  Some EAP methods limit the channel binding space. For all EAP
methods there is value in minimizing the size of messages.

2) What does the peer do with the echoed value? What if the echoed value
is different from what the peer sent? MAY the peer fail in that case?
SHOULD the peer fail in that case? MUST the peer fail in that case? Why
do we want to introduce complexity here? The peer clearly needs to know
what attributes the server validated. I don't understand why the peer
needs a copy of the attribute value it already sent except that it's
convenient if you're using an existing RADIUS library.

Hmm. OK, I thought there were some fairly compelling use cases related
to extensibility. I was thinking for example we might provide a way to
indicate why a EAP server failed to validate an attribute. For example,
in a channel binding failure we might decide that we want to indicate
which attributes validated and which ones did not and we might want to
use the value for that.  However, unmodified clients might misinterpret
that, so this extensibility option isn't nearly as valuable as I
thought. We can always invent a new namespace as an extensibility
mechanism if we need it.

So, we're left with space as the main argument and I agree it's not
compelling.

I propose that: 

1) We send full values in responses

2) Peers MUST ignore differences between the value sent in the channel
binding data and channel binding response.  This gives us the option of
changing the value if we ever find a reason to do so. It also prohibits
some particularly bad peer implementation strategies like doing a binary
comparison of the channel bindigns sent against the response.

3) Codes should define what attributes you include. For success we
include attributes the server considered in making the decision that
channel binding was successful. For our current failure code I think we
should also include all the attributes the server looked at--we are not
indicating what attributes are wrong. My rationale is that it may not be
easy to tell what's wrong; it may be that some attributes are
inconsistent and either of them alone could have been OK, but both
together was not.

4) Indicate that if a client doesn't understand a code, it treats it as
failure.

Would this work?