headers
Bernard Aboba | 9 Aug 2005 18:03

: Change to "Reply-Message AVP" usage in Diameter EAP

Tom Hiller and Glen Zorn have found an issue in Diameter EAP that they
would like to fix in AUTH48.

The issue relates to an inconsistency between RADIUS/EAP as specified
in RFC 3579, and Diameter with respect to the Reply-Message AVP.

We now have:

2.8.3.  Displayable Messages

    The Reply-Message AVP [NASREQ] contains text which may be displayed
    to the user.  Note that the NAS does not necessarily have any
    facility for actually sending these messages to the user.  In any
    case, the NAS MUST NOT manufacture any EAP packets (such as
    EAP-Request/Notification) from Reply-Message AVPs.

Tom has suggested:

2.8.3.  Displayable Messages

The Reply-Message AVP [NASREQ] MUST NOT be included in any Diameter
message containing an EAP-Payload AVP.

Here is the text in RFC 3579, Section 2.6.5:

2.6.5.  Displayable Messages

   The Reply-Message attribute, defined in [RFC2865], Section 5.18,
   indicates text which may be displayed to the peer.  This is similar
   in concept to EAP Notification, defined in [RFC2284].  When sending a
(Continue reading)

Permalink | Reply | 1 comment |
headers
Bernard Aboba | 9 Aug 2005 21:36

: Re: Change to "Reply-Message AVP" usage in Diameter EAP

We would like AAA WG input by Friday August 12, 2005.  Please send your
opinions to the mailing list, stating clearly whether you are "For" or
"Against" this change.

On Tue, 9 Aug 2005, Bernard Aboba wrote:

> Tom Hiller and Glen Zorn have found an issue in Diameter EAP that they
> would like to fix in AUTH48.
>
> The issue relates to an inconsistency between RADIUS/EAP as specified
> in RFC 3579, and Diameter with respect to the Reply-Message AVP.
>
> We now have:
>
> 2.8.3.  Displayable Messages
>
>     The Reply-Message AVP [NASREQ] contains text which may be displayed
>     to the user.  Note that the NAS does not necessarily have any
>     facility for actually sending these messages to the user.  In any
>     case, the NAS MUST NOT manufacture any EAP packets (such as
>     EAP-Request/Notification) from Reply-Message AVPs.
>
> Tom has suggested:
>
> 2.8.3.  Displayable Messages
>
> The Reply-Message AVP [NASREQ] MUST NOT be included in any Diameter
> message containing an EAP-Payload AVP.
>
> Here is the text in RFC 3579, Section 2.6.5:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Santhosh K K | 10 Aug 2005 06:15
Favicon

FW: : Re: Change to "Reply-Message AVP" usage in Diameter EAP


I think the argument is valid...As the Reply message text will not be sent
to the user there is no point in including it in the message.

-----Original Message-----
From: owner-aaa-wg <at> merit.edu [mailto:owner-aaa-wg <at> merit.edu] On Behalf Of
Bernard Aboba
Sent: Wednesday, August 10, 2005 1:06 AM
To: aaa-wg <at> merit.edu
Subject: [AAA-WG]: Re: Change to "Reply-Message AVP" usage in Diameter EAP

We would like AAA WG input by Friday August 12, 2005.  Please send your
opinions to the mailing list, stating clearly whether you are "For" or
"Against" this change.

On Tue, 9 Aug 2005, Bernard Aboba wrote:

> Tom Hiller and Glen Zorn have found an issue in Diameter EAP that they
> would like to fix in AUTH48.
>
> The issue relates to an inconsistency between RADIUS/EAP as specified
> in RFC 3579, and Diameter with respect to the Reply-Message AVP.
>
> We now have:
>
> 2.8.3.  Displayable Messages
>
>     The Reply-Message AVP [NASREQ] contains text which may be displayed
>     to the user.  Note that the NAS does not necessarily have any
>     facility for actually sending these messages to the user.  In any
(Continue reading)

Permalink | Reply | 0 comments |
headers
German Blanco (E2/EEM | 10 Aug 2005 10:59
Picon
Favicon

RE: : Diameter SIP Application AVP and command codes

Dan,

I would be also of that 'old school', only problem is I wasn't there
when all this started :-)

All (I hope somebody else apart from the people that are/were in 
3GPP reads this),

could anybody tell me if there was any discussion at all about this
issue in the last IETF meeting?

I understand that the initial goal of this draft (please correct me 
if this is wrong) was to have a *superset* of the Cx application.  
That is, to have a Diameter application in IETF that allowed several 
methods for authentication of a SIP user, one of which could be Cx.
To me that makes perfect sense.

