headers
jouni korhonen | 3 Dec 2010 11:02
Picon

Re: Diameter AVPs for Channel Binding


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
> Emu <at> ietf.org
> https://www.ietf.org/mailman/listinfo/emu
Permalink | Reply | 1 comment |
headers
Sam Hartman | 3 Dec 2010 13:04
Picon
Favicon

Re: Diameter AVPs for Channel Binding

>>>>> "jouni" == jouni korhonen <jouni.nospam <at> gmail.com> 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.
Permalink | Reply | 0 comments |
headers
Dan Harkins | 3 Dec 2010 18:34

Re: Diameter AVPs for Channel Binding


  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.

On Mon, November 22, 2010 8:28 am, 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
(Continue reading)

Permalink | Reply | 3 comments |
headers
Sam Hartman | 3 Dec 2010 19:53
Picon
Favicon

Re: Diameter AVPs for Channel Binding

>>>>> "Dan" == Dan Harkins <dharkins <at> lounge.org> 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.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Alan DeKok | 3 Dec 2010 21:57
Favicon
Gravatar

Re: Diameter AVPs for Channel Binding

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.

  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.
Permalink | Reply | 1 comment |
headers
Sam Hartman | 3 Dec 2010 22:18
Picon
Favicon

Re: Diameter AVPs for Channel Binding

>>>>> "Alan" == Alan DeKok <aland <at> deployingradius.com> 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.
Permalink | Reply | 0 comments |
headers
rishyang@gmail.com | 6 Dec 2010 03:35
Picon

答复: Re: Diameter AVPs for Channel Binding

衰，开盘被天天股份骗下了车。

从我的诺基亚手机发送
-----原始邮件-----
自:Dan Harkins
发送时间: 2010/12/04 01:34:53
至:Sam Hartman
抄送:hannes.tschofenig <at> gmx.net; emu <at> ietf.org
主题: Re: [Emu] Diameter AVPs for Channel Binding

  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.
(Continue reading)

Permalink | Reply | 0 comments |
headers
rishyang@gmail.com | 6 Dec 2010 04:06
Picon

转发: Re: Diameter AVPs for Channel Binding

HI, sorry. Please ignore my last emaIl. Someone use my mobile and send a wrong email. 

从我的诺基亚手机发送
-----原始邮件-----
自:rishyang <at> gmail.com; rishyang <at> gmail.com
发送时间: 2010/12/06 10:35:06
主题: 答复: Re: [Emu] Diameter AVPs for Channel Binding

衰，开盘被天天股份骗下了车。

从我的诺基亚手机发送
-----原始邮件-----
自:Dan Harkins
发送时间: 2010/12/04 01:34:53
至:Sam Hartman
抄送:hannes.tschofenig <at> gmx.net; emu <at> ietf.org
主题: Re: [Emu] Diameter AVPs for Channel Binding

  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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrea Manganaro - Oracle Corp. | 14 Dec 2010 17:46
Picon
Favicon

info about Call for Tunnel/Password Method Submissions

Hello,

according to IETF-79 minutes the EMU team has defined a 4-month Call for 
Tunnel/Password Method Submissions.
Is such a milestone confirmed?

regards,
Andrea

--

--
Permalink | Reply | 0 comments |

Gmane