Subject: [Emu] RFC 6677: empty attribute lists in Channel Binding responses

From: Sam Hartman <[email-masked]>
Date: Mon, 23 Sep 2013 15:08:31 -0400

We noticed a situation where our AAA server was generating a channel
binding response that was rejected by our supplicant code.

We looked into things and determined that the server was generating a
single octet failure response (code 3) and was including no attributes.

After re-reading section 5.3, we believe this is unambiguously permitted
and is correct behavior in the situation where we send it.
However, it was kind of non-intuitive to get a response back with no
information in it.

I don't think an erata is required, but I'd appreciate others looking at
the spec to confirm our reading.

Thanks,

--Sam

---

From: Sam Hartman <[email-masked]>
Date: Thu, 26 Sep 2013 12:29:38 -0400

>>>>> "Sam" == Sam Hartman <[email-masked]> writes:

    Sam> We noticed a situation where our AAA server was generating a
    Sam> channel binding response that was rejected by our supplicant
    Sam> code.

    Sam> We looked into things and determined that the server was
    Sam> generating a single octet failure response (code 3) and was
    Sam> including no attributes.
Actually, our debugging code was confusing.
The server is generating a code 3, the RADIUS NSID, and a length of 0
 for that NSID.

After reading section 5.3, I think it's ambiguous whether this is
permitted.
I'm going to change the server code to generate no NSID or length in
this situation because as discussed previously that is clearly
permitted.

I'd be interested in opinions about what clients should do in the case
where tan NSID with 0 length is received.