Subject: [Emu] Channel Bindings: RADIUS or Diameter namespace

From: Sam Hartman <[email-masked]>
Date: Mon, 10 Jan 2011 14:51:35 -0500

At the last IETF, Glen proposed that rather than using diameter's
namespace for channel binding AVPs we use the RADIUS namespace. There
were two aspects to this concern.  One is that diameter has a larger
length value for attributes. If we're routinely exceeding 253-octets for
values that are part of channel binding, then EAP is not a good

The second aspect is that there is more overhead because the diameter
namespace is larger.

So far we've not been able to come across use cases for channel binding
for attributes present in Diameter but not RADIUS.

So, I'd like to propose that we adopt Glen's suggestion.

This may call into question an earlier discussion. At IETF 78, we decided
that we didn't need to have a mechanism for non-AAA channel binding
attributes, because especially for Diameter it is relatively easy to add
a new attribute.
The RADIUS namespace is more constrained.

I think we have a couple of options:

1) encourage the RADEXT work to extend the RADIUS namespace and work
with RADEXT to make sure they will be OK if they have to approve a
couple of attributes that we only expect to be used for channel binding.
I still expect there will be few of these.

2) Have multiple namespaces for attributes we support.  This may remove
a lot of the overhead savings for RADIUS over Diameter; in the obvious
implementation I'd expect we would waste a byte per AVP.

3) Decide Diameter is fine after all.

I don't care much what option we adopt.  I'd like to decide soon and
propose that option 2 is most conservative. If no other consensus
emerges I'd like to move forward with that option, effectively reversing
our IETF 78 decision.

Thoughts?

---

From: Alan DeKok <[email-masked]>
Date: Tue, 11 Jan 2011 09:43:10 +0100

> So, I'd like to propose that we adopt Glen's suggestion.

  Speaking as an individual, that sounds reasonable.

> I still expect there will be few of these.

  There are multiple proposals in RADIUS to extend the namespace.  Under
current allocation pressure, the namespace may be exhausted in 2-3
years.  That's about how long it takes for a new document to be
standardized.

> implementation I'd expect we would waste a byte per AVP.

  I'm not sure what you mean by that proposal.

> emerges I'd like to move forward with that option, effectively reversing

  We should be aware of the alternatives,and costs/benefits before
making or reversing any decision.

  Alan DeKok.

---

From: Joe Salowey <[email-masked]>
Date: Tue, 11 Jan 2011 15:33:37 -0800

> values that are part of channel binding, then EAP is not a good
[Joe] I think we do want to discourage using large amounts of data as channel bindings. 

> The RADIUS namespace is more constrained.

[Joe] I think we need to have a way to add new attributes that are not already present.   If we don't then at some point we will end up with the need to for a new attribute and we will have to revisit all this again.   

> I still expect there will be few of these.

[Joe] While I think this would be good to do, I think this work should be largely independent of and not tightly coupled to channel bindings .

> implementation I'd expect we would waste a byte per AVP.

[Joe] To me this sounds the simplest, but I previously favored this approach.  

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