Subject: Re: [Emu] Diameter AVPs for Channel Binding

From: jouni korhonen <[email-masked]>
Date: Fri, 3 Dec 2010 12:02:44 +0200

Hi,

As far as I remember there are no specific AVPs for channel binding purposes defined for any Diameter application documented in IETF.

- Jouni

On Nov 22, 2010, at 6:28 PM, Sam Hartman wrote:

> 
> 
> Hannes, at the EMU meeting we were discussing  whether there are any
> attributes we're likely to want to bind to in EAP channel binding that
> are in the diameter rather than RADIUS namespace.
> I asked for your thoughts and you said you'd have to look into it.
> 
> Any chance you could get input (with appropriate context) from the
> Diameter community on this issue?
> 
> --Sam
> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu

---

From: Sam Hartman <[email-masked]>
Date: Fri, 03 Dec 2010 07:04:00 -0500

>>>>> "jouni" == jouni korhonen <[email-masked]> writes:

    jouni> Hi,

    jouni> As far as I remember there are no specific AVPs for channel
    jouni> binding purposes defined for any Diameter application
    jouni> documented in IETF.

That's not really the interesting question.
The interesting question is whether there are link-layer-specific AVPs
useful for channel binding defined for Diameter but not RADIUS.

---

From: "Dan Harkins" <[email-masked]>
Date: Fri, 3 Dec 2010 09:34:53 -0800 (PST)

Hi Sam,

  I know you have expressed your desire to use an existing registry
to identify channel binding information, I just don't recall hearing
you say why it's a good idea. Could you explain the benefits (once
more) of using an existing registry versus rolling our own?

  If we use an existing registry I still think there are going to be
some link-level information that might not be in the existing registry
and we're going to have to roll our own registry to some extent anyway.
As a for instance (and this example may be contrived), there might be
some provider that charges more for an 11n connection than an 11a/b/g
connection. It might be valuable to bind this information to the
channel to prevent billing issues later but I am not aware of an
attribute in an existing registry to support this.

  regards,

  Dan.

---

From: Sam Hartman <[email-masked]>
Date: Fri, 03 Dec 2010 13:53:07 -0500

>>>>> "Dan" == Dan Harkins <[email-masked]> writes:

    Dan>   Hi Sam,

    Dan>   I know you have expressed your desire to use an existing
    Dan> registry to identify channel binding information, I just don't
    Dan> recall hearing you say why it's a good idea. Could you explain
    Dan> the benefits (once more) of using an existing registry versus
    Dan> rolling our own?

Seems like it's less effort.  When I look at the effort involved for the
two applications of CB that we've started to spec out in detail (abfab
and 802.11), many of the attributes we bind to are already in the RADIUS
namespace in the case of 802.11 or need to be there for other reasons in
the case of abfab.  So, we have less registration work to do if we have
a registry that can import that namespace.

My assumption is that either we use diameter or that RADIUS solves their
attribute shortage problem and that if we need to register new things
that we are not going to run into problems doing that.
I think we should explicitly discuss this with radext/dime if we want to
reuse their registry.

    Dan>   If we use an existing registry I still think there are going
    Dan> to be some link-level information that might not be in the
    Dan> existing registry and we're going to have to roll our own
    Dan> registry to some extent anyway.  

I agree we'll have to register some things.

    Dan> As a for instance (and this
    Dan> example may be contrived), there might be some provider that
    Dan> charges more for an 11n connection than an 11a/b/g
    Dan> connection. It might be valuable to bind this information to
    Dan> the channel to prevent billing issues later but I am not aware
    Dan> of an attribute in an existing registry to support this.

Yep. It would take a lot for this particular example to be an
issue. You'd need to interoperably understand the charging model. It's
presumably possible that someone like 3GPP might want to do that.
If you aren't actually encoding the charging model over the wire, then
you're stuck understanding the  charging model based on local
configuration and some identity of the network you're connecting to.
That's a problem that we have more ability to do with the existing
attributes.

So, I think we're better off with an existing registry provided that we
can get things we need registered in it. I think it's not a huge deal to
go do our own registry if we need to; doing so probably makes
implementation more messy on the AAA server especially, but is not
impossible.

I'd really like to know the answer soon though. Moonshot expects to be
funding development of CB for AAA servers during the first half of next
year.  So let's see if we can come to consensus on this quickly.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 03 Dec 2010 21:57:44 +0100

> implementation more messy on the AAA server especially, but is not

  If the CB data has value to AAA *outside* of the context of channel
binding, then there are likely already AVPs defined for it in AAA
protocols.  Or, it will be useful to define new AVPs.

  If the CB data does *not* have value to AAA outside of the context of
channel bindings, then using a namespace (and AVP format) specific to CB
is the best approach.

  Alan DeKok.

---

From: Sam Hartman <[email-masked]>
Date: Fri, 03 Dec 2010 16:18:19 -0500

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

    Alan> Sam Hartman wrote:
    >> So, I think we're better off with an existing registry provided
    >> that we can get things we need registered in it. I think it's not
    >> a huge deal to go do our own registry if we need to; doing so
    >> probably makes implementation more messy on the AAA server
    >> especially, but is not impossible.

    Alan>   If the CB data has value to AAA *outside* of the context of
    Alan> channel binding, then there are likely already AVPs defined
    Alan> for it in AAA protocols.  Or, it will be useful to define new
    Alan> AVPs.

    Alan>   If the CB data does *not* have value to AAA outside of the
    Alan> context of channel bindings, then using a namespace (and AVP
    Alan> format) specific to CB is the best approach.

It's my suspicion that the vast majority of CB data has value to AAA
outside of the context of CB.  It's possible that if we go the route of
using an AAA registry and don't have a mechanism for registering non-AAA
CB, then we'll find ourselves having to register an AAA attribute useful
almost exclusively for CB from time to time.  I think that will be rare
but notimpossible.
I do find it telling that I cannot think of a CB attribute that I
wouldn't sometimes want to send over AAA.