As it is, and as Dan said, there is a GREAT deal of common things, 
and that is what I call a "double specification" (the same thing 
defined in two places).  Not only that, if no effort is done for 
the alignment, the two specifications will have a lot of differences 
at protocol level, while being almost identical at a concept level.
That means that most developers will find themselves building two
protocol interfaces for their Diameter SIP Authentication nodes.

In my personal opinion, there should be an effort in making these
two specifications compatible.  Could it be possible to move in the
direction of removing common things and reusing existing codes so
that we end up with that "superset"?
(Continue reading)

Permalink | Reply | 0 comments |
headers
john.loughney | 10 Aug 2005 12:34
Picon

RE: : Diameter SIP Application AVP and command codes

Hello all,

The original 'agreement' was that the 3GPP Diameter AVP command codes
(used at the Cx interface) were valid only for Release 5. After Release
5, 3GPP was supposed to develop the SIP application inside of the IETF.
That hasn't really happened, but as far as the IETF is concerned,
the IETF is the place to standardize Diameter applications.

YMMV;
John

> -----Original Message-----
> From: ext German Blanco (E2/EEM) [mailto:german.blanco <at> ericsson.com]
> Sent: 10 August, 2005 12:00
> To: 'Warren, Dan, VF UK - Technology (TS)'; Loughney John
> (Nokia-NRC/Helsinki); Garcia Miguel.An (Nokia-NRC/Helsinki)
> Cc: aaa-wg <at> merit.edu
> Subject: RE: [AAA-WG]: Diameter SIP Application AVP and command codes
> 
> 
> Dan,
> 
> I would be also of that 'old school', only problem is I wasn't there
> when all this started :-)
> 
> All (I hope somebody else apart from the people that are/were in 
> 3GPP reads this),
> 
> could anybody tell me if there was any discussion at all about this
> issue in the last IETF meeting?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Pasi.Eronen | 10 Aug 2005 12:28
Picon

RE: : Change to "Reply-Message AVP" usage in Diameter EAP


