>>>>> "Alan" == Alan DeKok <[email protected]> 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?
_______________________________________________
Emu mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/emu
