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

From: Sam Hartman <[email-masked]>
Date: Tue, 08 Feb 2011 14:42:55 -0500

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

    >> 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.

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

So, we're asking EAP methods to give us a space to stick channel
bindings data.
The channel bindings data  could look like a set of
* Length
* namespace ID
* ns-specific

namespace 0: RADIUS--a single RADIUS type and value (we already have a
length)

So, assuming 1 byte for the namespace and no padding, it takes us an
extra byte over RADIUS to store a RADIUS AVP in channel binding data.

There are obvious ways you could optimize that some.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 10 Feb 2011 13:47:31 +0100

> namespace 0: RADIUS--a single RADIUS type and value (we already have a

  Ah, OK.

> There are obvious ways you could optimize that some.

  Hmm... I might be inclined to keep the namespace-specific packing.
i.e. the RADIUS namespace packs RADIUS attributes, just like they would
be packed in a RADIUS packet.

  That has slightly more overhead, and the issue of lengths potentially
disagreeing.  But it has the benefit of simplifying the
packing/unpacking code somewhat.

  The issue for Diameter is that the requirements are for the data to be
aligned.  Does that requirement continue for the channel-bindings data?
 Or can we just pack Diameter data into an opaque blob, and wrap a 2-4
byte "channel binding" header around it?

  Alan DeKok.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 10 Feb 2011 08:58:44 -0500

I considered retaining namespace-specific packing.  my concern is that
in the channel binding response you want to remove values.  This ends up
being a bit namespace specific because of VSAs but seems to argue for
the channel binding logic ending up getting stuck with a fair bit of
namespace specific logic.  I also really wanted to avoid more than one
length for a given attribute because that tends to cause problems in a
security protocol--they can get out of sync.  A blob of RADIUS stuff all
with its own length would not suffer from the length issue so much.

This is an area where I want us to decide quite quickly what the answer
is going to be, but where I don't have a hugely strong opinion on what
it is.
I threw something out to make forward progress.
So long as we can actually decide on something soon, I'm happy to change
to another way of encoding.