Back when RFC 3579 was written, sending Reply-Message was a bad idea
because the only things the NAS could do with it was discard it (so
sending it wasn't necessary) or convert it to an EAP Notification
packet (a really bad idea for several reasons).

Since then, things have changed. For instance, PANA has the ability 
to send a displayable message to the client, and Reply-Message would 
be the most logical attribute for this (and is used for this purpose
in draft-ieft-pana-aaa-interworking-00). So if we prohibit using
Reply-Message, we may at some point need to define an identical
attribute with a different name/number to get around this "MUST NOT".

While IMHO this is the wrong choice from technical point of view 
(and it is RFC 3579 that needs updating rather than Diameter EAP), 
my impression from other AAA WG documents suggests that arguing 
about this issue will have no other effect than stretching the
Author's 48 Weeks period even longer. I really would like to get 
this document out some time this year, so if making this change
gets it published sooner, let it be so...

Best regards,
Pasi

> -----Original Message-----
> From: Bernard Aboba
> Sent: Tuesday, August 09, 2005 7:04 PM
> To: aaa-wg <at> merit.edu
> Subject: [AAA-WG]: Change to "Reply-Message AVP" usage in Diameter EAP
>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Bernard Aboba | 10 Aug 2005 18:38

: Re: AAA for Handovers

> A while ago, some work was done in the IRTF on RADIUS for handovers in the
> aaaarch-handoff draft, but it seems to have rather died now.

The extension specified in the draft was implemented, and experimental
measurements were made that showed that the technique was effective in
intra-domain use.

However, in other scenarios there are potential efficiency
issues since in 802.11 handoff is station-initiated and yet
pre-emptive keying does not allow the station to know where keys
have been sent.  As a result, the key state between the
peer, authenticator and server is not kept in sync and the station may not
be able to make effective roaming decisions.  For example, in roaming
scenarios the server would be unlikely to have a complete knowledge of
the topology and thus would be unable to determine where to send keying material.

This causes pre-emptive keying to be ineffective in
inter-domain use.  There are also concerns about intra-domain
deployments because pre-emptive keying requires RFC 3576-style
server-initiated messages.

Finally, questions were also raised about whether the mechanism satisfied
the criteria in draft-housley since the pre-emptive keying scheme does not
authenticate the user through the NAS that it will connect to.

As a result, the focus of work on fast handoff has shifted away from
pre-emptive keying schemes initiated by the server, toward "key request"
schemes initiated by the peer.  Advantages of "Key Request" include:

a. The station can send an authenticated "Key Request" via the target
(Continue reading)

Permalink | Reply | 0 comments |
headers
Narayanan Vidya-CVN065 | 10 Aug 2005 20:42

: RE: AAA for Handovers

Hi Bernard,
Thanks for the detailed explanation. This was very helpful to me. Please see some questions/comments
inline. 

> -----Original Message-----
> From: Bernard Aboba [mailto:aboba <at> internaut.com]
> Sent: Wednesday, August 10, 2005 11:38 AM
> To: Narayanan Vidya-CVN065
> Cc: radiusext <at> ops.ietf.org; aaa-wg <at> merit.edu; Korus Mike-CMK013
> Subject: Re: AAA for Handovers
> 
> 
> > A while ago, some work was done in the IRTF on RADIUS for
> handovers in
> > the aaaarch-handoff draft, but it seems to have rather died now.
> 
> The extension specified in the draft was implemented, and
> experimental measurements were made that showed that the 
> technique was effective in intra-domain use.
> 
> However, in other scenarios there are potential efficiency
> issues since in 802.11 handoff is station-initiated and yet 
> pre-emptive keying does not allow the station to know where 
> keys have been sent.  As a result, the key state between the 
> peer, authenticator and server is not kept in sync and the 
> station may not be able to make effective roaming decisions.  
> For example, in roaming scenarios the server would be 
> unlikely to have a complete knowledge of the topology and 
> thus would be unable to determine where to send keying material.
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Bernard Aboba | 10 Aug 2005 23:44

: RE: AAA for Handovers

> Can this not be addressed by providing a mechanism in AAA to carry target NAS-IDs
> from the current NAS through which the STA is authenticating? I agree
> that it is unrealistic to expect the AAA server to have complete
> knowledge of the topology. By allowing this information to be carried in
> RADIUS to the server, the topology information can still come from the
> STA - of course, this will require some support from EAP as well to get
> this from the STA to the current NAS, but it still seems like it can be
> done. So, in this model, the AAA server will only derive keys for the
> requested target NAS devices - so, the station will know where the keys
> are sent. Am I missing something?

While technologies such as 802.11 allow a NAS to discover the L2 address
of its neighbors (e.g. IEEE 802.11k Neighbor Report), there is currently
no mechanism to allow discovery of L3 addresses or names.  So today an AP
has no way to learn the L3 address of a neighbor, let alone the neighbor
NAS-Identifier.  So before the AAA client could provide this information
to the server it would need a mechanism to obtain it.  In the case of
802.11, this would probably imply the addition of an L3 address or
NAS-Identifier IE to the Beacon/Probe Response.  I think that IEEE 802.11r
does include support for the latter, but not the former.

> Yes, true. I have wondered why RFC3576 wasn't made a bit more generic,
> with "disconnect" being one type of message. But, why is this style bad?

The issue is that RFC 3576 has not been widely implemented.  There are a
few devices that support it (e.g. Airespace WLAN switches) and a few
servers.  This makes it possible to deploy RFC 3576 in an intra-domain
scenario, but in inter-domain scenarios you'd need to upgrade all the
intervening proxies and there are some substantial security issues to deal.
For example, you'd need to make sure one ISP couldn't disconnect or change
(Continue reading)

Permalink | Reply | 0 comments |
headers
mikko.aittola | 11 Aug 2005 14:26
Picon

RE: : Diameter SIP Application AVP and command codes

Hi,

> if no effort is done for the alignment, the two specifications will
> have a lot of differences at protocol level, while being almost
> identical at a concept level. That means that most developers will
> find themselves building two protocol interfaces for their Diameter
> SIP Authentication nodes.
> 
> In my personal opinion, there should be an effort in making these
> two specifications compatible.

I agree.

BR,
Mikko

> -----Original Message-----
> From: owner-aaa-wg <at> merit.edu 
> [mailto:owner-aaa-wg <at> merit.edu]On Behalf Of
> ext German Blanco (E2/EEM)
> Sent: 10 August, 2005 12:00
> To: 'Warren, Dan, VF UK - Technology (TS)'; Loughney John
> (Nokia-NRC/Helsinki); Garcia Miguel.An (Nokia-NRC/Helsinki)
> Cc: aaa-wg <at> merit.edu
> Subject: RE: [AAA-WG]: Diameter SIP Application AVP and command codes
> 
> 
> Dan,
> 
> I would be also of that 'old school', only problem is I wasn't there
(Continue reading)

Permalink | Reply | 1 comment |

Gmane