Subject: Re: AW: AW: AW: Digest Authentication: Security issue with https/sips
From: Bernard Aboba <[email-masked]>
To: Miguel Garcia <[email-masked]>
Cc: "Beck01, Wolfgang" <[email-masked]>, [email-masked]
Date: Fri, 30 Sep 2005 08:27:31 -0700 (PDT)

I think I agree with Miguel that the security of the RADIUS exchange is 
a somewhat orthogonal issue from the security of the SIP Digest exchange.

For example, the RADIUS exchange may occur over a different network than 
the SIP exchange, which may be more or less vulnerable.  Just because the 
SIP UA doesn't request TLS, or sends a registration request over a 
wireless network, does that mean there is no need to secure the 
RADIUS exchange?  Or because the SIP UA does request TLS, does that mean 
that it is also attempting to negotiate RADIUS security at the same time?

My recommendation would be to unlink the SIP and RADIUS exchanges.  If you 
want to recommend encryption to protect Digest attributes that is ok, but 
I wouldn't mention SIP/SIPs exchanges in the same paragraphs and link them 
together. 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 30 Sep 2005 15:15:32 +0000
Date: Fri, 30 Sep 2005 08:15:02 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: "Nagi Reddy Jonnala (njonnala)" <[email-masked]>
cc: "Murtaza Chiba (mchiba)" <[email-masked]>, [email-masked],  [email-masked]
Subject: RE: Issue: Counters for Session Contexts not found in RFC3576 MIBS

I think I was going to go on to talk about Error Messages.  Some of them 
might be useful to count. 

On Fri, 30 Sep 2005, Nagi Reddy Jonnala (njonnala) wrote:

>  
> > > Alternative, is to maintain a counter for requests that are 
> > for Diameter RAR capabilities.
> > 
> > I do think it may make sense to count "Authorization Only" CoA and 
> > Disconnect-Requests.  In terms of the 
> 
>  Did Bernard miss anything in the last line? I don't think we agreed for
> any "Authorize-only" Dyn auth requests. Could you guys conclude this
> conversation as well?
> 
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 30 Sep 2005 06:26:27 +0000
Content-class: urn:content-classes:message
Subject: RE: FW: I-D ACTION:draft-salowey-radext-delegated-prefix-00.txt
Date: Thu, 29 Sep 2005 23:25:54 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, "Joseph Salowey \(jsalowey\)" <[email-masked]>
Cc: <[email-masked]>

Bernard Aboba <> supposedly scribbled:

>> [Joe] My understanding is that Framed-IPv6-Prefix causes a route to
>> be added in the NAS and I would expect that route to be advertised
>> in a Router Advertisement messages.
>=20
> RFC 3162 Section 2.3 states about Framed-IPv6-Prefix:
>=20
> "     This Attribute indicates an IPv6 prefix (and corresponding
>       route) to be configured for the user. "
>=20
> For Framed-IPv6-Route, RFC 3162, Section 2.5 states:
>=20
> "     This Attribute provides routing information to be configured for
>       the user on the NAS.  It is used in the Access-Accept packet and
>       can appear multiple times."
>=20
> RFC 2865, Section 5.10 describes Framed-Routing:
>=20
> "     This Attribute indicates the routing method for the user, when
>       the user is a router to a network.  It is only used in
>       Access-Accept packets."
>=20
> Based on this, I think Framed-IPv6-Prefix causes a route to be added
> on the NAS and advertised to the user via Router Advertisement, but
> not via routing packets (e.g. RIPv2) unless indicated in
> Framed-Routing. =20

I'm inclined to agree.=20

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by simply
  listening to John Coltrane? -- Henry Gabriel

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 30 Sep 2005 06:12:28 +0000
Date: Thu, 29 Sep 2005 23:12:02 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: "Salowey, Joe" <[email-masked]>
cc: [email-masked]
Subject: RE: FW: I-D ACTION:draft-salowey-radext-delegated-prefix-00.txt

> [Joe] My understanding is that Framed-IPv6-Prefix causes a route to be
> added in the NAS and I would expect that route to be advertised in a
> Router Advertisement messages.   

RFC 3162 Section 2.3 states about Framed-IPv6-Prefix:

"     This Attribute indicates an IPv6 prefix (and corresponding route)
      to be configured for the user. "

For Framed-IPv6-Route, RFC 3162, Section 2.5 states: 

"     This Attribute provides routing information to be configured for
      the user on the NAS.  It is used in the Access-Accept packet and
      can appear multiple times."

RFC 2865, Section 5.10 describes Framed-Routing:

"     This Attribute indicates the routing method for the user, when the
      user is a router to a network.  It is only used in Access-Accept
      packets."

Based on this, I think Framed-IPv6-Prefix causes a route to be added 
on the NAS and advertised to the user via Router Advertisement, but not 
via routing packets (e.g. RIPv2) unless indicated in Framed-Routing. 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 30 Sep 2005 04:18:55 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue: Counters for Session Contexts not found in RFC3576 MIBS
Date: Fri, 30 Sep 2005 09:48:13 +0530
From: "Nagi Reddy Jonnala \(njonnala\)" <[email-masked]>
To: "Murtaza Chiba \(mchiba\)" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

=20
> > Alternative, is to maintain a counter for requests that are=20
> for Diameter RAR capabilities.
>=20
> I do think it may make sense to count "Authorization Only" CoA and=20
> Disconnect-Requests.  In terms of the=20

 Did Bernard miss anything in the last line? I don't think we agreed for
any "Authorize-only" Dyn auth requests. Could you guys conclude this
conversation as well?

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 29 Sep 2005 20:30:56 +0000
content-class: urn:content-classes:message
Subject: RE: FW: I-D ACTION:draft-salowey-radext-delegated-prefix-00.txt
Date: Thu, 29 Sep 2005 13:35:45 -0700
From: "Salowey, Joe" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>

Hi Bernard,

Thanks for the quick review.  Comments in line below. =20

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]]=20
> Sent: Tuesday, September 27, 2005 6:36 AM
> To: [email-masked]
> Subject: Re: FW: I-D=20
> ACTION:draft-salowey-radext-delegated-prefix-00.txt
>=20
> Some questions:
>=20
> a. Based on the introduction is the below a description of=20
> which messages this attribute can be included in?
>=20
>    Request Accept Reject Challenge Accounting  #  Attribute
>                                    Request
>    0+      0+     0      0         0+         TBD =20
> Delegated-IPv6-Prefix
>=20

[Joe] The table looks good, we'll add it.=20

> b.  In Section 1, it states:
>=20
> "  the prefix in
>    a Framed-IPv6-Prefix attribute can be assigned to a link=20
> to which the
>    NAS is attached, and subsequently advertised through Router
>    Advertisement messages [3]."
>=20
> Control over what is advertised is controlled by=20
> Framed-Routing and Framed-IPv6-Route, not Framed-IPv6-Prefix, right?
>=20

[Joe] My understanding is that Framed-IPv6-Prefix causes a route to be
added in the NAS and I would expect that route to be advertised in a
Router Advertisement messages.  =20

> For example, in [RFC2865] Section 5.10 (Framed-Routing):
>=20
> "     This Attribute indicates the routing method for the=20
> user, when the
>       user is a router to a network.  It is only used in Access-Accept
>       packets."
>=20
>=20
> On Mon, 26 Sep 2005, Salowey, Joe wrote:
>=20
> >=20
> > > ---------- Forwarded message ----------
> > > From: [email-masked] <[email-masked]>
> > > Date: Sep 22, 2005 3:50 PM
> > > Subject: I-D ACTION:draft-salowey-radext-delegated-prefix-00.txt
> > > To: [email-masked]
> > >=20
> > >=20
> > > A New Internet-Draft is available from the on-line=20
> Internet-Drafts=20
> > > directories.
> > >=20
> > >=20
> > >         Title           : RADIUS Delegated-IPv6-Prefix Attribute
> > >         Author(s)       : J. Salowey, R. Droms
> > >         Filename        :=20
> draft-salowey-radext-delegated-prefix-00.txt
> > >         Pages           : 6
> > >         Date            : 2205-9-22
> > >=20
> > >    The Delegated-IPv6-Prefix attribute indicates an IPv6=20
> prefix that=20
> > > is
> > >    to be delegated to the user.
>=20
> --
> to unsubscribe send a message to=20
> [email-masked] with the word 'unsubscribe' in=20
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 28 Sep 2005 17:01:06 +0000
Date: Wed, 28 Sep 2005 10:00:36 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: "Murtaza Chiba (mchiba)" <[email-masked]>
cc: [email-masked]
Subject: Re: Issue: Counters for Session Contexts not found in RFC3576 MIBS

On Wed, 28 Sep 2005, Murtaza Chiba (mchiba) wrote:

> Glen Z., has suggested the addition of counters in the event where the Session Context is not found for the 
> RFC3576 MIBS.   This requires the addition of 4 objects, one each for DM 
> and CoA messages for both the client and server MIBs.   There is a good 
> need for this as NAKs could be sent for Diameter RAR capabilities, in 
> which case the NAK is not an error condition.

I think this makes sense. 

> Other Error Cause codes will not have corresponding counters.   There is a security concern that 
> the counter may provide information valuable for attacks.   The authors 
> would like to get the general feel for this.

Presumably access is only being provided to the SNMP manager, correct?  I 
would focus on whether the information is useful rather than whether it is 
security-sensitive. 

There is probably some value in tracking error messages by DAC and DAS, so 
as to see if there is a problem with a client or server.  For example, if 
an error 501 is being returned by a DAC (Administratively Prohibited), 
this could represent a security problem that needs to be addressed (e.g. 
someone is trying to send unauthorized Disconnect-Requests). 

I'm note sure whether the way to do this is via counters or potentially an 
error message table.  

> Alternative, is to maintain a counter for requests that are for Diameter RAR capabilities.

I do think it may make sense to count "Authorization Only" CoA and 
Disconnect-Requests.  In terms of the 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 28 Sep 2005 08:07:53 +0000
Content-class: urn:content-classes:message
Subject: Issue: Counters for Session Contexts not found in RFC3576 MIBS
Date: Wed, 28 Sep 2005 01:06:58 -0700
From: "Murtaza Chiba \(mchiba\)" <[email-masked]>
To: <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C5C403.997EE0C3
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Glen Z., has suggested the addition of counters in the event where the =
Session Context is not found for the RFC3576 MIBS.   This requires the =
addition of 4 objects, one each for DM and CoA messages for both the =
client and server MIBs.   There is a good need for this as NAKs could be =
sent for Diameter RAR capabilities, in which case the NAK is not an =
error condition.

Other Error Cause codes will not have corresponding counters.   There is =
a security concern that the counter may provide information valuable for =
attacks.   The authors would like to get the general feel for this.

Alternative, is to maintain a counter for requests that are for Diameter =
RAR capabilities.

Thanks and Regards,
Murtaza

------_=_NextPart_001_01C5C403.997EE0C3
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7233.8">
<TITLE>Issue: Counters for Session Contexts not found in RFC3576 =
MIBS</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<BR>

<P><FONT SIZE=3D2>Glen Z., has suggested the addition of counters in the =
event where the Session Context is not found for the RFC3576 =
MIBS.&nbsp;&nbsp; This requires the addition of 4 objects, one each for =
DM and CoA messages for both the client and server MIBs.&nbsp;&nbsp; =
There is a good need for this as NAKs could be sent for Diameter RAR =
capabilities, in which case the NAK is not an error condition.<BR>
<BR>
Other Error Cause codes will not have corresponding =
counters.&nbsp;&nbsp; There is a security concern that the counter may =
provide information valuable for attacks.&nbsp;&nbsp; The authors would =
like to get the general feel for this.<BR>
<BR>
<BR>
Alternative, is to maintain a counter for requests that are for Diameter =
RAR capabilities.<BR>
<BR>
Thanks and Regards,<BR>
Murtaza</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C5C403.997EE0C3--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 27 Sep 2005 17:04:06 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue 113: Attribute Concatenation
Date: Tue, 27 Sep 2005 10:03:36 -0700
From: "Congdon, Paul T (ProCurve)" <[email-masked]>
To: "Emile van Bergen" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>

> >  =20
> >         As per the requirements of RFC 2865, Section 2.3,=20
> if multiple=20
> >         QoS-Filter-Rule attributes are contained within an Access-
> >         Request or Access-Accept packet, they MUST be maintained in=20
> >         order. The attributes MUST be consecutive attributes in the=20
> >         packet. RADIUS proxies MUST NOT reorder QoS-Filter-Rule=20
> >         attributes.=20
>=20
> I think the relevant section of RFC 2865 is Section 5, and it states:
>=20
>    If multiple Attributes with the same Type are present, the order of
>    Attributes with the same Type MUST be preserved by any=20
> proxies.  The
>    order of Attributes of different Types is not required to be
>    preserved.  A RADIUS server or client MUST NOT have any=20
> dependencies
>    on the order of attributes of different types.  A RADIUS server or
>    client MUST NOT require attributes of the same type to be=20
> contiguous.
>=20
> So I see two issues. 1: the conflict between the "consecutive=20
> attributes" requirement and the last sentence of the text=20
> quoted above, and 2. it would probably be clearer if the=20
> reference pointed to Section
> 5 (Attributes) instead of section 2.3 (Proxy behaviour).
>

Yes, what is important is that the order is maintained, not that the
attributes are consecutive.  Since this sentence is in direct conflict
with 2865, we need to remove it.  Also I agree that Section 5 appears to
be the better reference.  The last paragraph should read:

       As per the requirements of RFC 2865, Section 5, if multiple=20
       QoS-Filter-Rule attributes are contained within an Access-
       Request or Access-Accept packet, they MUST be maintained in=20
       order. RADIUS proxies MUST NOT reorder QoS-Filter-Rule=20
       attributes.=20

I'm still working on a response to the rest of Glen's comments...

Paul

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 27 Sep 2005 16:13:59 +0000
Date: Tue, 27 Sep 2005 18:13:36 +0200
From: Emile van Bergen <[email-masked]>
To: "Congdon, Paul T (ProCurve)" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Issue 113: Attribute Concatenation
Mail-Followup-To: "Congdon, Paul T (ProCurve)" <[email-masked]>, [email-masked], [email-masked], [email-masked]

Hi,

On Tue, Sep 27, 2005 at 08:27:56AM -0700, Congdon, Paul T (ProCurve) wrote:

> 
> Taking Glen's suggested text, I'd like to close this issue out with the
> following proposed text for the Text field in section 3.6.  Please let
> me know if this will work.
>  
>  
>      Text
> 
>         The Text field contains a QoS filter, utilizing the syntax 
>         defined for the QoSFilterRule derived data type defined in 
>         [RFC3588], Section 4.3.  Note that this definition contained 
>         an error, so that the complete syntax is described in the 
>         definition of the QoS-Filter-Rule AVP, defined in [NASREQ]. 
>        
>         The RADIUS server can return multiple QoS-Filter-Rule 
>         attributes in an Access-Accept or CoA-Request packet. Where 
>         more than one QoS-Filter-Rule Rule attribute is included, it
>         is assumed that the attributes are to be concatenated to form
>         a single QOS filter. 
>  
>         Whereas the maximum allowable AVP size in [NASREQ] is greater
>         than RADIUS' maximum allowable attribute size, it is assumed
>         that QOS filters that exceed RADIUS' allowable attribute size
>         will be broken into multiple QoS-Filter-Rule attributes by 
>         the RADIUS server and concatenated back into a single QOS
>         filter by the NAS.
>   
>         As per the requirements of RFC 2865, Section 2.3, if multiple 
>         QoS-Filter-Rule attributes are contained within an Access-
>         Request or Access-Accept packet, they MUST be maintained in 
>         order. The attributes MUST be consecutive attributes in the 
>         packet. RADIUS proxies MUST NOT reorder QoS-Filter-Rule 
>         attributes. 

I think the relevant section of RFC 2865 is Section 5, and it states:

   If multiple Attributes with the same Type are present, the order of
   Attributes with the same Type MUST be preserved by any proxies.  The
   order of Attributes of different Types is not required to be
   preserved.  A RADIUS server or client MUST NOT have any dependencies
   on the order of attributes of different types.  A RADIUS server or
   client MUST NOT require attributes of the same type to be contiguous.

So I see two issues. 1: the conflict between the "consecutive
attributes" requirement and the last sentence of the text quoted above,
and 2. it would probably be clearer if the reference pointed to Section
5 (Attributes) instead of section 2.3 (Proxy behaviour).

Cheers,

Emile.

-- 
E-Advies - Emile van Bergen           [email-masked]      
tel. +31 (0)78 6136282           http://www.e-advies.nl    

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 27 Sep 2005 16:05:13 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue 113: Attribute Concatenation
Date: Tue, 27 Sep 2005 09:04:46 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Congdon, Paul T \(ProCurve\)" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

Congdon, Paul T (ProCurve) <mailto:[email-masked]> supposedly =
scribbled:

> Taking Glen's suggested text, I'd like to close this issue out with
> the following proposed text for the Text field in section 3.6.=20
> Please let me know if this will work. =20
>=20
>=20
>      Text
>=20
>         The Text field contains a QoS filter, utilizing the syntax
>         defined for the QoSFilterRule derived data type defined in
>         [RFC3588], Section 4.3.  Note that this definition contained
>         an error, so that the complete syntax is described in the
>         definition of the QoS-Filter-Rule AVP, defined in [NASREQ].

Are you _sure_ that you want to use this syntax?  It's awfully verbose.  =
Even if you really do want to use it, I would suggest that you reproduce =
it (or rather, adapt it to use w/RADIUS) in this document, rather than =
incorporating it by reference.  There are several problems with the =
Diameter definitions, not least of which is that the definition of the =
QoS-Filter-Rule AVP depends upon the definition of IPFilterRule which is =
derived from OctetString which doesn't exist in RADIUS.

>=20
>         The RADIUS server can return multiple QoS-Filter-Rule
>         attributes in an Access-Accept or CoA-Request packet. Where
>         more than one QoS-Filter-Rule Rule attribute is included, it
>         is assumed that the attributes are to be concatenated to form
>         a single QOS filter.
>=20
>         Whereas the maximum allowable AVP size in [NASREQ] is greater
>         than RADIUS' maximum allowable attribute size, it is assumed
>         that QOS filters that exceed RADIUS' allowable attribute size
>         will be broken into multiple QoS-Filter-Rule attributes by
>         the RADIUS server and concatenated back into a single QOS
>         filter by the NAS.

I still am puzzled by the reference to Diameter.  As I mentioned =
earlier, it is not possible to fit a maximum sized QOS-Filter-Rule AVP =
into a single RADIUS message, never mind a set of RADIUS attributes.  So =
why even talk about it?  I also think that it would be a very good idea =
to specify a maximum length for QOS filter rules themselves.  Also, if a =
filter is made up of filter rules, it makes sense that rules can be =
concatenated to form a filter; however, the paragraph above offers no =
guidance the case where a rule doesn't fit into a QoS-Filter-Rule =
attribute.

>=20
>         As per the requirements of RFC 2865, Section 2.3, if multiple
>         QoS-Filter-Rule attributes are contained within an Access-
>         Request or Access-Accept packet, they MUST be maintained in
>         order.=20
>         The attributes MUST be consecutive attributes in the
>         packet.=20

Why?

>         RADIUS proxies MUST NOT reorder QoS-Filter-Rule
>         attributes.

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by simply
  listening to John Coltrane? -- Henry Gabriel

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 27 Sep 2005 15:29:12 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue 113: Attribute Concatenation
Date: Tue, 27 Sep 2005 08:27:56 -0700
From: "Congdon, Paul T (ProCurve)" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>

Taking Glen's suggested text, I'd like to close this issue out with the
following proposed text for the Text field in section 3.6.  Please let
me know if this will work.
=20
=20
     Text

        The Text field contains a QoS filter, utilizing the syntax=20
        defined for the QoSFilterRule derived data type defined in=20
        [RFC3588], Section 4.3.  Note that this definition contained=20
        an error, so that the complete syntax is described in the=20
        definition of the QoS-Filter-Rule AVP, defined in [NASREQ].=20
      =20
        The RADIUS server can return multiple QoS-Filter-Rule=20
        attributes in an Access-Accept or CoA-Request packet. Where=20
        more than one QoS-Filter-Rule Rule attribute is included, it
        is assumed that the attributes are to be concatenated to form
        a single QOS filter.=20
=20
        Whereas the maximum allowable AVP size in [NASREQ] is greater
        than RADIUS' maximum allowable attribute size, it is assumed
        that QOS filters that exceed RADIUS' allowable attribute size
        will be broken into multiple QoS-Filter-Rule attributes by=20
        the RADIUS server and concatenated back into a single QOS
        filter by the NAS.
 =20
        As per the requirements of RFC 2865, Section 2.3, if multiple=20
        QoS-Filter-Rule attributes are contained within an Access-
        Request or Access-Accept packet, they MUST be maintained in=20
        order. The attributes MUST be consecutive attributes in the=20
        packet. RADIUS proxies MUST NOT reorder QoS-Filter-Rule=20
        attributes.=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 27 Sep 2005 13:36:46 +0000
Date: Tue, 27 Sep 2005 06:35:56 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Re: FW: I-D ACTION:draft-salowey-radext-delegated-prefix-00.txt

Some questions:

a. Based on the introduction is the below a description of which 
messages this attribute can be included in?

   Request Accept Reject Challenge Accounting  #  Attribute
                                   Request
   0+      0+     0      0         0+         TBD  Delegated-IPv6-Prefix

b.  In Section 1, it states:

"  the prefix in
   a Framed-IPv6-Prefix attribute can be assigned to a link to which the
   NAS is attached, and subsequently advertised through Router
   Advertisement messages [3]."

Control over what is advertised is controlled by Framed-Routing and 
Framed-IPv6-Route, not Framed-IPv6-Prefix, right?

For example, in [RFC2865] Section 5.10 (Framed-Routing):

"     This Attribute indicates the routing method for the user, when the
      user is a router to a network.  It is only used in Access-Accept
      packets."

On Mon, 26 Sep 2005, Salowey, Joe wrote:

> 
> > ---------- Forwarded message ----------
> > From: [email-masked] <[email-masked]>
> > Date: Sep 22, 2005 3:50 PM
> > Subject: I-D ACTION:draft-salowey-radext-delegated-prefix-00.txt
> > To: [email-masked]
> > 
> > 
> > A New Internet-Draft is available from the on-line 
> > Internet-Drafts directories.
> > 
> > 
> >         Title           : RADIUS Delegated-IPv6-Prefix Attribute
> >         Author(s)       : J. Salowey, R. Droms
> >         Filename        : draft-salowey-radext-delegated-prefix-00.txt
> >         Pages           : 6
> >         Date            : 2205-9-22
> > 
> >    The Delegated-IPv6-Prefix attribute indicates an IPv6 
> > prefix that is
> >    to be delegated to the user.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 26 Sep 2005 17:08:44 +0000
content-class: urn:content-classes:message
Subject: FW: I-D ACTION:draft-salowey-radext-delegated-prefix-00.txt
Date: Mon, 26 Sep 2005 10:13:27 -0700
From: "Salowey, Joe" <[email-masked]>
To: <[email-masked]>
Cc: "Droms, Ralph" <[email-masked]>

> ---------- Forwarded message ----------
> From: [email-masked] <[email-masked]>
> Date: Sep 22, 2005 3:50 PM
> Subject: I-D ACTION:draft-salowey-radext-delegated-prefix-00.txt
> To: [email-masked]
>=20
>=20
> A New Internet-Draft is available from the on-line=20
> Internet-Drafts directories.
>=20
>=20
>         Title           : RADIUS Delegated-IPv6-Prefix Attribute
>         Author(s)       : J. Salowey, R. Droms
>         Filename        : draft-salowey-radext-delegated-prefix-00.txt
>         Pages           : 6
>         Date            : 2205-9-22
>=20
>    The Delegated-IPv6-Prefix attribute indicates an IPv6=20
> prefix that is
>    to be delegated to the user.
>=20
> A URL for this Internet-Draft is:
>
http://www.ietf.org/internet-drafts/draft-salowey-radext-delegated-prefi
x-00.txt
>=20
> To remove yourself from the I-D Announcement list, send a=20
> message to [email-masked] with the word=20
> unsubscribe in the body of the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>=20
>=20
> Internet-Drafts are also available by anonymous FTP. Login=20
> with the username "anonymous" and a password of your e-mail=20
> address. After logging in, type "cd internet-drafts" and then
>         "get draft-salowey-radext-delegated-prefix-00.txt".
>=20
> A list of Internet-Drafts directories can be found in=20
> http://www.ietf.org/shadow.html or=20
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>=20
>=20
> Internet-Drafts can also be obtained by e-mail.
>=20
> Send a message to:
>         [email-masked].
> In the body type:
>         "FILE=20
> /internet-drafts/draft-salowey-radext-delegated-prefix-00.txt".
>=20
> NOTE:   The mail server at ietf.org can return the document in
>         MIME-encoded form by using the "mpack" utility.  To use this
>         feature, insert the command "ENCODING mime" before the "FILE"
>         command.  To decode the response(s), you will need=20
> "munpack" or
>         a MIME-compliant mail reader.  Different=20
> MIME-compliant mail readers
>         exhibit different behavior, especially when dealing with
>         "multipart" MIME messages (i.e. documents which have=20
> been split
>         up into multiple messages), so check your local=20
> documentation on
>         how to manipulate these messages.
>=20
>=20
> Below is the data which will enable a MIME compliant mail=20
> reader implementation to automatically retrieve the ASCII=20
> version of the Internet-Draft.
>=20
>=20
>=20
>=20
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/i-d-announce
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 26 Sep 2005 15:43:12 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue 102: NAS/QoS Filter Rule
Date: Mon, 26 Sep 2005 18:42:42 +0300
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>

[email-masked] wrote:

> Since these rules govern access policies, it is believed that a
> strong hammer is better than simply ignoring things that aren't
> understood or implemented.  These should apply equally for
> permit rules or deny rules.  If the NAS can't interpret the
> rule, it can't enforce the desired policy either and still MUST
> terminate the session, so if it gets lost parsing things, this
> rule should also apply.

I agree.

> I agree that we need to make sure parsing is unambiguous. =20
> I suppose we need a line feed at the end of each rule and=20
> perhaps this needs to be escaped as well for the=20
> tunnel-assignment-ID issue.

Yes, I also think that having an unambiguous "rule end" (or "rule
separator") character (LF, NUL, or something) would simplify the
parsing... It would be even nicer if the escape mechanism for
tunnel-assignment-ID would "hide" these characters somehow.

Perhaps we should use "percent-hex-hex" escaping like URIs?
(e.g. NUL would turn to "%00", not backslash+NUL).

Best regards
Pasi

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 26 Sep 2005 15:32:44 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue 102: NAS/QoS Filter Rule
Date: Mon, 26 Sep 2005 08:32:25 -0700
From: "Congdon, Paul T (ProCurve)" <[email-masked]>
To: <[email-masked]>, <[email-masked]>

On the last point...
=20
> > 13) If the NAS just concatenates all the NAS-Filter-Rule (or
> > QoS-Filter-Rule) attributes together to overcome the 255-byte=20
> > attribute length limit, then boundaries between individual=20
> rules are=20
> > lost. This is not necessarily a big problem, as it looks like the=20
> > syntax can be unambiguously parsed anyway, but should be mentioned=20
> > explicitly (alternatively, we could delimit the individual rules=20
> > somehow).
> >=20
> > [pc] yes, this should not be a problem and implementations=20
> will split=20
> > the string in different ways, but if they are following the=20
> rules of=20
> > fragmentation and reassembly properly there is no issue.  We really=20
> > don't need to say anything here as this is part of standard=20
> attribute=20
> > parsing.  No action proposed.
>=20
> There would be an issue if the grammar allowed ambiguous parsings.
> For instance, if we had ICMP types "no" and "notunnel" (which=20
> we don't), the following string could be parsed in two=20
> different ways (where exactly does the first rule end and=20
> second rule start?)
>=20
>   "deny in 1 from assigned to any icmptypes source quench,notunnel
>   permit in ip from assigned to any"
>=20
> I don't think we have any such cases currently (running the=20
> grammar through some kind of parser generator tool might=20
> verify this...), but it means that extending the syntax later=20
> has to be done with great care.
>=20
> It also means that saying "A NAS that is unable to interpret=20
> or apply a deny rule MUST terminate the session" is probably=20
> a bad idea, since it seems to imply that ignoring a "permit"=20
> rule the NAS cannot interpret is allowed... but if the NAS=20
> cannot interpret the rule, it cannot really know where one=20
> rule ends and the next rule starts.
>=20
> Best regards,
> Pasi

Since these rules govern access policies, it is believed that a strong
hammer is better than simply ignoring things that aren't understood or
implemented.  These should apply equally for permit rules or deny rules.
If the NAS can't interpret the rule, it can't enforce the desired policy
either and still MUST terminate the session, so if it gets lost parsing
things, this rule should also apply.=20

I agree that we need to make sure parsing is unambiguous.  I suppose we
need a line feed at the end of each rule and perhaps this needs to be
escaped as well for the tunnel-assignment-ID issue.

Paul
=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 26 Sep 2005 14:45:55 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue 102: NAS/QoS Filter Rule
Date: Mon, 26 Sep 2005 17:45:06 +0300
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>

[email-masked] wrote:

> [pc] We can insert this if we can complete the TODO parts
> above.  Do we insert it before the current description or
> completely replace what is there with just the ABNF?  I'm
> assuming this would be inserted in front of the current
> descriptions and we would leave the existing text with fixes
> discussed below.  Can you help complete the TODOs or provide a
> good reference guide on ABNF somewhere?

Whatever we do, we should avoid having multiple descriptions that=20
are in conflict with each other (currently we have two, and they=20
don't completely match).

ABNF is described in RFC 2234.

> 4) Description of "ipno/bits" says "the IP number MUST NOT have
> bits set beyond the mask", but the example given, "1.2.3.4/24",
> does not follow this. Suggested change: use 192.0.2.0/24 as the
> example.
>=20
> [pc] accept suggestion, maybe change the first 0 to something=20
> else to further disambiguate.

No, we should use 192.0.2.0/24 since it's the block reserved
for documentation use (RFC 3330).

> 8) The document allows an IP tunnel rule with direction "out",
> but does not describe what such a rule means (the description
> seems to apply only to rules with direction "in")
>=20
> [pc] Avi has written a great description of how the tunnel facility
> works and how the directions apply.  I've attached a version of this
> document - perhaps Avi has something more recent?  We probably want to
> consider how parts of his document are incorporated into an annex or
> some part of the document to make this clear.

Thanks, this explained things (but something along those lines
needs to be included in the document).

> 10) The document should explain why different types of rules
> must be given in exactly that order. Placing L2 rules before IP
> is understandable, but for some of the other cases it's not
> totally obvious why other orderings need to be forbidden.
>=20
> [pc] We had considerable discussion about this early on in the
> document development.  If my memory serves me correctly, we
> decided upon this order to maximize interoperability and to
> address the fact that it didn't make sense to filter out
> packets before putting them into the tunnel.  Perhaps others
> can recall more detail - sorry.

Well, I think it could make sense in theory (e.g., first filter out
some bad traffic using "deny" rules, then put all the rest to a
tunnel)... but I'm OK with leaving in these restrictions.

> 13) If the NAS just concatenates all the NAS-Filter-Rule (or
> QoS-Filter-Rule) attributes together to overcome the 255-byte
> attribute length limit, then boundaries between individual
> rules are lost. This is not necessarily a big problem, as it
> looks like the syntax can be unambiguously parsed anyway, but
> should be mentioned explicitly (alternatively, we could delimit
> the individual rules somehow).
>=20
> [pc] yes, this should not be a problem and implementations will
> split the string in different ways, but if they are following
> the rules of fragmentation and reassembly properly there is no
> issue.  We really don't need to say anything here as this is
> part of standard attribute parsing.  No action proposed.

There would be an issue if the grammar allowed ambiguous parsings.
For instance, if we had ICMP types "no" and "notunnel" (which we
don't), the following string could be parsed in two different ways
(where exactly does the first rule end and second rule start?)

  "deny in 1 from assigned to any icmptypes source quench,notunnel=20
  permit in ip from assigned to any"

I don't think we have any such cases currently (running the grammar
through some kind of parser generator tool might verify this...),=20
but it means that extending the syntax later has to be done with=20
great care.

It also means that saying "A NAS that is unable to interpret or apply
a deny rule MUST terminate the session" is probably a bad idea, since
it seems to imply that ignoring a "permit" rule the NAS cannot
interpret is allowed... but if the NAS cannot interpret the rule,=20
it cannot really know where one rule ends and the next rule starts.

Best regards,
Pasi

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 23 Sep 2005 22:04:44 +0000
Content-class: urn:content-classes:message
Subject: FW: Issue 102: NAS/QoS Filter Rule
Date: Fri, 23 Sep 2005 15:04:13 -0700
From: "Congdon, Paul T (ProCurve)" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C5C08A.BCBAE846
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

[pc] Comments on Pasi's issue 102...

1) Section 3.5 is currently quite difficult to follow since it mixes L2,
IP, tunneling and HTTP redirect rules... It's not always even clear when
some element is just a name for a rule (like "ipno") and when it's a
literal string (like "from"). =20
So some editing work is needed here. Maybe describing the L2, IP
filtering, IP tunneling and HTTP rules one-by-one (instead of mixing
their descriptions) would make this more understandable.

(The IPFilterRule description in RFC3588 isn't nearly as complicated as
this, since it doesn't have the L2, tunneling or HTTP rules.)

[pc] ok, assuming the rest of the discussion addresses this first point.

2) Or would using ABNF be of any help? Here's a first sketch (probably
buggy..)
      =20
   rule           =3D  flush-rule /
                     l2-filter-rule /=20
                     ip-filter-rule /=20
                     ip-tunnel-rule /
                     http-redirect-rule=20

   flush-rule     =3D  "flush"

   l2-filter-rule =3D  ("permit" / "deny") " " ("in" / "out" / "inout")=20
                     " " l2-filter [" Cnt"]
   l2-filter      =3D  l2-proto " from " l2-address " to " l2-address
   l2-filter      =3D/ l2-rmon-str
   l2-proto       =3D  "l2:ether2" [":0x" 1*4HEXDIG]  =20
   l2-rmon-str    =3D  "l2:" 1*DIGIT *("." 1*DIGIT)
   l2-address     =3D  ["!"] (macaddr / (macaddr "/" mask) / "any")
   macaddr        =3D  2HEXDIG 5("-" 2HEXDIG)
   mask           =3D  1*2DIGIT

   ip-filter-rule =3D  ("permit" / "deny") " " ("in" / "out" / "inout")=20
                     " " ip-filter
   ip-filter      =3D  ("ip" / ip-proto)=20
                     " from " ip-address [" " ip-ports]
                     " to " ip-address [" " ip-ports]
                     *(" " ip-option)
   ip-proto       =3D  1*3DIGIT
   ip-address     =3D  ["!"] (ipv4-address ["/" bits] /=20
                            ipv6-address ["/" bits] /
                            "any" /=20
                            "assigned")=20
   ipv4-address   =3D 1*3DIGIT 3("." 1*3DIGIT)
   ipv6-address   =3D ;; TODO
   bits           =3D  1*3DIGIT
   ip-ports       =3D  ip-port *("," ip-port)
   ip-port        =3D  1*5DIGIT / (1*5DIGIT "-" 1*5DIGIT)

   ip-option      =3D  "Cnt"
   ip-option      =3D  "frag"
   ip-option      =3D/ "ipoptions " ["!"] ipopt *("," ["!"] ipopt)
   ip-option      =3D/ "tcpoptions " ["!"] tcpopt *("," ["!"] tcpopt)
   ip-option      =3D/ "established"
   ip-option      =3D/ "setup"
   ip-option      =3D/ "tcpflags " ["!"] tcpflag *("," ["!"] tcpflag)
   ip-option      =3D/ "icmptypes " icmptype *("," icmptype)

   ipopt          =3D  "ssrr" / "lsrr" / "rr" / "ts"
   tcpopt         =3D  "mss" / "window" / "sack" / "ts" / "cc"
   tcpflag        =3D  "fin" / "syn" / "rst" / "psh" / "ack" / "urg"
   icmptype       =3D  1*3DIGIT
   icmptype       =3D/ 1*3DIGIT "-" 1*3DIGIT
   icmptype       =3D/ ;; TODO (names)

   ip-tunnel-rule =3D  "tunnel " tunnel-id " in " ip-filter
   tunnel-id      =3D  ;; TODO

   http-redirect-rule =3D  "redirect " [redir-cnt " "]=20
                     redir-url " in " ip-filter
   redir-cnt      =3D  1*DIGIT
   redir-url      =3D  ;; TODO

(Ok, maybe this is not so clear either... but at least it's unambiguous
when something is just a rule name and when it's a literal string )

[pc] We can insert this if we can complete the TODO parts above.  Do we
insert it before the current description or completely replace what is
there with just the ABNF?  I'm assuming this would be inserted in front
of the current descriptions and we would leave the existing text with
fixes discussed below.  Can you help complete the TODOs or provide a
good reference guide on ABNF somewhere?

3) Example of "macaddr/mask": The example should use some other width
than /24 to make it clearer how the counting works. Also, the example
given is an invalid one, since it does not meet the "The MAC address
MUST NOT have bits set beyond the mask"
requirement. Suggested change: use 00-10-A4-23-00-00/32 as the example.

[pc] accept suggestion

4) Description of "ipno/bits" says "the IP number MUST NOT have bits set
beyond the mask", but the example given, "1.2.3.4/24", does not follow
this. Suggested change: use 192.0.2.0/24 as the example.

[pc] accept suggestion, maybe change the first 0 to something else to
further disambiguate.

5) Description of tunnel_id: according to RFC 2868, there are no
restrictions on the format of the Tunnel-Assignment-ID.
Currently it's not clear if the NAS-Filter-Rule syntax supports
correctly parsing arbitrary IDs (what happens if the ID includes spaces,
for instance?)

[pc] Good observation.  This needs fixing.  Seems like we have two
choices; put restrictions on the usage of Tunnel-Assignment-ID so that
the strings are parse-able (not really a good idea), or encapsulate the
string in quotes when used in the rule.  Since there are no restrictions
on the format of the string used in Tunnel-Assignment-ID we MUST provide
a way to parse it as a single element in the entire attribute string.
Of course, the Tunnel-Assignment-ID could itself contain quotes, so we
will also need to describe some escaping function before including them
in the rule.  The escaping function would be: For all occurrence of "
replace with \" and for all occurrence of \ replace with \\.  While this
is a little ugly, I think it is the only course of action.=20

6) Near the end of Section 3.5: The "concise syntax statements"
don't exactly match the definitions earlier. I catched at least these:

- IP rule is missing "[ports]" before "to"
- IP rule is missing "|" after "redirect"
- HTTP redirect rule is missing the "proto" part after the direction
- HTTP redirect rule does not have "[ports]"

[pc] agreed, fix these and double check the rest..

7) The document does not seem to describe what HTTP filter rules are or
how they work (HTTP redirect rules are explained, but not HTTP filter
rules).

[pc] There really aren't specific HTTP filter rules per-se.  We don't
filter based upon HTTP content, but it is possible to filter all HTTP
traffic using normal IP filter rules.  The text is a little unclear at
the end of the section that indicates there are 'redirect' and 'filter'
rules.  Seems like we need to discuss redirect rules separately from
filter rules.  There are really two types of redirect rules; tunnel and
http, and two filter rules; L2 and IP.
 =20
8) The document allows an IP tunnel rule with direction "out", but does
not describe what such a rule means (the description seems to apply only
to rules with direction "in")

[pc] Avi has written a great description of how the tunnel facility
works and how the directions apply.  I've attached a version of this
document - perhaps Avi has something more recent?  We probably want to
consider how parts of his document are incorporated into an annex or
some part of the document to make this clear.

9) Currently the text says "A flush rule MUST appear before all other
rule types." I first read this to mean that a flush rule must always be
present, but I guess that was not what was meant. Furthermore, it's not
easy to parse the ordering requirements.

Suggested change: Rewrite that paragraph to "Furthermore, if the list
contains different types of rules, they MUST appear in the following
order: flush rules, base encapsulation filter rules, IP tunnel rules,
HTTP redirect rules, IP filter rules, and HTTP filter rules."

[pc] Agreed. This is better than my suggestion to change this part of
the text to, "Base encapsulation filter rules MUST appear after a flush
rule (if present) and before IP tunnel,..."=20

10) The document should explain why different types of rules must be
given in exactly that order. Placing L2 rules before IP is
understandable, but for some of the other cases it's not totally obvious
why other orderings need to be forbidden.

[pc] We had considerable discussion about this early on in the document
development.  If my memory serves me correctly, we decided upon this
order to maximize interoperability and to address the fact that it
didn't make sense to filter out packets before putting them into the
tunnel.  Perhaps others can recall more detail - sorry.

11) The document should have some examples of NAS filter rules,
preferably showing most of the different features at least once.

[pc] agreed.

12) The document should somewhere describe the differences to Diameter's
NAS-Filter-Rule syntax.

[pc] agreed this relates to Bernard's comment as well.  Text to be
developed.

13) If the NAS just concatenates all the NAS-Filter-Rule (or
QoS-Filter-Rule) attributes together to overcome the 255-byte attribute
length limit, then boundaries between individual rules are lost. This is
not necessarily a big problem, as it looks like the syntax can be
unambiguously parsed anyway, but should be mentioned explicitly
(alternatively, we could delimit the individual rules somehow).

[pc] yes, this should not be a problem and implementations will split
the string in different ways, but if they are following the rules of
fragmentation and reassembly properly there is no issue.  We really
don't need to say anything here as this is part of standard attribute
parsing.  No action proposed.

------_=_NextPart_001_01C5C08A.BCBAE846
Content-Type: text/plain;
	name="Tunneling.txt"
Content-Transfer-Encoding: base64
Content-Description: Tunneling.txt
Content-Disposition: attachment;
	filename="Tunneling.txt"

------_=_NextPart_001_01C5C08A.BCBAE846--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 23 Sep 2005 21:04:24 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue 113: Attribute Concatenation
Date: Fri, 23 Sep 2005 14:02:52 -0700
From: "Congdon, Paul T (ProCurve)" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

=20
> ...
>=20
> >> Actually, Diameter AVPs can be larger than a RADIUS _message_.  If=20
> >> you really want to support fragmentation and reassembly in the=20
> >> general sense, then you need to deal with that, too.
> >>=20
> >=20
> > I probably should have been more clear about using the=20
> words 'general=20
> > sense'.  All we are talking about is the string in the=20
> Qos-Filter-Rule=20
> > that might be too large to fit in the current Radius version of the=20
> > attribute.  I am under the assumption that handling this type of=20
> > scenario is common practice in Radius/Diameter proxies and=20
> that is has=20
> > been documented in a previous RFC, but perhaps I'm
> > wrong on this.  =20
>=20
> OK, I'm a bit confused here: is this Qos-Filter-Rule=20
> generated by a RADIUS server, a Diameter peer or either?
>

It is generated by a RADIUS server and is a RADIUS attribute.  We are
simply leveraging the format and syntax of the rule string.
  =20
> >=20
> > I still think the existing text explains the issue and=20
> solution fairly
> > clearly:
> >=20
> >          The Text field contains a QoS filter, utilizing the syntax
> >          defined for the QoSFilterRule derived data type defined in
> >          [RFC3588], Section 4.3.  Note that this definition=20
> contained=20
> > an
> >=20
> >          error, so that the complete syntax is described in the
> >          definition of the QoS-Filter-Rule AVP, defined in [NASREQ].
> >=20
> >          The RADIUS server can return multiple QoS-Filter-Rule
> >          attributes in an Access-Accept or CoA-Request packet. Where
> >          more than one QoS-Filter-Rule Rule attribute is=20
> included, it=20
> > is
> >=20
> >          assumed that the attributes are to be concatenated=20
> to form a
> >          single QOS filter.
> >=20
> >          Whereas the maximum allowable message size in [NASREQ] is
> >          greater than RADIUS' maximum allowable message size, it is
> >          assumed that QOS filters that exceed RADIUS' allowable
> >          message size will be broken into multiple QoS-Filter-Rule=20
> > attributes by
> >=20
> >          the RADIUS server and concatenated back into a single QOS
> >          filter by the NAS.
>=20
> But this makes no sense to me at all.  Do you mean "Whereas=20
> the maximum allowable AVP size in [NASREQ] is greater than=20
> RADIUS' maximum allowable attribute size, it is assumed that=20
> QOS filters that exceed RADIUS' allowable attribute size will=20
> be broken into multiple QoS-Filter-Rule attributes by the=20
> RADIUS server and concatenated back into a single QOS filter=20
> by the NAS"?
>=20

Yes.  We can use this text as a replacement if you agree with this.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 23 Sep 2005 14:52:18 +0000
Date: Fri, 23 Sep 2005 07:51:51 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Internet-Drafts Submission Cutoff Dates for the 64th IETF Meeting in Vancouver, British Columbia, Canada  (fwd)

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of
[email-masked]
Sent: Friday, September 23, 2005 06:00
To: [email-masked]
Subject: Internet-Drafts Submission Cutoff Dates for the 64th IETF
Meeting in Vancouver, British Columbia, Canada 

There are two (2) Internet-Draft cutoff dates for the 64th 
IETF Meeting in Vancouver, British Columbia, Canada:

October 17th: Cutoff Date for Initial (i.e., version -00) 
Internet-Draft Submissions 

All initial Internet-Drafts (version -00) must be submitted by Monday, 
October 17th at 9:00 AM ET. As always, all initial submissions with a 
filename beginning with "draft-ietf" must be approved by the 
appropriate WG Chair before they can be processed or announced.  The 
Secretariat would appreciate receiving WG Chair approval by Monday, 
October 10th at 9:00 AM ET.

October 24th: Cutoff Date for Revised (i.e., version -01 and higher) 
Internet-Draft Submissions 

All revised Internet-Drafts (version -01 and higher) must be submitted 
by Monday, October 24th at 9:00 AM ET.

Initial and revised Internet-Drafts received after their respective 
cutoff dates will not be made available in the Internet-Drafts 
directory or announced until on or after Monday, November 7th at 9:00 
AM ET, when Internet-Draft posting resumes.  Please do not wait until 
the last minute to submit.

Thank you for your understanding and cooperation. If you have any 
questions or concerns, then please send a message to 
[email-masked].

The IETF Secretariat

FYI: The Internet-Draft cutoff dates as well as other significant dates
for the 64th IETF Meeting can be found at http://www.ietf.org/meetings/cutoff_dates_64.html.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 23 Sep 2005 13:28:28 +0000
Date: Fri, 23 Sep 2005 16:27:46 +0300
From: Miguel Garcia <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: "Beck01, Wolfgang" <[email-masked]>, [email-masked]
Subject: Re: AW: AW: AW: Digest Authentication: Security issue with https/sips

Bernard Aboba wrote:

>>Consider the following proposal (section RADIUS client behaviour):
>>"If the scheme in the digest-uri directive indicates a secure HTTP-style
>>connection (eg sips, https) and the RADIUS client does not have a secure
>>connection to its RADIUS server, it MUST act as if it had received an
>>Access-Reject."
>>
>>Less comprehensible, but no normative statement for SIP or HTTP.
> 
> 
> How can the RADIUS client act like it received an Access-Reject before 
> even sending an Access-Request?

Presumably it refers to the fact that the RADIUS client could take the 
same local actions that it will take when it receives an 
Access-Reject... namely, inform the SIP/HTTP server about it.

But I still disagree with the fact under discussion: first, the lack of 
encryption of the RADIUS interface puts a penalty to the users that are 
tring just to encrypt the communication. This IMHO deviates from the 
main point of using a secure URI (sips, https).

/Miguel

-- 
Miguel A. Garcia           tel:+358-50-4804586
sip:[email-masked]
Nokia Research Center      Helsinki, Finland

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 23 Sep 2005 13:12:11 +0000
Date: Fri, 23 Sep 2005 06:11:51 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: "Beck01, Wolfgang" <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: AW: AW: AW: Digest Authentication: Security issue with https/sips

> Consider the following proposal (section RADIUS client behaviour):
> "If the scheme in the digest-uri directive indicates a secure HTTP-style
> connection (eg sips, https) and the RADIUS client does not have a secure
> connection to its RADIUS server, it MUST act as if it had received an
> Access-Reject."
> 
> Less comprehensible, but no normative statement for SIP or HTTP.

How can the RADIUS client act like it received an Access-Reject before 
even sending an Access-Request?

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 23 Sep 2005 08:06:33 +0000
Date: Fri, 23 Sep 2005 11:06:19 +0300
From: Miguel Garcia <[email-masked]>
To: "Beck01, Wolfgang" <[email-masked]>
CC: [email-masked]
Subject: Re: AW: AW: AW: Digest Authentication: Security issue with https/sips

Beck01, Wolfgang wrote:

> Miguel,
> 
> 
>>So if A calls B, it is only A's network that can authenticate and 
>>authorize A's call. If A uses a SIPS URI to address B, it 
>>just want to have secured signalling connection betweeen A and B, and does 
>>not care  about the sortages of A's network and not protecting the 
>>RADIUS interface.
> 
> But A's RADIUS connection is part of the signalling connection
> between A and B.

[Miguel]
Ok, so here is our point of disagreement. I think you cannot consider 
the RADIUS interface as part of the signalling connection between A and 
B. The RADIUS server is just there to provide an authorization, but is 
not part of the signalling path. So putting a penalty to the end user is 
wrong in my opinion, and prevents the user to establish a secure 
connection just because the inability of the network.

> 
> 
>>And then we come to the normative statements that you are placing for 
>>HTTP and SIP, I don't think it is valid for a RADIUS document 
>>to contain such statements. The WG that deal with those protocols should 
>>attack the problem and extend the protocol, if needed.
>>
> 
> 
> Consider the following proposal (section RADIUS client behaviour):
> "If the scheme in the digest-uri directive indicates a secure HTTP-style
> connection (eg sips, https) and the RADIUS client does not have a secure
> connection to its RADIUS server, it MUST act as if it had received an
> Access-Reject."
> 
> Less comprehensible, but no normative statement for SIP or HTTP.

[Miguel]

Ok, this part would be more acceptable, but we need to solve the first 
part of the draft, for which I don't agree yet.

BR,

      Miguel

> 
> 
> Wolfgang
> 
> --
> T-Systems
> Next Generation IP Services and Systems
> +49 6151 937 2863
> Am Kavalleriesand 3
> 64295 Darmstadt
> Germany 
> 
> 

-- 
Miguel A. Garcia           tel:+358-50-4804586
sip:[email-masked]
Nokia Research Center      Helsinki, Finland

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 23 Sep 2005 07:22:50 +0000
From: "Beck01, Wolfgang" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: AW: AW: AW: Digest Authentication: Security issue with https/sips
Date: Fri, 23 Sep 2005 09:22:01 +0200

Miguel,

> So if A calls B, it is only A's network that can authenticate and 
> authorize A's call. If A uses a SIPS URI to address B, it 
> just want to have secured signalling connection betweeen A and B, and does 
> not care  about the sortages of A's network and not protecting the 
> RADIUS interface.
But A's RADIUS connection is part of the signalling connection
between A and B.

> 
> And then we come to the normative statements that you are placing for 
> HTTP and SIP, I don't think it is valid for a RADIUS document 
> to contain such statements. The WG that deal with those protocols should 
> attack the problem and extend the protocol, if needed.
> 

Consider the following proposal (section RADIUS client behaviour):
"If the scheme in the digest-uri directive indicates a secure HTTP-style
connection (eg sips, https) and the RADIUS client does not have a secure
connection to its RADIUS server, it MUST act as if it had received an
Access-Reject."

Less comprehensible, but no normative statement for SIP or HTTP.

Wolfgang

--
T-Systems
Next Generation IP Services and Systems
+49 6151 937 2863
Am Kavalleriesand 3
64295 Darmstadt
Germany 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 22 Sep 2005 06:39:35 +0000
Date: Thu, 22 Sep 2005 09:38:20 +0300
From: Miguel Garcia <[email-masked]>
To: "Beck01, Wolfgang" <[email-masked]>
CC: [email-masked]
Subject: Re: AW: AW: Digest Authentication: Security issue with https/sips

Wolfgang:

I sort of disagree with the conclusion. You are focusing on the fact 
that of whether there is TLS/Ipsec at the last mile, which is not my 
point of discussion.

My point of discussion is that if A calls B, I will not expect that B's 
network authenticates A, because typically there won't be any 
relationship between A and B's networks.

So if A calls B, it is only A's network that can authenticate and 
authorize A's call. If A uses a SIPS URI to address B, it just want to 
have secured signalling connection betweeen A and B, and does not care 
about the sortages of A's network and not protecting the RADIUS interface.

If A's proxy rejects a SIPS request because the RADIUS interface is not 
protected, applying the current semantics, it will give user A the idea 
that TLS is not supported in between proxies, or there isn't security 
(IPsec) at the last mile. This is not the case, so you can't hijack this 
type of error for this purpose. And in this case, I don't know how the 
lack of IPsec in RADIUS will have a negative effect in the encryption of 
signalling between A and B.

And then we come to the normative statements that you are placing for 
HTTP and SIP, I don't think it is valid for a RADIUS document to contain 
such statements. The WG that deal with those protocols should attack the 
problem and extend the protocol, if needed.

/Miguel

Beck01, Wolfgang wrote:

> Miguel,
> 
> 
>>Let A call B, so that A sends an INVITE request to B, assume that the 
>>REquest-URI is sip:[email-masked]
>>
>>According to the draft, A's network may want to authenticate the request 
>>to make sure it comes from A and to verify that A is authorized to send 
>>this SIP request.
>>
>>So a SIP proxy in A's network challenges user A and the draft applies.
>>
>>Now assume the same INVITE whereby A wants an encrypted end-to-end 
>>secure communication. So A sends an INVITE request whose Request-URI is 
>>a SIPS URI, like sips:[email-masked]. The only problem is that, if the 
>>RADIUS interface between SIP server (at domain A) and the RADIUS 
>>server (at domain A) is not secured, the request is rejected, giving the 
>>user the sense that it is not possible to have a secure encrypted 
>>signalling connection between A and B. This is not related to the 
>>problem that the RADIUS interface is not secure at A's domain, the user 
>>shouldn't be paying a penalty for this, and the A user shouldn't be 
>>given the false sense that it is not possible to have end-to-end secured 
>>communication at the SIP level.
> 
> RADIUS exposes parts of the request -- like username and URI -- which are
> not exposed in a TLS session. If all SIP hops are encrypted with TLS and B's
> domain uses locally specified security mechanims, your proxy would send username
> and URI unencrypted to the RADIUS server.
> 
> If some intermediary rejects a sips call as it would have to send unencrypted
> information to the RADIUS server, the client has the chance to tell the user
> about this. It could display a message, like "Encryption not supported. Retry unencrypted?"
> 
> As far as I remember, the sentence about "locally specified security mechanisms"
> in the callee's domain was added on request of 3GPP as IPsec is used instead of TLS.
> 
> To summarize:
> Miguel's opinion: The information exposed by unencrypted RADIUS is not important
> enough to justify sips call/https request rejection.
> [correct me if I got it wrong]
> 
> Wolfgang's opinion: sips + unencrypted RADIUS results in partial encryption, which
> is not what users expect.
> 
> 
> Wolfgang
> 
> --
> T-Systems International GmbH
> Systems Integration
> Technologiezentrum
> Engineering Networks, Products & Services
> Next Generation IP Services & Systems
> Am Kavalleriesand 3
> 64295 Darmstadt
> Tel +49 6151 937 2863
> 
> 
> 
> 
> 
> 

-- 
Miguel A. Garcia           tel:+358-50-4804586
sip:[email-masked]
Nokia Research Center      Helsinki, Finland

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 22 Sep 2005 02:42:25 +0000
From: [email-masked]
Content-class: urn:content-classes:message
Subject: RE: Issue 113: Attribute Concatenation
Date: Wed, 21 Sep 2005 19:41:33 -0700
To: "Congdon, Paul T \(ProCurve\)" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

Congdon, Paul T (ProCurve) <mailto:[email-masked]> supposedly =
scribbled:

...

>> Actually, Diameter AVPs can be larger than a RADIUS _message_.  If
>> you really want to support fragmentation and reassembly in the
>> general sense, then you need to deal with that, too.
>>=20
>=20
> I probably should have been more clear about using the words 'general
> sense'.  All we are talking about is the string in the
> Qos-Filter-Rule that might be too large to fit in the current Radius
> version of the attribute.  I am under the assumption that handling
> this type of scenario is common practice in Radius/Diameter proxies
> and that is has been documented in a previous RFC, but perhaps I'm
> wrong on this.  =20

OK, I'm a bit confused here: is this Qos-Filter-Rule generated by a =
RADIUS server, a Diameter peer or either?
 =20
>=20
> I still think the existing text explains the issue and solution fairly
> clearly:
>=20
>          The Text field contains a QoS filter, utilizing the syntax
>          defined for the QoSFilterRule derived data type defined in
>          [RFC3588], Section 4.3.  Note that this definition contained
> an=20
>=20
>          error, so that the complete syntax is described in the
>          definition of the QoS-Filter-Rule AVP, defined in [NASREQ].
>=20
>          The RADIUS server can return multiple QoS-Filter-Rule
>          attributes in an Access-Accept or CoA-Request packet. Where
>          more than one QoS-Filter-Rule Rule attribute is included, it
> is=20
>=20
>          assumed that the attributes are to be concatenated to form a
>          single QOS filter.
>=20
>          Whereas the maximum allowable message size in [NASREQ] is
>          greater than RADIUS' maximum allowable message size, it is
>          assumed that QOS filters that exceed RADIUS' allowable
>          message size will be broken into multiple QoS-Filter-Rule
> attributes by=20
>=20
>          the RADIUS server and concatenated back into a single QOS
>          filter by the NAS.

But this makes no sense to me at all.  Do you mean "Whereas the maximum =
allowable AVP size in [NASREQ] is greater than RADIUS' maximum allowable =
attribute size, it is assumed that QOS filters that exceed RADIUS' =
allowable attribute size will be broken into multiple QoS-Filter-Rule
attributes by the RADIUS server and concatenated back into a single QOS =
filter by the NAS"?

>=20
>          As per the requirements of RFC 2865, Section 2.3, if multiple
>          QoS-Filter-Rule attributes are contained within an Access-
>          Request or Access-Accept packet, they MUST be maintained in
>          order. The attributes MUST be consecutive attributes in the
>          packet. RADIUS proxies MUST NOT reorder QoS-Filter-Rule
>          attributes.

~gwz

Why is it that most of the world's problems can't be solved by simply
  listening to John Coltrane? -- Henry Gabriel

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 21 Sep 2005 21:37:37 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue 113: Attribute Concatenation
Date: Wed, 21 Sep 2005 14:36:40 -0700
From: "Congdon, Paul T (ProCurve)" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

>=20
> > Responding to Greg's issue 113...
> >=20
> >> I didn't understand how the language in section 3.6 about=20
> >> concatenating
> >=20
> >> QoS-Filter-Rule(s) works.  If these are simply=20
> concatenated, how does=20
> >> an implementation distinguish between multiple 'small'
> >> QoS-Filter-Rules
> >=20
> >> and a single larger attribute?  What if I want to send one=20
> >> QoS-Filter-Rule which spans 253, followed by one which does not?
> >=20
> > Actually I believe the editorial note needs to be removed=20
> since there=20
> > is text just after the note that explains the problem.  As=20
> you know,=20
> > Diameter attributes may be larger than what will fit in the Radius=20
> > attribute so we need to support fragmentation and reassembly in the=20
> > general sense.
>=20
> Actually, Diameter AVPs can be larger than a RADIUS=20
> _message_.  If you really want to support fragmentation and=20
> reassembly in the general sense, then you need to deal with that, too.
>=20

I probably should have been more clear about using the words 'general
sense'.  All we are talking about is the string in the Qos-Filter-Rule
that might be too large to fit in the current Radius version of the
attribute.  I am under the assumption that handling this type of
scenario is common practice in Radius/Diameter proxies and that is has
been documented in a previous RFC, but perhaps I'm wrong on this.

I still think the existing text explains the issue and solution fairly
clearly:

         The Text field contains a QoS filter, utilizing the syntax=20
         defined for the QoSFilterRule derived data type defined in=20
         [RFC3588], Section 4.3.  Note that this definition contained an

         error, so that the complete syntax is described in the=20
         definition of the QoS-Filter-Rule AVP, defined in [NASREQ].=20
     =20
         The RADIUS server can return multiple QoS-Filter-Rule=20
         attributes in an Access-Accept or CoA-Request packet. Where=20
         more than one QoS-Filter-Rule Rule attribute is included, it is

         assumed that the attributes are to be concatenated to form a=20
         single QOS filter.=20
=20
         Whereas the maximum allowable message size in [NASREQ] is=20
         greater than RADIUS' maximum allowable message size, it is=20
         assumed that QOS filters that exceed RADIUS' allowable message=20
         size will be broken into multiple QoS-Filter-Rule attributes by

         the RADIUS server and concatenated back into a single QOS=20
         filter by the NAS.=20
         =20
         As per the requirements of RFC 2865, Section 2.3, if multiple=20
         QoS-Filter-Rule attributes are contained within an Access-
         Request or Access-Accept packet, they MUST be maintained in=20
         order. The attributes MUST be consecutive attributes in the=20
         packet. RADIUS proxies MUST NOT reorder QoS-Filter-Rule=20
         attributes.=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 21 Sep 2005 21:14:20 +0000
Content-class: urn:content-classes:message
Subject: Issue 110: Compliance and Coherence
Date: Wed, 21 Sep 2005 14:10:03 -0700
From: "Congdon, Paul T (ProCurve)" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>

Greg has made the following comment on the 802 attributes draft:

>1) Compliance vs. Functional Coherence
>Most of the RADIUS RFCs tend to address a single functional area, e.g.=20
>IPv6 attributes, EAP, tunneling, etc.  This is good because RFCs tend=20
>to become checkmarks on RFPs or customer requirements.  This documents=20
>seems to combine functionality that is only related to IEEE 802 (VLANs)

>and things that are independent of access type.  For example, filtering

>and redirection can apply equally usefully to PPP-based L2 connections.

>If I'm a vendor of PPPoA-based DSL termination NASes, I can't claim=20
>compliance to this potential RFC unless I support all the VLAN oriented

>attributes because the compliance language in section 1.2 requires an=20
>all or nothing approach to compliance.  Can the authors clarify why the

>NAS-Filter-Rule/QoS-Filter-Rule attributes are combined with the 802=20
>specific attributes?
>
>I would think these should be addressed via separate documents.

Throughout the history of this document we have included, excluded,
added and removed various attributes to get the scope of the document
just right.   We have been balancing the tradeoff of getting a
reasonable focused set of attributes in a single document without
creating a slew of attribute documents to run through the process.
Also, we are addressing the needs and requests of other SDOs for
completing the work on this set of attributes in a timely manner.

I believe we can (and perhaps have) address the issue of compliance to
the spec by indicating in the front matter how NAS devices that do not
support media that provides the functionality controlled by the
attributes in the spec are supposed to behave.  We already have
statements in the spec (section 2.2) that say if you can't support the
functionality requested by the attributes you MUST treat an
Access-Accept as an Reject.  This should be sufficient to allow non VLAN
devices to use this spec and still create an environment with
predictable behavior.

Paul

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 21 Sep 2005 20:57:08 +0000
From: [email-masked]
Content-class: urn:content-classes:message
Subject: RE: Issue 113: Attribute Concatenation
Date: Wed, 21 Sep 2005 13:56:57 -0700
To: "Congdon, Paul T \(ProCurve\)" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Congdon, Paul T (ProCurve) <> supposedly scribbled:

> Responding to Greg's issue 113...
>=20
>> I didn't understand how the language in section 3.6 about
>> concatenating=20
>=20
>> QoS-Filter-Rule(s) works.  If these are simply concatenated, how does
>> an implementation distinguish between multiple 'small'
>> QoS-Filter-Rules=20
>=20
>> and a single larger attribute?  What if I want to send one
>> QoS-Filter-Rule which spans 253, followed by one which does not?
>=20
> Actually I believe the editorial note needs to be removed since there
> is text just after the note that explains the problem.  As you know,
> Diameter attributes may be larger than what will fit in the Radius
> attribute so we need to support fragmentation and reassembly in the
> general sense.=20

Actually, Diameter AVPs can be larger than a RADIUS _message_.  If you =
really want to support fragmentation and reassembly in the general =
sense, then you need to deal with that, too.
 =20
>=20
> The assumption with concatenation is that you are building a 'list'
> of QoS-Filter-Rules, just like you are building a 'list' of
> NAS-Filter-Rules.  So, as the text states, if there are multiple
> QoS-Filter-Rules, you simply concatenate them together (whether they
> are multiple little rules or one large split rule) and treat them as
> a 'list'    =20
>=20
> The proposed resolution to this comment is to remove the editorial
> note.=20
> If this is not acceptable, please propose some new text in this
> section which helps clarify things for you - provided I've made that
> clear. =20
>=20
> Thanks,
>=20
> Paul

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by simply
  listening to John Coltrane? -- Henry Gabriel

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 21 Sep 2005 20:36:31 +0000
Date: Wed, 21 Sep 2005 22:35:49 +0200
From: Emile van Bergen <[email-masked]>
To: Avi Lior <[email-masked]>
Cc: Bernard Aboba <[email-masked]>, "Nelson, David" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Capabilities (was Re: AW: Review of draft-ietf-geopriv-radius-lo-04.txt )
Mail-Followup-To: Avi Lior <[email-masked]>, Bernard Aboba <[email-masked]>, "Nelson, David" <[email-masked]>, [email-masked], [email-masked]

Hi,

On Wed, Sep 21, 2005 at 01:04:50PM -0400, Avi Lior wrote:

> See inline..... 

Same.

> > -----Original Message-----
> > From: Emile van Bergen [mailto:[email-masked]] 
> > Sent: Friday, September 09, 2005 7:04 PM
> > To: Avi Lior
> > Cc: Bernard Aboba; Nelson, David; [email-masked]; 
> > [email-masked]
> > Subject: Re: Capabilities (was Re: AW: Review of 
> > draft-ietf-geopriv-radius-lo-04.txt )
> > 
> > Hi,
> > 
> > (Cross posting to GEOPRIV-WG; this discussion pertains to 
> > http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius-
> > lo-04.txt,
> > in particular section 8).
> > 
> > On Fri, Sep 09, 2005 at 04:49:09PM -0400, Avi Lior wrote:
> > 
> > > > The question is why GEOPRIV has decided not to send location by 
> > > > default.
> > > 
> > > Initially we did exactly that we sent the location 
> > information in the 
> > > Access-Request.  But Geopriv being about privacy, was 
> > concerned what 
> > > if the user did not want to have their location exposed.
> > > 
> > > So now we have the case where in some systems, the user's policy of 
> > > whether or not to expose location is stored in the a database and 
> > > during authentication the AAA learns that policy.
> > 
> > Presumably you mean that the NAS learns the user's policy 
> > from the home server, who has access to the user's profile.
> > 
> > I see that your position is in line with that, but I still do 
> > not see the point.
> > 
> > 1. If the home AAA makes access or billing conditional on 
> > Location, the
> >    user's own policy is irrelevant; the home AAA will only 
> > list the user
> >    in his database if the user agrees with his location being
> >    transmitted to the home AAA. 
> 
> It could do that but it may also limit what it authorizes the user to do
> if the user doesn't agree to location,
> 
> > 
> >    So if that is the case, if the home AAA doesn't see Location in a
> >    request without State, it challenges. If it sees no Location in a
> >    request with State, it rejects. 
> 
> See above comment.
>  
> >    Advertising the positive case (NAS supports GEOPRIV and will send
> >    Location when challenged) in the access request does not 
> > prevent the
> >    challenge.
> > 
> >    Advertising the negative case (NAS supports GEOPRIV but 
> > will not send
> >    Location when challenged) will prevent the challenge and allow the
> >    home AAA to send a reject immediately. 
> 
> Reject or Accept with limited access etc....
> 
> >    But that's a corner case that seems hardly worth dealing 
> > with. You'll
> >    either have a NAS that supports it and needs a challenge, or a
> >    pre-GEOPRIV NAS that won't do any negative GEOPRIV-advertising
> >    either.
> 
> I don't follow/understand the "negative case"

Ok, let me try and explain it better.

1. The positive case is where the NAS advertises that it WILL send
Location when asked for it. 

The server will need to send a challenge to tell the NAS that the user
allows Location to be sent. This is required by GEOPRIV; Location may
not be sent in the first access request, because Location may only be
sent if the NAS knows that the user's privacy policy allows it. 

If the only interface between users database and NAS is RADIUS, and it
does not seem reasonable to build two parallel interfaces if we're
specifically creating support for all this in RADIUS, then the only way
the NAS can learn about that policy is a RADIUS response (in practice, a
challenge or an accept).

2. The negative case is where the NAS advertises that it WILL NOT send
Location. 

The server may then skip the challenge step and proceed to accept,
accept with reduced authorization, or reject immediately. The server may
also do so if it does not care about Location.

3. A third case is where the NAS advertises capabilities in some form,
but does not know anything about Location or GEOPRIV, so it cannot say
that it supports Location, and it cannot say that it does not support
Location.

The server will then have to challenge. This can be avoided if the
capabilties advertising standard says that a server can infer
non-support for a feature if the server sees an advertisement without a
statement about that feature. 

That would mean that a NAS that supports advertising must be required to
advertise EVERYTHING it has support for, otherwise the server cannot
conclude non-support of a feature when the NAS omits it from the
advertisement. That may not be a bad thing for a capabilities
advertising standard to ask (arguably the only thing that would make it
worthwhile), but the current caps. draft doesn't go as far as that.

4. A fourth case is where the NAS does not know how to advertise
capabilities. 

The server will then have to challenge if it cares about Location,
unless it can conclude from the lack of advertisment that Location is
not supported. This can be avoided if the GEOPRIV standard rules that no
GEOPRIV support may exist without capability advertising, which would
allow a server to conclude from the lack of advertisement that GEOPRIV
is not supported.

As you can see, you need to be /very/ careful in defining such things
for maximum convergence, because without convergence, the number of
states raises exponentially for each case you introduce.

> >    Only the home AAA advertising to its upstream the policy that it
> >    needs Location, else don't bother sending an access request, would
> >    prevent the access request and the challenge. But the general idea
> >    with RADIUS is not that home AAA push their policies 
> > downstream, but
> >    that downstream queries upstream in the individual case.
> 
> The RADIUS server pushing their policy to the NAS before the
> access-request is not possible today.

And should not be possible tomorrow, especially not for per-session
policy. That makes no sense. 

I reiterate: the whole idea of RADIUS is offloading policy decisions to
a central place, by asking a server a question before each session
starts. Not by pushing the information needed to make policy decisions
outwards.

Take a look at DNS if publishing stuff is what you want.

> >    In short: if Location is /needed/ by the home AAA, then you need a
> >    Challenge step anyway, a. for the NAS to learn about the user's
> >    policy, and b. for the AAA server to postpone its decision until it
> >    learns the presence or value of Location.
> 
> You miss my point.  If the AAA server requires Location information and
> it knows that the NAS does not support Location information then it will
> not challenge.  It will simply reject or accept based on its local
> policies.

Exactly, and that's immediately the only case where the NEGATIVE
advertisement (does not support) adds something (efficiency).

> If the AAA server requires location information but it does not know
> whether or not the NAS supports location information -- it has no option
> but to challenge for the information.  This is wasteful and worse can
> result in the NAS treating the challenge as a reject and terminating the
> session.

It's does not waste anything compared to the 'normal' case, where the
NAS advertises 'yes, I do support' and then the server challenges for
Location (because the NAS is not allowed to send Location immediately by
the PRIV part of GEOPRIV).

So let's please put the whole efficiency argument aside: even the most
positive case requires a challenge (accept with maximum privileges) if
the server /requires/ Location, so such a server may just as well use a
challenge in the other cases too.

The unintended reject, where a server learning that a NAS does not
support GEOPRIV would rather send a limited accept rather than a
challenge, causing a reject as per RFC2865 4.4 for NASes that do not
support Challenge (or for NASes that don't understand why they are
challenged) is the first sensible argument I hear for GEOPRIV requiring
capabilities advertisements.

> > 2. If Location is optional, and only used for statistics, marketing,
> >    and other shady purposes, then NAS can learn from the access accept
> >    whether the user allows Location to be included in accounting
> >    packets (start, interim and stop).
> 
> Sure....
>     
> >    The access accept could include a dummy Location value in 
> > that case,
> >    and we could have language saying that the NAS MUST NOT 
> > send Location
> >    in accounting unless an empty Location attribute is present in the
> >    access accept.
> 
> Draft-capexchange as proposes a way to signal this. 

True, but I'm arguing the case how GEOPRIV could be done without broad
capabilities advertising.

This is also a bit more specific; it's not about feature support, it's
about the user's privacy policy wrt. Location sending, which possibly
depends on the NAS that's used for that session.

Would you want to use the capabilities exchange to publish the user's
specific GEOPRIV policy for that specific session?

Then the capabilities exchange should be defined as a very loose
signaling mechanism, where the semantics of each capability value is
completely governed by the document describing the capability. 

This rules out the strict modes where the server may conclude
non-support from a default value.

> > In both cases: no advertising needed. Or even helpful.
> 
> I don't agree!!!

OK, I concede that advertising allows servers whose policy REQUIRES
Location for full access to provide more limited access if the user's
policy WOULD allow the sending of Location from that NAS, but Location
is not sent.

The question is whether this, plus the efficiency gain in the case where
the NAS supports challenges but not GEOPRIV, warrants a capability
advertisement feature.

If one could be developed that's generic enough to support both this
case and the "NAS-and-proxies-will-heed-limit-X" case, while being
/extemely/ careful to avoid an explosion of states (see above how easy
this is), then I would agree that it would make sense for GEOPRIV to
require that.

GEOPRIV requiring specific advertisements without a good capability
mechanism already defined and accepted, or an overly broad advertising
mechanism without very clear semantics and well defined convergence of
states is what I object to.

> > > > > But that advertisement is also an extra transaction. What's
> > > > the home
> > > > > AAA supposed to do, keep state from separate 
> > > > > pseudo-authentications that include the advertised 
> > information for 
> > > > > later use? That doesn't sound like RADIUS, at all.
> > > > Right. 
> > > 
> > > Wrong.
> > > 
> > > No the advertizement is not an extra transaction.  It comes in the 
> > > Access-Request.
> > 
> > But if the NAS may only include Location if it learns the 
> > user's policy first, for privacy reason, then telling the NAS 
> > about the user's policy /is/ an extra transaction. You need 
> > that one, too.
> 
> The extra message is required because Geopriv wants to have a mode where
> by the location is not provided automatically.
> So we cant help but using a Challenge. 

Agreed. So I take it you agree that you need the Challenge in all cases
where the server wants Location, and that no amount of advertising up
front will remedy that?

> However, what is being debated is whether it is helpful to have the NAS
> tell the AAA server in the initial Access-Request whether or not the NAS
> supports location information.
> 
> I say it is helpful. Since as I stated above, if the NAS does not
> support location information, then the AAA can simply reject or accept
> the session without sending a challenge.

Which seems useful only when it wants to offer limited access in that
case. And I agree, that /is/ useful.

> > You're not advocating (phew) that each user is to advertise 
> > his policy towards each NAS in advance, and no other form of 
> > advertising would prevent that step.
> 
> I am not advocating any such thing. I never have and I don't see how you
> come to the above statement.

Prescience, I think, considering what you wrote in this post. I wrote:

> >    Only the home AAA advertising to its upstream the policy that it
> >    needs Location, else don't bother sending an access request,
> >    would prevent the access request and the challenge. But the
> >    general idea with RADIUS is not that home AAA push their policies
> >    downstream, but that downstream queries upstream in the
> >    individual case.

and you answered:

> The RADIUS server pushing their policy to the NAS before the
> access-request is not possible today.

I read the "today" as that you think it might be useful. Or am I wrong?

Best regards,

Emile.

-- 
E-Advies - Emile van Bergen           [email-masked]      
tel. +31 (0)78 6136282           http://www.e-advies.nl    

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 21 Sep 2005 17:04:31 +0000
Content-class: urn:content-classes:message
Subject: RE: Capabilities (was Re: AW: Review of draft-ietf-geopriv-radius-lo-04.txt )
Date: Wed, 21 Sep 2005 13:04:50 -0400
From: "Avi Lior" <[email-masked]>
To: "Emile van Bergen" <[email-masked]>
Cc: "Bernard Aboba" <[email-masked]>, "Nelson, David" <[email-masked]>, <[email-masked]>, <[email-masked]>

Hi Emile,
This is a late response sorry.

See inline.....=20

> -----Original Message-----
> From: Emile van Bergen [mailto:[email-masked]]=20
> Sent: Friday, September 09, 2005 7:04 PM
> To: Avi Lior
> Cc: Bernard Aboba; Nelson, David; [email-masked];=20
> [email-masked]
> Subject: Re: Capabilities (was Re: AW: Review of=20
> draft-ietf-geopriv-radius-lo-04.txt )
>=20
> Hi,
>=20
> (Cross posting to GEOPRIV-WG; this discussion pertains to=20
> http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius-
> lo-04.txt,
> in particular section 8).
>=20
> On Fri, Sep 09, 2005 at 04:49:09PM -0400, Avi Lior wrote:
>=20
> > > The question is why GEOPRIV has decided not to send location by=20
> > > default.
> >=20
> > Initially we did exactly that we sent the location=20
> information in the=20
> > Access-Request.  But Geopriv being about privacy, was=20
> concerned what=20
> > if the user did not want to have their location exposed.
> >=20
> > So now we have the case where in some systems, the user's policy of=20
> > whether or not to expose location is stored in the a database and=20
> > during authentication the AAA learns that policy.
>=20
> Presumably you mean that the NAS learns the user's policy=20
> from the home server, who has access to the user's profile.
>=20
> I see that your position is in line with that, but I still do=20
> not see the point.
>=20
> 1. If the home AAA makes access or billing conditional on=20
> Location, the
>    user's own policy is irrelevant; the home AAA will only=20
> list the user
>    in his database if the user agrees with his location being
>    transmitted to the home AAA.=20

It could do that but it may also limit what it authorizes the user to do
if the user doesn't agree to location,

>=20
>    So if that is the case, if the home AAA doesn't see Location in a
>    request without State, it challenges. If it sees no Location in a
>    request with State, it rejects.=20

See above comment.
=20
>    Advertising the positive case (NAS supports GEOPRIV and will send
>    Location when challenged) in the access request does not=20
> prevent the
>    challenge.
>=20
>    Advertising the negative case (NAS supports GEOPRIV but=20
> will not send
>    Location when challenged) will prevent the challenge and allow the
>    home AAA to send a reject immediately.=20

Reject or Accept with limited access etc....
   =20
>    But that's a corner case that seems hardly worth dealing=20
> with. You'll
>    either have a NAS that supports it and needs a challenge, or a
>    pre-GEOPRIV NAS that won't do any negative GEOPRIV-advertising
>    either.

I don't follow/understand the "negative case"

>    Only the home AAA advertising to its upstream the policy that it
>    needs Location, else don't bother sending an access request, would
>    prevent the access request and the challenge. But the general idea
>    with RADIUS is not that home AAA push their policies=20
> downstream, but
>    that downstream queries upstream in the individual case.

The RADIUS server pushing their policy to the NAS before the
access-request is not possible today.

=20
>    In short: if Location is /needed/ by the home AAA, then you need a
>    Challenge step anyway, a. for the NAS to learn about the user's
>    policy, and b. for the AAA server to postpone its decision until it
>    learns the presence or value of Location.

You miss my point.  If the AAA server requires Location information and
it knows that the NAS does not support Location information then it will
not challenge.  It will simply reject or accept based on its local
policies.

If the AAA server requires location information but it does not know
whether or not the NAS supports location information -- it has no option
but to challenge for the information.  This is wasteful and worse can
result in the NAS treating the challenge as a reject and terminating the
session.

=20
> 2. If Location is optional, and only used for statistics, marketing,
>    and other shady purposes, then NAS can learn from the access accept
>    whether the user allows Location to be included in accounting
>    packets (start, interim and stop).

Sure....
   =20
>    The access accept could include a dummy Location value in=20
> that case,
>    and we could have language saying that the NAS MUST NOT=20
> send Location
>    in accounting unless an empty Location attribute is present in the
>    access accept.

Draft-capexchange as proposes a way to signal this.=20

=20
> In both cases: no advertising needed. Or even helpful.

I don't agree!!!

> > > > But that advertisement is also an extra transaction. What's
> > > the home
> > > > AAA supposed to do, keep state from separate=20
> > > > pseudo-authentications that include the advertised=20
> information for=20
> > > > later use? That doesn't sound like RADIUS, at all.
> > > Right.=20
> >=20
> > Wrong.
> >=20
> > No the advertizement is not an extra transaction.  It comes in the=20
> > Access-Request.
>=20
> But if the NAS may only include Location if it learns the=20
> user's policy first, for privacy reason, then telling the NAS=20
> about the user's policy /is/ an extra transaction. You need=20
> that one, too.

The extra message is required because Geopriv wants to have a mode where
by the location is not provided automatically.
So we cant help but using a Challenge.=20

However, what is being debated is whether it is helpful to have the NAS
tell the AAA server in the initial Access-Request whether or not the NAS
supports location information.

I say it is helpful. Since as I stated above, if the NAS does not
support location information, then the AAA can simply reject or accept
the session without sending a challenge.

=20
> You're not advocating (phew) that each user is to advertise=20
> his policy towards each NAS in advance, and no other form of=20
> advertising would prevent that step.

I am not advocating any such thing. I never have and I don't see how you
come to the above statement.

> > And by the way, RADIUS does keep transactional state. =20
>=20
> Please see my other post.=20
>=20
> The NAS does not keep state about users after they log off,=20
> so it can't cache the user's policy, and the home AAA does=20
> not keep state per NAS, so it can't use information about a=20
> NAS (negative support) from earlier authentications, unless=20
> you add a whole new dimension to building a compliant RADIUS server.

Can you please show me where I claim or require that the NAS keep state
after the user logs off?

> Kind regards,
>=20
>=20
> Emile.
>=20
> --=20
> E-Advies - Emile van Bergen           [email-masked]     =20
> tel. +31 (0)78 6136282           http://www.e-advies.nl   =20
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 21 Sep 2005 13:51:37 +0000
From: "Beck01, Wolfgang" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: AW: AW: Digest Authentication: Security issue with https/sips
Date: Wed, 21 Sep 2005 15:49:40 +0200

Miguel,

> Let A call B, so that A sends an INVITE request to B, assume that the 
> REquest-URI is sip:[email-masked]
> 
> According to the draft, A's network may want to authenticate the request 
> to make sure it comes from A and to verify that A is authorized to send 
> this SIP request.
> 
> So a SIP proxy in A's network challenges user A and the draft applies.
> 
> Now assume the same INVITE whereby A wants an encrypted end-to-end 
> secure communication. So A sends an INVITE request whose Request-URI is 
> a SIPS URI, like sips:[email-masked]. The only problem is that, if the 
> RADIUS interface between SIP server (at domain A) and the RADIUS 
> server (at domain A) is not secured, the request is rejected, giving the 
> user the sense that it is not possible to have a secure encrypted 
> signalling connection between A and B. This is not related to the 
> problem that the RADIUS interface is not secure at A's domain, the user 
> shouldn't be paying a penalty for this, and the A user shouldn't be 
> given the false sense that it is not possible to have end-to-end secured 
> communication at the SIP level.
RADIUS exposes parts of the request -- like username and URI -- which are
not exposed in a TLS session. If all SIP hops are encrypted with TLS and B's
domain uses locally specified security mechanims, your proxy would send username
and URI unencrypted to the RADIUS server.

If some intermediary rejects a sips call as it would have to send unencrypted
information to the RADIUS server, the client has the chance to tell the user
about this. It could display a message, like "Encryption not supported. Retry unencrypted?"

As far as I remember, the sentence about "locally specified security mechanisms"
in the callee's domain was added on request of 3GPP as IPsec is used instead of TLS.

To summarize:
Miguel's opinion: The information exposed by unencrypted RADIUS is not important
enough to justify sips call/https request rejection.
[correct me if I got it wrong]

Wolfgang's opinion: sips + unencrypted RADIUS results in partial encryption, which
is not what users expect.

Wolfgang

--
T-Systems International GmbH
Systems Integration
Technologiezentrum
Engineering Networks, Products & Services
Next Generation IP Services & Systems
Am Kavalleriesand 3
64295 Darmstadt
Tel +49 6151 937 2863

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 21 Sep 2005 11:27:55 +0000
Date: Wed, 21 Sep 2005 14:27:25 +0300
From: Miguel Garcia <[email-masked]>
To: "Beck01, Wolfgang" <[email-masked]>
CC: [email-masked]
Subject: Re: AW: Digest Authentication: Security issue with https/sips

Wolfgang:

I think we need to look at a particular scenario, you emphasis on the 
 >>>secure<<< communications is done on the wrong side of the call (on 
the callee's side), but RADIUS will be used in the other side, in the 
originating side.

Let A call B, so that A sends an INVITE request to B, assume that the 
REquest-URI is sip:[email-masked]

According to the draft, A's network may want to authenticate the request 
to make sure it comes from A and to verify that A is authorized to send 
this SIP request.

So a SIP proxy in A's network challenges user A and the draft applies.

Now assume the same INVITE whereby A wants an encrypted end-to-end 
secure communication. So A sends an INVITE request whose Request-URI is 
a SIPS URI, like sips:[email-masked]. The only problem is that, if the 
  RADIUS interface between SIP server (at domain A) and the RADIUS 
server (at domain A) is not secured, the request is rejected, giving the 
user the sense that it is not possible to have a secure encrypted 
signalling connection between A and B. This is not related to the 
problem that the RADIUS interface is not secure at A's domain, the user 
shouldn't be paying a penalty for this, and the A user shouldn't be 
given the false sense that it is not possible to have end-to-end secured 
communication at the SIP level.

Do you see the scenario I am thinking?

/Miguel

Beck01, Wolfgang wrote:

> Miguel,
> 
> 
>>First, I don't like the idea that a RADIUS draft (soon to be 
>>RFC) puts a normative statement to non-RADIUS protocols, namely
>>HTTP(RFC 2616/17) and SIP (RFC 3261). I am referring to the sentence
>>that reads
>>"... the RADIUS client MUST NOT accept secured connections (like https 
>>or sips) from its HTTP-style clients ...".
> 
> Unfortunately, the SIP/HTTP RfCs do not mention AAA servers. Do
> you propose a separate draft "https/sips usage with AAA protocols"?
> Is there a better behaviour than refusing the sips/https?
> 
> 
>>The second thing is that you are (IMHO) wrongly overloading the 
>>semantics of at least the SIPS URI, which is clearly defined 
>>in RFC 3261:
>>
>>    "A call
>>    made to a SIPS URI guarantees that secure, encrypted transport
>>    (namely TLS) is used to carry all SIP messages from the caller to the
>>    domain of the callee.  "
>>
> 
> RfC 3261, section 19.1 tells us (emphasis by me):
> "
>    A SIPS URI specifies that the resource be contacted securely.  This
>    means, in particular, that TLS is to be used between the UAC and the
>    domain that owns the URI.  From there, >>>secure<<< communications are used
>    to reach the user, where the specific security mechanism depends on
>    the policy of the domain."
> 
> So, secure communications has to be used, but not necessarily TLS. If
> I recall the SIP WG discussions correctly, the whole point of sips was
> to guarantee secure hops along the path of a SIP request.
> 
> 
>>it is not even implementable, since it does not affect RADIUS
> 
> The question is whether implementors will understand the desired
> behaviour. Introducing the concept of RADIUS and SIP/HTTP subsystems
> interacting with some internal protocol will not help.
> 
> Wolfgang
> 
> --
> T-Systems International GmbH
> Systems Integration
> Technologiezentrum
> Engineering Networks, Products & Services
> Next Generation IP Services & Systems
> Am Kavalleriesand 3
> 64295 Darmstadt
> Tel +49 6151 937 2863
> 
> 

-- 
Miguel A. Garcia           tel:+358-50-4804586
sip:[email-masked]
Nokia Research Center      Helsinki, Finland

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 21 Sep 2005 11:16:46 +0000
From: "Beck01, Wolfgang" <[email-masked]>
To: [email-masked], [email-masked]
Subject: AW: Digest Authentication: Security issue with https/sips
Date: Wed, 21 Sep 2005 13:15:30 +0200

Miguel,

> First, I don't like the idea that a RADIUS draft (soon to be 
> RFC) puts a normative statement to non-RADIUS protocols, namely
> HTTP(RFC 2616/17) and SIP (RFC 3261). I am referring to the sentence
> that reads
> "... the RADIUS client MUST NOT accept secured connections (like https 
> or sips) from its HTTP-style clients ...".
Unfortunately, the SIP/HTTP RfCs do not mention AAA servers. Do
you propose a separate draft "https/sips usage with AAA protocols"?
Is there a better behaviour than refusing the sips/https?

> 
> The second thing is that you are (IMHO) wrongly overloading the 
> semantics of at least the SIPS URI, which is clearly defined 
> in RFC 3261:
> 
>     "A call
>     made to a SIPS URI guarantees that secure, encrypted transport
>     (namely TLS) is used to carry all SIP messages from the caller to the
>     domain of the callee.  "
> 
RfC 3261, section 19.1 tells us (emphasis by me):
"
   A SIPS URI specifies that the resource be contacted securely.  This
   means, in particular, that TLS is to be used between the UAC and the
   domain that owns the URI.  From there, >>>secure<<< communications are used
   to reach the user, where the specific security mechanism depends on
   the policy of the domain."

So, secure communications has to be used, but not necessarily TLS. If
I recall the SIP WG discussions correctly, the whole point of sips was
to guarantee secure hops along the path of a SIP request.

> it is not even implementable, since it does not affect RADIUS
The question is whether implementors will understand the desired
behaviour. Introducing the concept of RADIUS and SIP/HTTP subsystems
interacting with some internal protocol will not help.

Wolfgang

--
T-Systems International GmbH
Systems Integration
Technologiezentrum
Engineering Networks, Products & Services
Next Generation IP Services & Systems
Am Kavalleriesand 3
64295 Darmstadt
Tel +49 6151 937 2863

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 21 Sep 2005 09:35:56 +0000
Date: Wed, 21 Sep 2005 12:34:37 +0300
From: Miguel Garcia <[email-masked]>
To: "Beck01, Wolfgang" <[email-masked]>, [email-masked]
Subject: Digest Authentication: Security issue with https/sips

Wolfgang, and the Radius extensions WG:

I was revising the RADIUS Digest authentication draft, to find out 
missing features that should be transposed to the Diameter SIP app. On 
doing this exersice I came to a paragraph on the RADIUS Client section 
that reads:

    If the packets between RADIUS client and RADIUS server are not
    protected with IPsec, the RADIUS client MUST NOT accept secured
    connections (like https or sips) from its HTTP-style clients, so that
    HTTP-style clients are not provided with a false sense of security.

I think this paragraph is not totally correct, and deserves a bit more 
of discussion. Here are my thoughts:

First, I don't like the idea that a RADIUS draft (soon to be RFC) puts a 
normative statement to non-RADIUS protocols, namely HTTP(RFC 2616/17) 
and SIP (RFC 3261). I am referring to the sentence that reads "... the 
RADIUS client MUST NOT accept secured connections (like https or sips) 
from its HTTP-style clients ...". At least in the Diameter SIP 
application we have put a lot of effort to just define the behaviour of 
the Diameter client, not the SIP server or SIP User Agent that is 
co-located with the Diameter client. In your document, even when the 
text says "the RADIUS client" it is not correct, because it refers to 
refusing an HTTP or SIP session, which takes place outside the RADIUS 
client, presumably in an HTTP/SIP server.

The second thing is that you are (IMHO) wrongly overloading the 
semantics of at least the SIPS URI, which is clearly defined in RFC 3261:

    "A call
    made to a SIPS URI guarantees that secure, encrypted transport
    (namely TLS) is used to carry all SIP messages from the caller to the
    domain of the callee.  "

Notice that a SIPS URI has nothing to do with the mechanism whereby a 
SIP proxy authenticates a user who has created some SIP request, and has 
nothing to do with the security of protocols beyond SIP. Notice even 
that the semantics of the SIPS URI does not mean that TLS is in every 
two hops from the caller to the callee, but rather that TLS is used from 
the caller to ***the domain of the callee*** (from them onwards, there 
could be anything). Similar things apply to HTTP, where I don't expect 
that the TLS security between the client and the server is mixed up with 
the security in the network to authorize the client's requests.

So do people have an opinion on this topic? In my opinion the above 
paragraph should be deleted from the current section. I think you can 
add some discussion of the threats and provide recommendations in the 
Security Consideration sections, but the current text is not acceptable 
(it is not even implementable, since it does not affect RADIUS).

/Miguel

-- 
Miguel A. Garcia           tel:+358-50-4804586
sip:[email-masked]
Nokia Research Center      Helsinki, Finland

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 20 Sep 2005 23:52:13 +0000
Content-class: urn:content-classes:message
Subject: FW: Issue 113: Attribute Concatenation
Date: Tue, 20 Sep 2005 16:44:52 -0700
From: "Congdon, Paul T (ProCurve)" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>

Responding to Greg's issue 113...

>I didn't understand how the language in section 3.6 about concatenating

>QoS-Filter-Rule(s) works.  If these are simply concatenated, how does=20
>an implementation distinguish between multiple 'small' QoS-Filter-Rules

>and a single larger attribute?  What if I want to send one=20
>QoS-Filter-Rule which spans 253, followed by one which does not?

Actually I believe the editorial note needs to be removed since there is
text just after the note that explains the problem.  As you know,
Diameter attributes may be larger than what will fit in the Radius
attribute so we need to support fragmentation and reassembly in the
general sense.

The assumption with concatenation is that you are building a 'list' of
QoS-Filter-Rules, just like you are building a 'list' of
NAS-Filter-Rules.  So, as the text states, if there are multiple
QoS-Filter-Rules, you simply concatenate them together (whether they are
multiple little rules or one large split rule) and treat them as a
'list'

The proposed resolution to this comment is to remove the editorial note.
If this is not acceptable, please propose some new text in this section
which helps clarify things for you - provided I've made that clear.

Thanks,

Paul

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 20 Sep 2005 15:58:56 +0000
Date: Tue, 20 Sep 2005 17:58:08 +0200
From: Emile van Bergen <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: RFC 2865
Mail-Followup-To: [email-masked], [email-masked]

Hi,

On Tue, Sep 20, 2005 at 04:53:32PM +0200, [email-masked] wrote:

> Hi all,
> 
> I have one question regarding RFC 2865. Maybe someone can help:
> 
> RFC 2865 section 5.22 (Framed-Route attribute) states:
> ---
> For IP routes, it SHOULD contain a destination prefix in dotted
> quad form optionally followed by a slash and a decimal length
> specifier stating how many high order bits of the prefix to use.
> That is followed by a space, a gateway address in dotted quad
> form, a space, and one or more metrics separated by spaces.  For
> example, "192.168.1.0/24 192.168.1.1 1 2 -1 3 400". The length
> specifier may be omitted, in which case it defaults to 8 bits for
> class A prefixes, 16 bits for class B prefixes, and 24 bits for
> class C prefixes.  For example, "192.168.1.0 192.168.1.1 1".
> 
> Whenever the gateway address is specified as "0.0.0.0" the IP
> Address of the user SHOULD be used as the gateway address.
> ---
> 
> It seems as if the Framed-Route attribute is used to create a routing
> table entry at the *NAS*. Is that correct?

Tat is correct. RADIUS responses are interpreted by the RADIUS client
(the NAS). Some RADIUS attributes (eg. EAP-Message) may be passed on by
the NAS to the user as part of an authentication protocol.

> However, I wonder why the NAS (cf. second part of above citation) would
> configure the IP address of the user as gateway? Is there any scenario
> for that?

If you want to route a netblock to the user, you want to use the IP
address of the user as the gateway address.

It's especially useful in dial-on-demand WAN backup scenarios.

Kind regards,

Emile.

-- 
E-Advies - Emile van Bergen           [email-masked]      
tel. +31 (0)78 6136282           http://www.e-advies.nl    

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 20 Sep 2005 14:54:09 +0000
Content-class: urn:content-classes:message
Subject: RFC 2865
Date: Tue, 20 Sep 2005 16:53:32 +0200
From: <[email-masked]>
To: <[email-masked]>

Hi all,

I have one question regarding RFC 2865. Maybe someone can help:

RFC 2865 section 5.22 (Framed-Route attribute) states:
---
For IP routes, it SHOULD contain a destination prefix in dotted
quad form optionally followed by a slash and a decimal length
specifier stating how many high order bits of the prefix to use.
That is followed by a space, a gateway address in dotted quad
form, a space, and one or more metrics separated by spaces.  For
example, "192.168.1.0/24 192.168.1.1 1 2 -1 3 400". The length
specifier may be omitted, in which case it defaults to 8 bits for
class A prefixes, 16 bits for class B prefixes, and 24 bits for
class C prefixes.  For example, "192.168.1.0 192.168.1.1 1".

Whenever the gateway address is specified as "0.0.0.0" the IP
Address of the user SHOULD be used as the gateway address.
---

It seems as if the Framed-Route attribute is used to create a routing
table entry at the *NAS*. Is that correct?

However, I wonder why the NAS (cf. second part of above citation) would
configure the IP address of the user as gateway? Is there any scenario
for that?

Kind regards,

Rajendra

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 19 Sep 2005 18:42:27 +0000
Date: Mon, 19 Sep 2005 11:42:15 -0700
From: Anjaneyulu Pata <[email-masked]>
Reply-To: [email-masked]
To: Bernard Aboba <[email-masked]>
Subject: Re: REMINDER: Review comments on RFC 3576 MIBs
Cc: [email-masked]

------=_Part_34928_23290920.1127155335914
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

I have read the documents and the documents seems to be OK
 Anjaneyulu

 On 9/14/05, Bernard Aboba <[email-masked]> wrote:=20
>=20
> So far, the RFC 3576 MIBs have received only a few comments.
>=20
> In order to advance this document, we will need to get more affirmative
> response that WG participants have read it.
>=20
> If you have read the documents and believe they are ok, please post this
> indication to the RADEXT WG list.
>=20
> If you have read the documents and have an issue with them, please post
> the issue to the RADEXT WG list in the format described on the RADEXT WG
> web page:
> http://www.drizzle.com/~aboba/RADEXT/
>=20
> If you have not read the documents, please do so NOW:
>=20
> http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-client-mib-=
01.txt
>=20
> http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-server-mib-=
01.txt
>=20
>=20
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>

------=_Part_34928_23290920.1127155335914
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<div>I have read the documents and the documents seems to be OK</div>
<div>&nbsp;</div>
<div>Anjaneyulu</div>
<div><br>&nbsp;</div>
<div><span class=3D"gmail_quote">On 9/14/05, <b class=3D"gmail_sendername">=
Bernard Aboba</b> &lt;<a href=3D"mailto:[email-masked]">aboba@internau=
t.com</a>&gt; wrote:</span>
<blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0=
px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">So far, the RFC 3576 MIBs have r=
eceived only a few comments.<br><br>In order to advance this document, we w=
ill need to get more affirmative
<br>response that WG participants have read it.<br><br>If you have read the=
 documents and believe they are ok, please post this<br>indication to the R=
ADEXT WG list.<br><br>If you have read the documents and have an issue with=
 them, please post
<br>the issue to the RADEXT WG list in the format described on the RADEXT W=
G<br>web page:<br><a href=3D"http://www.drizzle.com/~aboba/RADEXT/">http://=
www.drizzle.com/~aboba/RADEXT/</a><br><br>If you have not read the document=
s, please do so NOW:
<br><a href=3D"http://www.ietf.org/internet-drafts/draft-ietf-radext-dynaut=
h-client-mib-01.txt">http://www.ietf.org/internet-drafts/draft-ietf-radext-=
dynauth-client-mib-01.txt</a><br><a href=3D"http://www.ietf.org/internet-dr=
afts/draft-ietf-radext-dynauth-server-mib-01.txt">
http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-server-mib-01=
.txt</a><br><br><br>--<br>to unsubscribe send a message to <a href=3D"mailt=
o:[email-masked]">[email-masked]</a> with
<br>the word 'unsubscribe' in a single line as the message text body.<br>ar=
chive: &lt;<a href=3D"http://psg.com/lists/radiusext/">http://psg.com/lists=
/radiusext/</a>&gt;<br></blockquote></div><br>

------=_Part_34928_23290920.1127155335914--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 19 Sep 2005 18:14:45 +0000
Content-class: urn:content-classes:message
Subject: RE: Deployment Review for Bandwidth Attributes Document
Date: Mon, 19 Sep 2005 10:53:30 -0700
From: "Congdon, Paul T (ProCurve)" <[email-masked]>
To: "Wijnen, Bert (Bert)" <[email-masked]>, "Bernard Aboba" <[email-masked]>, "Mick Seaman" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

Bert,

The most recent comments in this thread are related to how 3GPP, Wi-Fi
and 802.11e have chosen to map the 802.1D/Q traffic classes to
applications (Discussed in Annex G of 802.1Q).  This is not what the
bandwidth draft is specifying and I haven't seen any evidence so far
that the draft is not on track to satisfy the original intent to allow
simple bandwidth allocations for 802.1 and 802.11 devices.

Paul=20

> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:[email-masked]]=20
> Sent: Sunday, September 18, 2005 2:56 AM
> To: Bernard Aboba; Mick Seaman
> Cc: Congdon, Paul T (ProCurve); [email-masked];=20
> [email-masked]
> Subject: RE: Deployment Review for Bandwidth Attributes Document
>=20
> Bernard writes:
> > It sounds like there is a potential conflict between the intended=20
> > usages of this document by various SDOs.
> >=20
>=20
> And so to me that sounds as a not-so-good-basis to try to converge
> and define a standard. But if you want it to become a stds track
> document, then it is absolutely necessary (in my view) to
> converge on exactly what needs to be specified and what the
> intended uses are.
>=20
> Bert
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 19 Sep 2005 15:50:37 +0000
content-class: urn:content-classes:message
Subject: RE: Deployment Review for Bandwidth Attributes Document
Date: Mon, 19 Sep 2005 08:49:55 -0700
To: "Adrangi, Farid" <[email-masked]>, "Bernard Aboba" <[email-masked]>, "Mick Seaman" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
From: "Bari, Farooq" <[email-masked]>

I had similar understanding i.e. DSCP/802.1 tags were outside the scope
of this radext draft.

Farooq Bari
Cingular Wireless
Core Network Standards
=20
[email-masked]
+1 425 580 5526

> -----Original Message-----
> From: Adrangi, Farid [mailto:[email-masked]]
> Sent: Monday, September 19, 2005 8:44 AM
> To: Bernard Aboba; Mick Seaman
> Cc: Bari, Farooq; [email-masked]; [email-masked]
> Subject: RE: Deployment Review for Bandwidth Attributes Document
>=20
> Yes, I agree.
>=20
> WME/802.11e (w/Call Admission Control - CAC) deployments in Enterprise
> networks is now happening.  And, WME/802.11e enabled Public WLAN
hotspot
> deployments are next in order to provide WLAN users real-time services
> w/ QoS over WLAN and also enabling end-2-end QoS.  The draft was
> originally intended to allow the home network to indicate the
Bandwidth
> Authorization (BA) to the WLAN access network for a given user, and
also
> enable the access network to indicate the allocated bandwidth in the
> accounting messages.  Later also profile ID was added. Based on the BA
> information and the profile ID, the access network should be able to
> decide whether it can accept an 80211e/ADDTS request from a user.
>=20
> While use of DSCP/802.1 tags over WLAN link and their mappings to
wired
> segments are important, it is outside the scope of this document -
IMHO.
>=20
>=20
> Thanks,
> Farid
>=20
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Bernard Aboba
> > Sent: Sunday, September 18, 2005 8:52 AM
> > To: Mick Seaman
> > Cc: 'Bari, Farooq'; [email-masked]; [email-masked]
> > Subject: RE: Deployment Review for Bandwidth Attributes Document
> >
> >
> > From a technical point of view,  the Bandwidth Attributes and
> > VLAN/Priority documents were chartered in RADEXT WG for the
> > purpose of
> > satisfying requests originating in the IEEE 802 community.  The BW
> > Attributes request came from WFA (marketing arm of IEEE
> > 802.11), and the
> > VLAN/Priority document came out of IEEE 802.1.
> >
> > While it is ok (good, in fact) if those documents satisfy other
> > constituencies as well, at the end of the day, these
> > documents MUST meet
> > the needs of the groups making the original request.
> >
> >
> > On Sat, 17 Sep 2005, Mick Seaman wrote:
> >
> > >
> > > Farooq,
> > >
> > > Given that a lot of bridges are deployed in environments
> > were keeping
> > > management to a minimum is a practical necessity, and that
> > there are very
> > > widespread deployments which use fairly well known values
> > what you say is
> > > legalistically correct but can only give rise to conflict.
> > One of the future
> > > items of working that is being proposed in 802.1 is the use
> > of Ethernet for
> > > residential home entertainment applications including a
> > variety of music and
> > > video applications. The notion that a home owner is going to make
a
> > > management decision abut his or her network and then manage a lot
of
> > > different equipment with different natural backgrounds will
> > kill ease of
> > > use, or prevent equipment that departs far from usual practice
being
> > > successful.
> > >
> > > So my legalistic response here is that we are talking about
> > 802.1D/.1Q
> > > priorities here, whose aim is to support Diffserv and does
> > provide a lot of
> > > flexibility but also whose aim is to provide as much usual
> > guidance as
> > > possible an advocate the default use of mappings that seem
> > to provide
> > > maximal interoperability with minimum management. A lot of
> > effort has been
> > > put into that so far, and the notion that all might be
> > discarded and revised
> > > to a new set that requires further management because
> > "anything is possible"
> > > is not something that should happen without examination.
> > >
> > > Goals that are impossible to achieve fully  can still yield
> > substantial
> > > benefit to many people if 80% achieved. There is no reason
> > to suppose that
> > > in the absence of perfection we should advocate anarchy.
> > >
> > > Mick
> > >
> > > -----Original Message-----
> > > From: Bari, Farooq [mailto:[email-masked]]
> > > Sent: Saturday, September 17, 2005 8:49 AM
> > > To: [email-masked]; Congdon, Paul T (ProCurve)
> > > Cc: [email-masked]; Bernard Aboba; [email-masked]
> > > Subject: RE: Deployment Review for Bandwidth Attributes Document
> > >
> > > Hi Mick,
> > >
> > > I look forward to hearing from you. I do want to float my
> > understanding
> > > of DSCP usage and understand if other folks disagree (although
this
> > > topic does not have much to do with radext).
> > > My understanding is that interpretation and usage of DSCP within a
> > > network is whatever the owner of the network decides to
> > have i.e. it can
> > > choose to ignore them, overwrite/remark them, use them to
prioritize
> > > traffic the way it decides etc. The importance of standard
> > > interpretation/marking of these settings is typically at
> > the boundaries
> > > of networks. However this standard interpretation is
> > dependent upon on
> > > the SLAs that the networks have amongst themselves i.e. the
> > > interpretation is not global but limited to SLA. SLAs
> > between networks
> > > can vary significantly based on network technologies and the type
of
> > > traffic that they carry. Also I am not aware of any forum
> > in the world
> > > that can standardize this for all the networks in the world. So if
I
> > > understood the comments correctly, although the goals seem
> > noble they
> > > may be quite hard to get (if not impossible).....
> > >
> > > BR,
> > >
> > > Farooq Bari
> >
> > --
> > to unsubscribe send a message to [email-masked] with
> > the word 'unsubscribe' in a single line as the message text body.
> > archive: <http://psg.com/lists/radiusext/>
> >

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 19 Sep 2005 15:50:03 +0000
Content-class: urn:content-classes:message
Subject: RE: Deployment Review for Bandwidth Attributes Document
Date: Mon, 19 Sep 2005 08:44:01 -0700
From: "Adrangi, Farid" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, "Mick Seaman" <[email-masked]>
Cc: "Bari, Farooq" <[email-masked]>, <[email-masked]>, <[email-masked]>

Yes, I agree. =20

WME/802.11e (w/Call Admission Control - CAC) deployments in Enterprise
networks is now happening.  And, WME/802.11e enabled Public WLAN hotspot
deployments are next in order to provide WLAN users real-time services
w/ QoS over WLAN and also enabling end-2-end QoS.  The draft was
originally intended to allow the home network to indicate the Bandwidth
Authorization (BA) to the WLAN access network for a given user, and also
enable the access network to indicate the allocated bandwidth in the
accounting messages.  Later also profile ID was added. Based on the BA
information and the profile ID, the access network should be able to
decide whether it can accept an 80211e/ADDTS request from a user.

While use of DSCP/802.1 tags over WLAN link and their mappings to wired
segments are important, it is outside the scope of this document - IMHO.

Thanks,
Farid

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Sunday, September 18, 2005 8:52 AM
> To: Mick Seaman
> Cc: 'Bari, Farooq'; [email-masked]; [email-masked]
> Subject: RE: Deployment Review for Bandwidth Attributes Document
>=20
>=20
> From a technical point of view,  the Bandwidth Attributes and=20
> VLAN/Priority documents were chartered in RADEXT WG for the=20
> purpose of=20
> satisfying requests originating in the IEEE 802 community.  The BW=20
> Attributes request came from WFA (marketing arm of IEEE=20
> 802.11), and the=20
> VLAN/Priority document came out of IEEE 802.1.=20
>=20
> While it is ok (good, in fact) if those documents satisfy other=20
> constituencies as well, at the end of the day, these=20
> documents MUST meet=20
> the needs of the groups making the original request.=20
>=20
>=20
> On Sat, 17 Sep 2005, Mick Seaman wrote:
>=20
> >=20
> > Farooq,
> >=20
> > Given that a lot of bridges are deployed in environments=20
> were keeping
> > management to a minimum is a practical necessity, and that=20
> there are very
> > widespread deployments which use fairly well known values=20
> what you say is
> > legalistically correct but can only give rise to conflict.=20
> One of the future
> > items of working that is being proposed in 802.1 is the use=20
> of Ethernet for
> > residential home entertainment applications including a=20
> variety of music and
> > video applications. The notion that a home owner is going to make a
> > management decision abut his or her network and then manage a lot of
> > different equipment with different natural backgrounds will=20
> kill ease of
> > use, or prevent equipment that departs far from usual practice being
> > successful.=20
> >=20
> > So my legalistic response here is that we are talking about=20
> 802.1D/.1Q
> > priorities here, whose aim is to support Diffserv and does=20
> provide a lot of
> > flexibility but also whose aim is to provide as much usual=20
> guidance as
> > possible an advocate the default use of mappings that seem=20
> to provide
> > maximal interoperability with minimum management. A lot of=20
> effort has been
> > put into that so far, and the notion that all might be=20
> discarded and revised
> > to a new set that requires further management because=20
> "anything is possible"
> > is not something that should happen without examination.
> >=20
> > Goals that are impossible to achieve fully  can still yield=20
> substantial
> > benefit to many people if 80% achieved. There is no reason=20
> to suppose that
> > in the absence of perfection we should advocate anarchy.
> >=20
> > Mick
> >=20
> > -----Original Message-----
> > From: Bari, Farooq [mailto:[email-masked]]
> > Sent: Saturday, September 17, 2005 8:49 AM
> > To: [email-masked]; Congdon, Paul T (ProCurve)
> > Cc: [email-masked]; Bernard Aboba; [email-masked]
> > Subject: RE: Deployment Review for Bandwidth Attributes Document
> >=20
> > Hi Mick,
> >=20
> > I look forward to hearing from you. I do want to float my=20
> understanding
> > of DSCP usage and understand if other folks disagree (although this
> > topic does not have much to do with radext).=20
> > My understanding is that interpretation and usage of DSCP within a
> > network is whatever the owner of the network decides to=20
> have i.e. it can
> > choose to ignore them, overwrite/remark them, use them to prioritize
> > traffic the way it decides etc. The importance of standard
> > interpretation/marking of these settings is typically at=20
> the boundaries
> > of networks. However this standard interpretation is=20
> dependent upon on
> > the SLAs that the networks have amongst themselves i.e. the
> > interpretation is not global but limited to SLA. SLAs=20
> between networks
> > can vary significantly based on network technologies and the type of
> > traffic that they carry. Also I am not aware of any forum=20
> in the world
> > that can standardize this for all the networks in the world. So if I
> > understood the comments correctly, although the goals seem=20
> noble they
> > may be quite hard to get (if not impossible).....
> >=20
> > BR,
> >=20
> > Farooq Bari
>=20
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 19 Sep 2005 02:29:01 +0000
content-class: urn:content-classes:message
Subject: RE: Deployment Review for Bandwidth Attributes Document
Date: Mon, 19 Sep 2005 05:28:31 +0300
From: "Romascanu, Dan \(Dan\)" <[email-masked]>
To: "Congdon, Paul T \(ProCurve\)" <[email-masked]>, "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>, "Mick Seaman" <[email-masked]>, "Tony Jeffree" <[email-masked]>, <[email-masked]>

Paul,

I believe that it would be a useful thing to discuss this in 802.1. I
would rather see the issues of how we standardize definition of
bandwidth, what limiting means, and how to do it discussed first in
802.1. It can be taken over by radext later, but I do not believe that
it is a RADIUS extension problem, other management protocols may apply.
This is the reason for which I did not support the work in radext,
although the problem of bandwidth limitation is interesting for me as
well.=20

Thanks and Regards,

Dan

=20
=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Congdon,=20
> Paul T (ProCurve)
> Sent: Friday, September 16, 2005 7:23 PM
> To: Bernard Aboba
> Cc: [email-masked]; Mick Seaman; Tony Jeffree
> Subject: RE: Deployment Review for Bandwidth Attributes Document
>=20
>=20
> I believe the proposal Avi and I have discussed would=20
> interest the 802.1 folks and I can certainly present this=20
> briefly to them next week at the Interim.
>=20
> Paul=20
>=20
> > -----Original Message-----
> > From: Bernard Aboba [mailto:[email-masked]]
> > Sent: Friday, September 16, 2005 9:21 AM
> > To: Congdon, Paul T (ProCurve)
> > Cc: [email-masked]
> > Subject: RE: Deployment Review for Bandwidth Attributes Document
> >=20
> > One way to move forward would be to revise the document in order to=20
> > increase buyin from the individuals who responded to the survey.
> > In particular, wider buyin from IEEE 802.1 participants would be=20
> > desirable.
> >=20
> > With IETF 64 and the  November IEEE 802 plenary occurring=20
> in the same=20
> > city (Vancouver, CA) one week apart, this might be a good=20
> opportunity=20
> > for cooperation.
> >=20
> >=20
> > On Fri, 16 Sep 2005, Congdon, Paul T (ProCurve) wrote:
> >=20
> > >=20
> > > Sounds to me like there is support, especially if we added
> > a scheme to
> > > support the 802 traffic classes.  Avi and I have talked
> > about a simple
> > > and optional way to do this without crossing the complexity
> > line.  It
> > > would be good to know if this would satisfy Pat's needs.
> > >=20
> > > Paul
> >=20
>=20
> --
> to unsubscribe send a message to=20
> [email-masked] with the word 'unsubscribe' in=20
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sun, 18 Sep 2005 15:52:46 +0000
Date: Sun, 18 Sep 2005 08:52:07 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Mick Seaman <[email-masked]>
cc: "'Bari, Farooq'" <[email-masked]>, [email-masked],  [email-masked]
Subject: RE: Deployment Review for Bandwidth Attributes Document

>From a technical point of view,  the Bandwidth Attributes and 
VLAN/Priority documents were chartered in RADEXT WG for the purpose of 
satisfying requests originating in the IEEE 802 community.  The BW 
Attributes request came from WFA (marketing arm of IEEE 802.11), and the 
VLAN/Priority document came out of IEEE 802.1. 

While it is ok (good, in fact) if those documents satisfy other 
constituencies as well, at the end of the day, these documents MUST meet 
the needs of the groups making the original request. 

On Sat, 17 Sep 2005, Mick Seaman wrote:

> 
> Farooq,
> 
> Given that a lot of bridges are deployed in environments were keeping
> management to a minimum is a practical necessity, and that there are very
> widespread deployments which use fairly well known values what you say is
> legalistically correct but can only give rise to conflict. One of the future
> items of working that is being proposed in 802.1 is the use of Ethernet for
> residential home entertainment applications including a variety of music and
> video applications. The notion that a home owner is going to make a
> management decision abut his or her network and then manage a lot of
> different equipment with different natural backgrounds will kill ease of
> use, or prevent equipment that departs far from usual practice being
> successful. 
> 
> So my legalistic response here is that we are talking about 802.1D/.1Q
> priorities here, whose aim is to support Diffserv and does provide a lot of
> flexibility but also whose aim is to provide as much usual guidance as
> possible an advocate the default use of mappings that seem to provide
> maximal interoperability with minimum management. A lot of effort has been
> put into that so far, and the notion that all might be discarded and revised
> to a new set that requires further management because "anything is possible"
> is not something that should happen without examination.
> 
> Goals that are impossible to achieve fully  can still yield substantial
> benefit to many people if 80% achieved. There is no reason to suppose that
> in the absence of perfection we should advocate anarchy.
> 
> Mick
> 
> -----Original Message-----
> From: Bari, Farooq [mailto:[email-masked]]
> Sent: Saturday, September 17, 2005 8:49 AM
> To: [email-masked]; Congdon, Paul T (ProCurve)
> Cc: [email-masked]; Bernard Aboba; [email-masked]
> Subject: RE: Deployment Review for Bandwidth Attributes Document
> 
> Hi Mick,
> 
> I look forward to hearing from you. I do want to float my understanding
> of DSCP usage and understand if other folks disagree (although this
> topic does not have much to do with radext). 
> My understanding is that interpretation and usage of DSCP within a
> network is whatever the owner of the network decides to have i.e. it can
> choose to ignore them, overwrite/remark them, use them to prioritize
> traffic the way it decides etc. The importance of standard
> interpretation/marking of these settings is typically at the boundaries
> of networks. However this standard interpretation is dependent upon on
> the SLAs that the networks have amongst themselves i.e. the
> interpretation is not global but limited to SLA. SLAs between networks
> can vary significantly based on network technologies and the type of
> traffic that they carry. Also I am not aware of any forum in the world
> that can standardize this for all the networks in the world. So if I
> understood the comments correctly, although the goals seem noble they
> may be quite hard to get (if not impossible).....
> 
> BR,
> 
> Farooq Bari

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sun, 18 Sep 2005 09:58:46 +0000
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: Bernard Aboba <[email-masked]>, Mick Seaman <[email-masked]>
Cc: "'Congdon, Paul T (ProCurve)'" <[email-masked]>, [email-masked], [email-masked]
Subject: RE: Deployment Review for Bandwidth Attributes Document
Date: Sun, 18 Sep 2005 11:56:29 +0200

Bernard writes:
> It sounds like there is a potential conflict between the 
> intended usages of this document by various SDOs. 
> 

And so to me that sounds as a not-so-good-basis to try to converge
and define a standard. But if you want it to become a stds track
document, then it is absolutely necessary (in my view) to
converge on exactly what needs to be specified and what the
intended uses are.

Bert

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sat, 17 Sep 2005 15:50:13 +0000
content-class: urn:content-classes:message
Subject: RE: Deployment Review for Bandwidth Attributes Document
Date: Sat, 17 Sep 2005 08:48:45 -0700
To: <[email-masked]>, "Congdon, Paul T \(ProCurve\)" <[email-masked]>
Cc: <[email-masked]>, "Bernard Aboba" <[email-masked]>, <[email-masked]>
From: "Bari, Farooq" <[email-masked]>

Hi Mick,

I look forward to hearing from you. I do want to float my understanding
of DSCP usage and understand if other folks disagree (although this
topic does not have much to do with radext).=20
My understanding is that interpretation and usage of DSCP within a
network is whatever the owner of the network decides to have i.e. it can
choose to ignore them, overwrite/remark them, use them to prioritize
traffic the way it decides etc. The importance of standard
interpretation/marking of these settings is typically at the boundaries
of networks. However this standard interpretation is dependent upon on
the SLAs that the networks have amongst themselves i.e. the
interpretation is not global but limited to SLA. SLAs between networks
can vary significantly based on network technologies and the type of
traffic that they carry. Also I am not aware of any forum in the world
that can standardize this for all the networks in the world. So if I
understood the comments correctly, although the goals seem noble they
may be quite hard to get (if not impossible).....

BR,

Farooq Bari

> -----Original Message-----
> From: Mick Seaman [mailto:[email-masked]]
> Sent: Friday, September 16, 2005 9:49 PM
> To: Bari, Farooq; 'Congdon, Paul T (ProCurve)'
> Cc: [email-masked]; 'Bernard Aboba'; [email-masked]
> Subject: RE: Deployment Review for Bandwidth Attributes Document
>=20
>=20
> Farooq,
>=20
> Yes, my comments (and these were necessarily quick because I don't
have much
> time just at the moment) are all to do with the code point choices.
While these may
> not be the most technically important things in the document, getting
most of the
> world lined up on usage will be of tremendous value - and will avoid
having to make
> arbitrary choices about what some important new application areas
should be
> consistent with.
>=20
> We have some recent experience with someone writing what was meant to
be a
> harmless example possibility into a document (just a random document
as it turned
> out, not even a standard or pseudo-standard), and the whole world went
off and
> stole a (fortunately unallocated, but unchecked) code point. In that
case it was an
> Ethernet Type allocation, but you get the idea. Examples get treated
as the gold
> standard by those who don't read further.
>=20
> I will try and get you some more detailed feedback next week, as it
happens we
> have an 802.1 meeting and I will put some time on the agenda for the
group to
> generate some more considered input/views on the particular scenarios
raised. I
> will also get time to read the document properly for the things I have
missed and
> other casual readers may miss.
>=20
> Mick
>=20
> -----Original Message-----
> From: Bari, Farooq [mailto:[email-masked]]
> Sent: Friday, September 16, 2005 9:08 PM
> To: [email-masked]; Congdon, Paul T (ProCurve)
> Cc: [email-masked]; Bernard Aboba
> Subject: RE: Deployment Review for Bandwidth Attributes Document
>=20
>=20
> Paul, Mick,
>=20
> I take it from the comments that they are about diffserv
mapping/marking
> and not regarding section 5.2.1 which is related to radext discussion.
> Also pls note that 3GPP has NOT defined any new diffserv marking /
> mapping but only tried to explain a SAMPLE scenario as to how a system
> could work in the presence mappings / diffserv markings/mappings
already
> defined by other forums (WiFI Alliance, GSM, IEEE....). I would be
happy
> to bring in changes into 3GPP specifications if the sample scenario
> seems incorrect / inconsistent.
>=20
> BR,
>=20
> Farooq Bari
>=20
> > -----Original Message-----
> > From: Mick Seaman [mailto:[email-masked]]
> > Sent: Friday, September 16, 2005 4:26 PM
> > To: 'Congdon, Paul T (ProCurve)'
> > Cc: Bari, Farooq; [email-masked]; 'Bernard Aboba'
> > Subject: RE: Deployment Review for Bandwidth Attributes Document
> >
> >
> > Paul,
> >
> > You are right these seem to be a fair way out of line which is
> worrying
> > because the mappings advocated in .1Q-REV Annex G were particularly
> chosen
> > (very slightly tweaked from .1D-2004) to maximize interopearability
> with lot
> > of deployed IP stuff, use of MPLS EXP bits etc.. At first glance
> (which is
> > all I have time for) the mappings in the attached {.11e,Wi-Fi, 3GPP}
> > document seem somewhat arbitrary, just carving the available space
> into 4
> > chunks. I would hope that these could be rechosen to fit into the
> maximal
> > interoperability recommendations already in Annex G. Otherwise
someone
> is
> > going to be managing a lot of translation gateways, which is very
much
> not
> > in the spirit we have tried to pursue.
> >
> > Mick
> >
> > -----Original Message-----
> > From: Congdon, Paul T (ProCurve) [mailto:[email-masked]]
> > Sent: Friday, September 16, 2005 3:04 PM
> > To: Mick Seaman
> > Subject: FW: Deployment Review for Bandwidth Attributes Document
> >
> >
> >
> > Mick,
> >
> > FYI...  I don't think the traffic class mappings that 802.11e, WMM
> Wi-Fi
> > and 3GPP are recommending here are exactly what 802.1 had in mind -
do
> > you?  There is no provision for network control traffic.
> >
> > Paul
> >
> > -----Original Message-----
> > From: Bari, Farooq [mailto:[email-masked]]
> > Sent: Friday, September 16, 2005 9:39 AM
> > To: Bernard Aboba; Congdon, Paul T (ProCurve); Sabine Demel;
> > [email-masked]
> > Subject: RE: Deployment Review for Bandwidth Attributes Document
> >
> > It would be useful to take into consideration the intention of other
> > forums/operators about the possible use of such mechanisms. I am
> > attaching an approved document from last week's 3GPP SA2 meeting.
Pls
> > see section 5.2.1 that indicates using such mechanisms in Rel 7
> > timeframe.
> >
> > BR,
> >
> > Farooq Bari
> > Cingular Wireless
> > Core Network Standards
> >
> > [email-masked]
> > +1 425 580 5526
> >
> > > -----Original Message-----
> > > From: [email-masked]
> > [mailto:[email-masked]] On
> > > Behalf Of Bernard Aboba
> > > Sent: Friday, September 16, 2005 9:21 AM
> > > To: Congdon, Paul T (ProCurve)
> > > Cc: [email-masked]
> > > Subject: RE: Deployment Review for Bandwidth Attributes Document
> > >
> > > One way to move forward would be to revise the document in order
to
> > > increase buyin from the individuals who responded to the survey.
> > > In particular, wider buyin from IEEE 802.1 participants would be
> > > desirable.
> > >
> > > With IETF 64 and the  November IEEE 802 plenary occurring in the
> same
> > city
> > > (Vancouver, CA) one week apart, this might be a good opportunity
for
> > > cooperation.
> > >
> > >
> > > On Fri, 16 Sep 2005, Congdon, Paul T (ProCurve) wrote:
> > >
> > > >
> > > > Sounds to me like there is support, especially if we added a
> scheme
> > to
> > > > support the 802 traffic classes.  Avi and I have talked about a
> > simple
> > > > and optional way to do this without crossing the complexity
line.
> > It
> > > > would be good to know if this would satisfy Pat's needs.
> > > >
> > > > Paul
> > >
> > > --
> > > to unsubscribe send a message to [email-masked]
with
> > > the word 'unsubscribe' in a single line as the message text body.
> > > archive: <http://psg.com/lists/radiusext/>
> >

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sat, 17 Sep 2005 04:09:34 +0000
content-class: urn:content-classes:message
Subject: RE: Deployment Review for Bandwidth Attributes Document
Date: Fri, 16 Sep 2005 21:08:24 -0700
To: <[email-masked]>, "Congdon, Paul T \(ProCurve\)" <[email-masked]>
Cc: <[email-masked]>, "Bernard Aboba" <[email-masked]>
From: "Bari, Farooq" <[email-masked]>

Paul, Mick,

I take it from the comments that they are about diffserv mapping/marking
and not regarding section 5.2.1 which is related to radext discussion.
Also pls note that 3GPP has NOT defined any new diffserv marking /
mapping but only tried to explain a SAMPLE scenario as to how a system
could work in the presence mappings / diffserv markings/mappings already
defined by other forums (WiFI Alliance, GSM, IEEE....). I would be happy
to bring in changes into 3GPP specifications if the sample scenario
seems incorrect / inconsistent.

BR,

Farooq Bari

> -----Original Message-----
> From: Mick Seaman [mailto:[email-masked]]
> Sent: Friday, September 16, 2005 4:26 PM
> To: 'Congdon, Paul T (ProCurve)'
> Cc: Bari, Farooq; [email-masked]; 'Bernard Aboba'
> Subject: RE: Deployment Review for Bandwidth Attributes Document
>=20
>=20
> Paul,
>=20
> You are right these seem to be a fair way out of line which is
worrying
> because the mappings advocated in .1Q-REV Annex G were particularly
chosen
> (very slightly tweaked from .1D-2004) to maximize interopearability
with lot
> of deployed IP stuff, use of MPLS EXP bits etc.. At first glance
(which is
> all I have time for) the mappings in the attached {.11e,Wi-Fi, 3GPP}
> document seem somewhat arbitrary, just carving the available space
into 4
> chunks. I would hope that these could be rechosen to fit into the
maximal
> interoperability recommendations already in Annex G. Otherwise someone
is
> going to be managing a lot of translation gateways, which is very much
not
> in the spirit we have tried to pursue.
>=20
> Mick
>=20
> -----Original Message-----
> From: Congdon, Paul T (ProCurve) [mailto:[email-masked]]
> Sent: Friday, September 16, 2005 3:04 PM
> To: Mick Seaman
> Subject: FW: Deployment Review for Bandwidth Attributes Document
>=20
>=20
>=20
> Mick,
>=20
> FYI...  I don't think the traffic class mappings that 802.11e, WMM
Wi-Fi
> and 3GPP are recommending here are exactly what 802.1 had in mind - do
> you?  There is no provision for network control traffic.
>=20
> Paul
>=20
> -----Original Message-----
> From: Bari, Farooq [mailto:[email-masked]]
> Sent: Friday, September 16, 2005 9:39 AM
> To: Bernard Aboba; Congdon, Paul T (ProCurve); Sabine Demel;
> [email-masked]
> Subject: RE: Deployment Review for Bandwidth Attributes Document
>=20
> It would be useful to take into consideration the intention of other
> forums/operators about the possible use of such mechanisms. I am
> attaching an approved document from last week's 3GPP SA2 meeting. Pls
> see section 5.2.1 that indicates using such mechanisms in Rel 7
> timeframe.
>=20
> BR,
>=20
> Farooq Bari
> Cingular Wireless
> Core Network Standards
>=20
> [email-masked]
> +1 425 580 5526
>=20
> > -----Original Message-----
> > From: [email-masked]
> [mailto:[email-masked]] On
> > Behalf Of Bernard Aboba
> > Sent: Friday, September 16, 2005 9:21 AM
> > To: Congdon, Paul T (ProCurve)
> > Cc: [email-masked]
> > Subject: RE: Deployment Review for Bandwidth Attributes Document
> >
> > One way to move forward would be to revise the document in order to
> > increase buyin from the individuals who responded to the survey.
> > In particular, wider buyin from IEEE 802.1 participants would be
> > desirable.
> >
> > With IETF 64 and the  November IEEE 802 plenary occurring in the
same
> city
> > (Vancouver, CA) one week apart, this might be a good opportunity for
> > cooperation.
> >
> >
> > On Fri, 16 Sep 2005, Congdon, Paul T (ProCurve) wrote:
> >
> > >
> > > Sounds to me like there is support, especially if we added a
scheme
> to
> > > support the 802 traffic classes.  Avi and I have talked about a
> simple
> > > and optional way to do this without crossing the complexity line.
> It
> > > would be good to know if this would satisfy Pat's needs.
> > >
> > > Paul
> >
> > --
> > to unsubscribe send a message to [email-masked] with
> > the word 'unsubscribe' in a single line as the message text body.
> > archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 16 Sep 2005 23:38:26 +0000
Date: Fri, 16 Sep 2005 16:38:10 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Mick Seaman <[email-masked]>
cc: "'Congdon, Paul T (ProCurve)'" <[email-masked]>,  [email-masked], [email-masked]
Subject: RE: Deployment Review for Bandwidth Attributes Document

It sounds like there is a potential conflict between the intended usages 
of this document by various SDOs. 

On Fri, 16 Sep 2005, Mick Seaman wrote:

> 
> Paul,
> 
> You are right these seem to be a fair way out of line which is worrying
> because the mappings advocated in .1Q-REV Annex G were particularly chosen
> (very slightly tweaked from .1D-2004) to maximize interopearability with lot
> of deployed IP stuff, use of MPLS EXP bits etc.. At first glance (which is
> all I have time for) the mappings in the attached {.11e,Wi-Fi, 3GPP}
> document seem somewhat arbitrary, just carving the available space into 4
> chunks. I would hope that these could be rechosen to fit into the maximal
> interoperability recommendations already in Annex G. Otherwise someone is
> going to be managing a lot of translation gateways, which is very much not
> in the spirit we have tried to pursue.
> 
> Mick
> 
> -----Original Message-----
> From: Congdon, Paul T (ProCurve) [mailto:[email-masked]]
> Sent: Friday, September 16, 2005 3:04 PM
> To: Mick Seaman
> Subject: FW: Deployment Review for Bandwidth Attributes Document
> 
> Mick,
> 
> FYI...  I don't think the traffic class mappings that 802.11e, WMM Wi-Fi
> and 3GPP are recommending here are exactly what 802.1 had in mind - do
> you?  There is no provision for network control traffic.
> 
> Paul
> 
> -----Original Message-----
> From: Bari, Farooq [mailto:[email-masked]]
> Sent: Friday, September 16, 2005 9:39 AM
> To: Bernard Aboba; Congdon, Paul T (ProCurve); Sabine Demel;
> [email-masked]
> Subject: RE: Deployment Review for Bandwidth Attributes Document
> 
> It would be useful to take into consideration the intention of other
> forums/operators about the possible use of such mechanisms. I am
> attaching an approved document from last week's 3GPP SA2 meeting. Pls
> see section 5.2.1 that indicates using such mechanisms in Rel 7
> timeframe.
> 
> BR,
> 
> Farooq Bari
> Cingular Wireless
> Core Network Standards
> 
> [email-masked]
> +1 425 580 5526

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 16 Sep 2005 22:52:28 +0000
content-class: urn:content-classes:message
Subject: RE: Deployment Review for Bandwidth Attributes Document
Date: Fri, 16 Sep 2005 15:51:19 -0700
To: <[email-masked]>
From: "Bari, Farooq" <[email-masked]>

Not sure why my previous message did not get posted. In any case the
document I was referring to (S2-052339.zip) is available at
ftp://ftp.3gpp.org/tsg_sa/WG2_Arch/TSGS2_48_Sophia_Antipolis/Docs/

BR,

Farooq Bari
Cingular Wireless
Core Network Standards
=20
[email-masked]
+1 425 580 5526

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]] On
> Behalf Of Bernard Aboba
> Sent: Friday, September 16, 2005 2:45 PM
> To: [email-masked]
> Subject: RE: Deployment Review for Bandwidth Attributes Document
>=20
>=20
>=20
> ---------- Forwarded message ----------
> Date: Fri, 16 Sep 2005 09:38:47 -0700
> From: "Bari, Farooq" <[email-masked]>
> To: Bernard Aboba <[email-masked]>,
>     "Congdon, Paul T (ProCurve)" <[email-masked]>,
>     Sabine Demel <[email-masked]>, [email-masked]
> Subject: RE: Deployment Review for Bandwidth Attributes Document
>=20
> It would be useful to take into consideration the intention of other
> forums/operators about the possible use of such mechanisms. I am
> attaching an approved document from last week's 3GPP SA2 meeting. Pls
> see section 5.2.1 that indicates using such mechanisms in Rel 7
> timeframe.
>=20
> BR,
>=20
> Farooq Bari
> Cingular Wireless
> Core Network Standards
>=20
> [email-masked]
> +1 425 580 5526
>=20
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 16 Sep 2005 21:45:55 +0000
Date: Fri, 16 Sep 2005 14:45:12 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: RE: Deployment Review for Bandwidth Attributes Document

---------- Forwarded message ----------
Date: Fri, 16 Sep 2005 09:38:47 -0700
From: "Bari, Farooq" <[email-masked]>
To: Bernard Aboba <[email-masked]>,
    "Congdon, Paul T (ProCurve)" <[email-masked]>,
    Sabine Demel <[email-masked]>, [email-masked]
Subject: RE: Deployment Review for Bandwidth Attributes Document

It would be useful to take into consideration the intention of other
forums/operators about the possible use of such mechanisms. I am
attaching an approved document from last week's 3GPP SA2 meeting. Pls
see section 5.2.1 that indicates using such mechanisms in Rel 7
timeframe.

BR,

Farooq Bari
Cingular Wireless
Core Network Standards
 
[email-masked]
+1 425 580 5526

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 16 Sep 2005 18:12:21 +0000
Date: Fri, 16 Sep 2005 11:11:42 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Emile van Bergen <[email-masked]>
cc: "Congdon, Paul T (ProCurve)" <[email-masked]>, [email-masked],  [email-masked]
Subject: Re: Issue 101: WG Last Call Review

Yes, I think the text is fine.  

On Fri, 16 Sep 2005, Emile van Bergen wrote:

> Hi,
> 
> On Thu, Sep 15, 2005 at 05:29:23PM -0700, Congdon, Paul T (ProCurve) wrote:
> 
> > I think we are converging.  Would love to hear from others if this is
> > acceptable...
> 
> That text looks very good.
> 
> Kind regards,
> 
> 
> Emile.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 16 Sep 2005 16:23:36 +0000
Content-class: urn:content-classes:message
Subject: RE: Deployment Review for Bandwidth Attributes Document
Date: Fri, 16 Sep 2005 09:23:01 -0700
From: "Congdon, Paul T (ProCurve)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>, "Mick Seaman" <[email-masked]>, "Tony Jeffree" <[email-masked]>

I believe the proposal Avi and I have discussed would interest the 802.1
folks and I can certainly present this briefly to them next week at the
Interim.

Paul=20

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]]=20
> Sent: Friday, September 16, 2005 9:21 AM
> To: Congdon, Paul T (ProCurve)
> Cc: [email-masked]
> Subject: RE: Deployment Review for Bandwidth Attributes Document
>=20
> One way to move forward would be to revise the document in=20
> order to increase buyin from the individuals who responded to=20
> the survey. =20
> In particular, wider buyin from IEEE 802.1 participants would=20
> be desirable.=20
>=20
> With IETF 64 and the  November IEEE 802 plenary occurring in=20
> the same city (Vancouver, CA) one week apart, this might be a=20
> good opportunity for cooperation.=20
>=20
>=20
> On Fri, 16 Sep 2005, Congdon, Paul T (ProCurve) wrote:
>=20
> >=20
> > Sounds to me like there is support, especially if we added=20
> a scheme to=20
> > support the 802 traffic classes.  Avi and I have talked=20
> about a simple=20
> > and optional way to do this without crossing the complexity=20
> line.  It=20
> > would be good to know if this would satisfy Pat's needs.
> >=20
> > Paul
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 16 Sep 2005 16:21:19 +0000
Date: Fri, 16 Sep 2005 09:20:56 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: "Congdon, Paul T (ProCurve)" <[email-masked]>
cc: [email-masked]
Subject: RE: Deployment Review for Bandwidth Attributes Document

One way to move forward would be to revise the document in order to 
increase buyin from the individuals who responded to the survey.  
In particular, wider buyin from IEEE 802.1 participants would be 
desirable. 

With IETF 64 and the  November IEEE 802 plenary occurring in the same city 
(Vancouver, CA) one week apart, this might be a good opportunity for 
cooperation. 

On Fri, 16 Sep 2005, Congdon, Paul T (ProCurve) wrote:

> 
> Sounds to me like there is support, especially if we added a scheme to
> support the 802 traffic classes.  Avi and I have talked about a simple
> and optional way to do this without crossing the complexity line.  It
> would be good to know if this would satisfy Pat's needs.
> 
> Paul 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 16 Sep 2005 15:58:00 +0000
Content-class: urn:content-classes:message
Subject: RE: Deployment Review for Bandwidth Attributes Document
Date: Fri, 16 Sep 2005 08:56:47 -0700
From: "Congdon, Paul T (ProCurve)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>
Cc: "Pat Calhoun (pacalhou)" <[email-masked]>

Sounds to me like there is support, especially if we added a scheme to
support the 802 traffic classes.  Avi and I have talked about a simple
and optional way to do this without crossing the complexity line.  It
would be good to know if this would satisfy Pat's needs.

Paul=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Thursday, September 15, 2005 9:23 PM
> To: [email-masked]
> Subject: Deployment Review for Bandwidth Attributes Document
>=20
> As part of the pre-work item review process, Bert Wijnen, our=20
> esteemed O&M AD, has suggested that RADEXT WG determine the=20
> level of customer interest, in order to avoid having the WG=20
> spend time developing specifications that are unlikely to be=20
> deployed.=20
>=20
> Since work on bandwidth limitation was originally requested=20
> by the Wifi Alliance (WFA) which had developed VSAs for=20
> Bandwidth Limitation, we requested feedback from 802.11=20
> vendors on whether they had implemented the existing WFA VSAs.=20
>=20
> We also requested feedback from IEEE 802.3 switch vendors on=20
> whether they would implement the bandwidth limitation=20
> attributes described in the document.=20
>=20
> Detailed responses are enclosed below.=20
>=20
> The response from the IEEE 802.11 vendors indicates that the=20
> existing WFA bandwidth limitation attributes have not been=20
> deployed, although some vendors have deployed their own VSAs=20
> (which typically provide more granular control).=20
>=20
> The response form IEEE 802.3 switch vendors indicates that=20
> while there is interest in Bandwidth Limitation, the proposed=20
> attributes do not provide the desired degree of granularity.
>=20
> --------------------------------------------------------------
> ---------
> IEEE 802 Review of Bandwidth Attributes Document
>=20
> --------------------------------------------------------------
> -------------------------
> Feedback from IEEE 802.11 Vendors
> --------------------------------------------------------------
> -------------------------
> Gerard Goubert (formerly of UNH, now with Funk Software)
>=20
> We do not have any evidence of bandwidth limitation=20
> attributes being deployed. I can only assume that as more and=20
> more voice gets deployed more people (WISP ops) will have to=20
> use QoS and provision bandwidth via some method. This one=20
> seems reasonable; though we would have further input to this=20
> draft and possible improvements to offer.
>       =20
> I personally wonder how well it will work in practice (I hope=20
> it does), as the RADIUS servers will send the bandwidth=20
> requirements, but it is up to the NAS to enforce it. This=20
> sort of implies a MAC based filtering firewall for each entry=20
> in the filtering database of the NAS, which some people have=20
> started to do. (aruba has admission control and load=20
> balancing `things'
> that seem to do this) This is pretty complex and can get=20
> expensive in terms of CPU and memory on the NAS. And in the=20
> wireless case, if there is a client filing up the airwaves on=20
> the access side, the NAS can choose to not forward them, but=20
> cannot _make_ the client stop `polluting' the access side.=20
> (there may be dis-assoc requests and PAUSE and other things that try
> to limit the client, but who says the client will pay=20
> attention?)      =20
>=20
> We have seen usage of Filter-ID in Access-Accept messages,=20
> but this has been primarily for security issues (session=20
> hijacking to redirect to forced landing page) and VLAN=20
> assignment, but not (yet) for QoS reasons.
>=20
> I am interested in this and will try to keep track of it and=20
> provide input where I can.
>=20
> -gerard
> Funk Software, Inc.
> 222 Third Street
> Cambridge, MA 02142
> USA
>=20
> --------------------------------------------------------------
> -------------------------
> Pat Calhoun, CTO of Cisco WNBU
>=20
> Yes, our product does something similar, but the capabilities=20
> of the draft would not be sufficient (read: expansive) enough=20
> for our needs.
> --------------------------------------------------------------
> -------------------------
> Clint Chaplin, Symbol Technologies
>=20
> We currently implement bandwidth limiting, usually using a UI=20
> and/or MIBs to administer it.  We would be very interested in=20
> using RADIUS attributes to communicate the bandwidth policies=20
> on a per-client basis to the APs/Wireless Switches during=20
> authentication.
> =20
> Clint Chaplin
>  =20
> --------------------------------------------------------------
> -------------------------
> Feedback from IEEE 802.1 Participants
> --------------------------------------------------------------
> -------------------------
>=20
> Norm Finn of Cisco:
>=20
> This might be interesting, both in the enterprise and in the=20
> metro environment.  I assume we're talking about limits per=20
> .1Q tag priority value.
>=20
> --------------------------------------------------------------
> -------------------------
> =20
> John Roese, CTO of Enterasys:
>=20
> I am not sure about bandwidth limits per tag but in general=20
> retrieving a bandwidth limit parameter as the result of the=20
> RADIUS transaction is of interest. Today this is something we=20
> trigger quite often in Enterprise environments using other=20
> mechanisms that relate to the AAA transaction or are=20
> associated with attributes that do flow in that exchange.=20
>=20
> As far as deployment levels today, while not the majority, at=20
> least in my customer base it is something that is of high=20
> interest and deployed by a sizable minority. The real=20
> sticking point is the ability of the edge device to enforce=20
> such limits as there is a wide range of "rate limiting"=20
> capability and granularity in edge products today so we would=20
> need to be pretty broad in our approach to the values sent.=20
>=20
> --------------------------------------------------------------
> -------------------------
>=20
> Paul Congdon of HP:
>=20
> We deploy this capability today in our products using VSAs.=20
>=20
> The current draft does not take into account traffic classes=20
> and is purely a 'port based' bandwidth specification. =20
> However, the bandwidth profile ID attribute could be used to=20
> define per-priority bandwidth limits, but I think it would be=20
> reasonable to add traffic class to the other attribute=20
> specifications without making this too complex.  We have been=20
> attempting to keep this as simple as possible, while still=20
> being useful, and avoiding overlap with more general and=20
> complex QoS schemes.
>=20
> --------------------------------------------------------------
> -------------------------
> Mick Seaman, formerly of Telseon (Ethernet ISP):
>=20
> I think it would be essential to introduce traffic clases for=20
> this to have any real positive impact, given the likely=20
> evolution of the .1 standards. I also think, again without=20
> wishing to make this too complex, that this should accomodate=20
> at least the cut down notions of "what bandwidth means"=20
> (not to exceed x bits in y milliseconds, simplified by having=20
> y quantized using a well known quantum) that a few of us=20
> having been discussing in the context of Residential=20
> Etherenet/Residential Bridging to meet Home Entertainment=20
> requirements on Etherent. That may be quite a step from the=20
> goals of the original proponents, but I think it is reality=20
> if this is going to have any staying power as an effort.
> --------------------------------------------------------------
> -------------------------
>=20
>=20
>=20
>=20
>=20
> --
> to unsubscribe send a message to=20
> [email-masked] with the word 'unsubscribe' in=20
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 16 Sep 2005 09:57:06 +0000
Date: Fri, 16 Sep 2005 11:56:36 +0200
From: Emile van Bergen <[email-masked]>
To: "Congdon, Paul T (ProCurve)" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Issue 101: WG Last Call Review
Mail-Followup-To: "Congdon, Paul T (ProCurve)" <[email-masked]>, [email-masked], [email-masked]

Hi,

On Thu, Sep 15, 2005 at 05:29:23PM -0700, Congdon, Paul T (ProCurve) wrote:

> I think we are converging.  Would love to hear from others if this is
> acceptable...

That text looks very good.

Kind regards,

Emile.

-- 
E-Advies - Emile van Bergen           [email-masked]      
tel. +31 (0)78 6136282           http://www.e-advies.nl    

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 16 Sep 2005 08:40:46 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue 101: WG Last Call Review
Date: Fri, 16 Sep 2005 11:39:57 +0300
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>

[email-masked] wrote:
> I agree that we shouldn't repeat text from the other documents,
> but I do believe some of the security considerations documented
> in these other documents may still apply.  I'd like to at least
> leave the introductory paragraph, followed by your text.  The
> security section would then look as follows:
<snip>

This looks OK to me.

Best regards,
Pasi

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 16 Sep 2005 04:23:15 +0000
Date: Thu, 15 Sep 2005 21:22:32 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Deployment Review for Bandwidth Attributes Document

As part of the pre-work item review process, Bert Wijnen, our esteemed O&M 
AD, has suggested that RADEXT WG determine the level of customer interest, 
in order to avoid having the WG spend time developing specifications that 
are unlikely to be deployed. 

Since work on bandwidth limitation was originally requested by the 
Wifi Alliance (WFA) which had developed VSAs for Bandwidth Limitation, 
we requested feedback from 802.11 vendors on whether they had 
implemented the existing WFA VSAs. 

We also requested feedback from IEEE 802.3 switch vendors on 
whether they would implement the bandwidth limitation 
attributes described in the document. 

Detailed responses are enclosed below. 

The response from the IEEE 802.11 vendors indicates that the existing WFA 
bandwidth limitation attributes have not been deployed, although some 
vendors have deployed their own VSAs (which typically provide more 
granular control). 

The response form IEEE 802.3 switch vendors indicates that while there is 
interest in Bandwidth Limitation, the proposed attributes do not provide 
the desired degree of granularity.

-----------------------------------------------------------------------
IEEE 802 Review of Bandwidth Attributes Document

---------------------------------------------------------------------------------------
Feedback from IEEE 802.11 Vendors
---------------------------------------------------------------------------------------
Gerard Goubert (formerly of UNH, now with Funk Software)

We do not have any evidence of bandwidth limitation attributes being
deployed. I can only assume that as more and more voice gets deployed more
people (WISP ops) will have to use QoS and provision bandwidth via 
some method. This one seems reasonable; though we would have further 
input to this draft and possible improvements to offer.
       
I personally wonder how well it will work in practice (I hope it does), as
the RADIUS servers will send the bandwidth requirements, but it is up to
the NAS to enforce it. This sort of implies a MAC based filtering firewall
for each entry in the filtering database of the NAS, which some people have
started to do. (aruba has admission control and load balancing `things'
that seem to do this) This is pretty complex and can get expensive in terms
of CPU and memory on the NAS. And in the wireless case, if there is a
client filing up the airwaves on the access side, the NAS can choose to not
forward them, but cannot _make_ the client stop `polluting' the access
side. (there may be dis-assoc requests and PAUSE and other things that try
to limit the client, but who says the client will pay attention?)       

We have seen usage of Filter-ID in Access-Accept messages, but this 
has been primarily for security issues (session hijacking to redirect to 
forced landing page) and VLAN assignment, but not (yet) for QoS reasons.

I am interested in this and will try to keep track of it and provide input
where I can.

-gerard
Funk Software, Inc.
222 Third Street
Cambridge, MA 02142
USA

---------------------------------------------------------------------------------------
Pat Calhoun, CTO of Cisco WNBU

Yes, our product does something similar, but the capabilities of the
draft would not be sufficient (read: expansive) enough for our needs.
---------------------------------------------------------------------------------------
Clint Chaplin, Symbol Technologies

We currently implement bandwidth limiting, usually using a UI and/or MIBs 
to administer it.  We would be very interested in using RADIUS attributes 
to communicate the bandwidth policies on a per-client basis to the 
APs/Wireless Switches during authentication.
 
Clint Chaplin
  
---------------------------------------------------------------------------------------
Feedback from IEEE 802.1 Participants
---------------------------------------------------------------------------------------

Norm Finn of Cisco:

This might be interesting, both in the enterprise and in the metro
environment.  I assume we're talking about limits per .1Q tag priority
value.

---------------------------------------------------------------------------------------
 
John Roese, CTO of Enterasys:

I am not sure about bandwidth limits per tag but in general retrieving a
bandwidth limit parameter as the result of the RADIUS transaction is of
interest. Today this is something we trigger quite often in Enterprise
environments using other mechanisms that relate to the AAA transaction
or are associated with attributes that do flow in that exchange. 

As far as deployment levels today, while not the majority, at least in
my customer base it is something that is of high interest and deployed
by a sizable minority. The real sticking point is the ability of the
edge device to enforce such limits as there is a wide range of "rate
limiting" capability and granularity in edge products today so we would
need to be pretty broad in our approach to the values sent. 

---------------------------------------------------------------------------------------

Paul Congdon of HP:

We deploy this capability today in our products using VSAs. 

The current draft does not take into account traffic classes and is
purely a 'port based' bandwidth specification.  However, the bandwidth
profile ID attribute could be used to define per-priority bandwidth
limits, but I think it would be reasonable to add traffic class to the
other attribute specifications without making this too complex.  We have
been attempting to keep this as simple as possible, while still being
useful, and avoiding overlap with more general and complex QoS schemes.

---------------------------------------------------------------------------------------
Mick Seaman, formerly of Telseon (Ethernet ISP):

I think it would be essential to introduce traffic clases for this to have
any real positive impact, given the likely evolution of the .1 standards. I
also think, again without wishing to make this too complex, that this 
should accomodate at least the cut down notions of "what bandwidth means" 
(not to exceed x bits in y milliseconds, simplified by having y quantized 
using a well known quantum) that a few of us having been discussing in the 
context of Residential Etherenet/Residential Bridging to meet Home 
Entertainment requirements on Etherent. That may be quite a step from the 
goals of the original proponents, but I think it is reality if this is 
going to have any staying power as an effort.
---------------------------------------------------------------------------------------

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 16 Sep 2005 00:30:36 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue 101: WG Last Call Review
Date: Thu, 15 Sep 2005 17:29:23 -0700
From: "Congdon, Paul T (ProCurve)" <[email-masked]>
To: <[email-masked]>, <[email-masked]>

I think we are converging.  Would love to hear from others if this is
acceptable...
=20
> >=20
> > I'm assuming the text you provided would be in addition to what is=20
> > already there?  Below, I've merged  your text into the=20
> existing text=20
> > as an entirely new Security section.
>=20
> No, the text was intended as a replacement of what's already there.
>=20
> The existing text is IMHO unnecessary because it doesn't=20
> describe any security considerations of _this_ document. I=20
> don't think we need to repeat what's already said in RFC 2865=20
> and 3579 in every document that defines a new RADIUS=20
> attribute: we just need to describe what new security=20
> considerations this document has (in addition to those=20
> already adequately described in 2865/3579).
>=20

I agree that we shouldn't repeat text from the other documents, but I do
believe some of the security considerations documented in these other
documents may still apply.  I'd like to at least leave the introductory
paragraph, followed by your text.  The security section would then look
as follows:

7.  Security Considerations=20
   =20
      Since this document describes the use of RADIUS for purposes of=20
      authentication, authorization, and accounting in IEEE 802.1X-
      enabled networks, it is vulnerable to all of the threats that are=20
      present in other RADIUS applications. For a discussion of these=20
      threats, see [RFC2607], [RFC3162], [RFC3579], and [RFC3580].=20
   =20
      This documents specifies new attributes that can be included
      in existing RADIUS messages. These messages are protected
      using existing security mechanisms; see [RFC2865] and
      [RFC3576] for a more detailed description and related security
      considerations.
 =20
      The security mechanisms in [RFC2865] and [RFC3576] are
      primarily concerned with an outside attacker who modifies
      messages in transit or inserts new messages. They do not
      prevent an authorized RADIUS server or proxy from inserting
      attributes with a malicious purpose in message it sends.
   =20
      An attacker who compromises an authorized RADIUS server or
      proxy can use the attributes defined in this document to
      influence the behavior of the NAS in ways that previously may
      not have been possible. For example, modifications to the=20
      VLAN-related attributes may cause the NAS to permit access to
      other VLANs that were intended. To give another example,
      inserting suitable redirection rules to the NAS-Filter-Rule
      attribute may allow the attacker to eavesdrop or modify
      packets sent by a legitimate client.
 =20
      In general, the NAS cannot know whether the attribute values
      it receives from an authenticated and authorized server are
      well-intentioned or malicious, and thus it is not possible to
      completely protect against attacks by compromised nodes. In
      some cases, the extent of the possible attacks can be limited
      by performing more fine-grained authorization checks at the NAS.=20
      For instance, a NAS could be configured to accept only certain
      VLAN IDs from a certain RADIUS server/proxy, or not to accept
      any redirection rules if it is known they are not used in
      this environment.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 15 Sep 2005 19:54:57 +0000
Date: Thu, 15 Sep 2005 12:54:41 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: IETF last call on RADIUS Chargeable User-ID (fwd)

The IESG has received a request from the RADIUS EXTensions WG to consider the 
following document:

- 'Chargeable User Identity '
   <draft-ietf-radext-chargeable-user-id-05.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by 2005-09-29.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-radext-chargeable-user-id-05.txt

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 15 Sep 2005 17:57:34 +0000
content-class: urn:content-classes:message
Subject: RE: REMINDER: Call for review of RFC 2618bis-2621bis
Date: Thu, 15 Sep 2005 20:55:28 +0300
From: "Romascanu, Dan \(Dan\)" <[email-masked]>
To: "Wijnen, Bert \(Bert\)" <[email-masked]>, "Nelson, David" <[email-masked]>, <[email-masked]>

Indeed, my comment in the review back in December 2004 was that distinct
MIB modules defined in distinct documents should rather be assigned (via
IANA)  under mib-2. This is also what the MIB review guidelines section
4.5 say.=20

Regards,

Dan

=20
=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Wijnen, Bert (Bert)
> Sent: Thursday, September 15, 2005 6:24 PM

> >=20
>=20
> What we object to (and that is what Juergen and Dan probably=20
> said or meant to say) is that we do not want something where=20
> you define say
>=20
>    radiusMIB  { mib-2 xx }
>=20
>    radiusServerMIB { radiusMIB 1 }
>    radiusClientMib { radiusMIB 2 }
>    radiusSomeOtherMIB { radiusMIB 3 }
>    etc
>=20
> All those MIB modules would be possibly be in different MIB documents.
> If you extend one MIB module then if you do it inside the MIB=20
> module (say radiusSomeMIB) and the last OID you used was for=20
> let us say
>=20
>    lastObjectInVersion1 =20
>=20
>        ::=3D { radiusSomeMIB 18 }
>=20
> The newly added objects within the same MIB module would be numbered
>=20
>    firstNewObjectInVersion2 =20
>=20
>        ::=3D { radiusSomeMIB 19 }
>=20
>    secondNewObjectInVersion2 =20
>=20
>        ::=3D { radiusSomeMIB 20 }
>=20
>    etc.
>=20
> It is if you were to do extension in anotehr MIB module that=20
> you would do a new assignment under mib-2. You could AUGMENT=20
> or EXTEND tables in the base MIB module still.
>=20
> Hope this helps.
>=20
> Bert
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 15 Sep 2005 15:41:15 +0000
Content-class: urn:content-classes:message
Subject: Issue: RFC 2618bis-2621bis root OIDs
Date: Thu, 15 Sep 2005 11:39:52 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Submitter name: David Nelson
Submitter email address: [email-masked]
Date first submitted: September 15, 2005
Reference: https://psg.com/lists/radiusext/2005/msg00866.html
Document: 2618bis-00 through 2621bis-00
Comment type: 'T' Technical
Priority: 'S' Must fix
Section: 7, MIB Definitions
Rationale/Explanation of issue:

Bert Wijnen writes...

radiusMIB OBJECT-IDENTITY
          STATUS  current
          DESCRIPTION
                "The OID assigned to RADIUS MIB work by the IANA."
           ::=3D { mib-2 67 }

radiusAuthClientExtMIB OBJECT-IDENTITY
          STATUS  current
          DESCRIPTION
                "The OID assigned to RADIUS Extensions MIB work by
                 the IANA."
           ::=3D { mib-2 TBA }

   -- RFC Editor: replace TBA with IANA assigned OID value, and
   -- remove this note.

Why do we need/want 2 OID branches underneath mib-2?
Why can the extensions not be made just within the radiusAuthClientMIB
branch itself?

Requested change:

Delete the new "TBA" roots under MIB-2 (for example
radiusAuthClientExtMIB) and locate the extended (new) MIB objects as the
next available OIDs under the existing IANA assignment for the
respective MIB.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 15 Sep 2005 15:24:23 +0000
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: "Nelson, David" <[email-masked]>, [email-masked]
Subject: RE: REMINDER: Call for review of RFC 2618bis-2621bis
Date: Thu, 15 Sep 2005 17:24:00 +0200

> 
> Dave Nelson writes...
> 
> Responding to my own reply.
> 
> > Bert Wijnen writes...
> >
> > > Why do we need/want 2 OID branches underneath mib-2?
> > > Why can the extensions not be made just within the
> > > radiusAuthClientMIB branch itself?
> > 
> > That question was raised and answered at IETF-63.  The 
> answer was that
> > all MIB extension work was to be rooted directly under 
> MIB-II, as that
> > is the only registry that IANA controls.  I believe it was Juergen
> > Schoenwaelder who provided that guidance.  I believe that Dan
> Romascanu
> > has given similar advice previously.
> > 
> > Is that not the correct answer?  I tend to think that the 
> approach you
> > suggest makes more sense, but I was previously corrected 
> for doing it
> > that way.
> 
> Would the fact that we now understand that these drafts will Obsolete
> their counterpart RFCs, and contain all the MIB objects from those RFCs,
> change the advice around issuing a new MIB branch directly under MIB-II
> for the extensions objects?  Would it be acceptable to use the original
> OIDs issues for the RADIUS MIBs as the [sole] root for their
> replacements?
> 

What we object to (and that is what Juergen and Dan probably
said or meant to say) is that we do not want something where
you define say

   radiusMIB  { mib-2 xx }

   radiusServerMIB { radiusMIB 1 }
   radiusClientMib { radiusMIB 2 }
   radiusSomeOtherMIB { radiusMIB 3 }
   etc

All those MIB modules would be possibly be in different MIB documents.
If you extend one MIB module then if you do it inside the MIB
module (say radiusSomeMIB) and the last OID you used was for let
us say

   lastObjectInVersion1  

       ::= { radiusSomeMIB 18 }

The newly added objects within the same MIB module would be
numbered

   firstNewObjectInVersion2  

       ::= { radiusSomeMIB 19 }

   secondNewObjectInVersion2  

       ::= { radiusSomeMIB 20 }

   etc.

It is if you were to do extension in anotehr MIB module that
you would do a new assignment under mib-2. You could
AUGMENT or EXTEND tables in the base MIB module still.

Hope this helps.

Bert

> 
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 15 Sep 2005 15:10:33 +0000
Content-class: urn:content-classes:message
Subject: RE: REMINDER: Call for review of RFC 2618bis-2621bis
Date: Thu, 15 Sep 2005 11:10:26 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Dave Nelson writes...

Responding to my own reply.

> Bert Wijnen writes...
>
> > Why do we need/want 2 OID branches underneath mib-2?
> > Why can the extensions not be made just within the
> > radiusAuthClientMIB branch itself?
>=20
> That question was raised and answered at IETF-63.  The answer was that
> all MIB extension work was to be rooted directly under MIB-II, as that
> is the only registry that IANA controls.  I believe it was Juergen
> Schoenwaelder who provided that guidance.  I believe that Dan
Romascanu
> has given similar advice previously.
>=20
> Is that not the correct answer?  I tend to think that the approach you
> suggest makes more sense, but I was previously corrected for doing it
> that way.

Would the fact that we now understand that these drafts will Obsolete
their counterpart RFCs, and contain all the MIB objects from those RFCs,
change the advice around issuing a new MIB branch directly under MIB-II
for the extensions objects?  Would it be acceptable to use the original
OIDs issues for the RADIUS MIBs as the [sole] root for their
replacements?

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 15 Sep 2005 15:03:25 +0000
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: "Nelson, David" <[email-masked]>, [email-masked]
Subject: RE: Issue: RFC 2618bis-2621bis nits
Date: Thu, 15 Sep 2005 17:02:28 +0200

> Submitter name: David Nelson
> Submitter email address: [email-masked]
> Date first submitted: September 15, 2005
> Reference: https://psg.com/lists/radiusext/2005/msg00855.html
> Document: 2618bis-00 through 2621bis-00
> Comment type: 'E'ditorial
> Priority: 'S' Must fix
> Section: 7, MIB Definitions
> Rationale/Explanation of issue:
> 
> >   C:\bwijnen\smicng\work>smicng radiusAuthClient.inc
> >   W: f(radiusAuthClient.mi2), (29,20) Revision date not in
> >      proper order - most recent comes first
> >   W: f(radiusAuthClient.mi2), (27,20) The first revision
> >      should match the last update for MODULE-IDENTITY
> >      radiusAuthClientMIB
> 
> Requested change:
> 
> Locate the latest revision at the top of the revision history list.
> 

By the way, the DESCRIPTION clause of a REVISION should 
contain a description of the (major) changes to the MIB
module.

Bert

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 15 Sep 2005 15:03:19 +0000
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: "Nelson, David" <[email-masked]>, [email-masked]
Subject: RE: REMINDER: Call for review of RFC 2618bis-2621bis
Date: Thu, 15 Sep 2005 17:02:28 +0200

inline
> >    ./RADIUS-AUTH-CLIENT-MIB:48: [2] {bad-identifier-case}
> >     `TBA' should start with a lower case letter
> >    ./RADIUS-AUTH-CLIENT-MIB:48: [2] {object-identifier-not-prefix}
> >      Object identifier element `TBA' name only allowed as first
> >      element
> 
> These appear to be complaints about the IANA placeholder "TBA".
> 

Yep, I had just quickly pasted the error log into my email.
I did send a follow up email wondering why we
need 2 OID branches under mib-2 at all.

Bert

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 15 Sep 2005 14:56:35 +0000
Content-class: urn:content-classes:message
Subject: RE: REMINDER: Call for review of RFC 2618bis-2621bis
Date: Thu, 15 Sep 2005 10:55:05 -0400
From: "Nelson, David" <[email-masked]>
To: "Wijnen, Bert \(Bert\)" <[email-masked]>, <[email-masked]>

Bert Wijnen writes...

> I also do not understand this
>    radiusMIB OBJECT-IDENTITY
>           STATUS  current
>           DESCRIPTION
>                 "The OID assigned to RADIUS MIB work by the IANA."
>            ::=3D { mib-2 67 }
>=20
>    radiusAuthClientExtMIB OBJECT-IDENTITY
>           STATUS  current
>           DESCRIPTION
>                 "The OID assigned to RADIUS Extensions MIB work by
>                  the IANA."
>            ::=3D { mib-2 TBA }
>=20
>    -- RFC Editor: replace TBA with IANA assigned OID value, and
>    -- remove this note.
>=20
> Why do we need/want 2 OID branches underneath mib-2?
> Why can the extensions not be made just within the
> radiusAuthClientMIB branch itself?

That question was raised and answered at IETF-63.  The answer was that
all MIB extension work was to be rooted directly under MIB-II, as that
is the only registry that IANA controls.  I believe it was Juergen
Schoenwaelder who provided that guidance.  I believe that Dan Romascanu
has given similar advice previously.

Is that not the correct answer?  I tend to think that the approach you
suggest makes more sense, but I was previously corrected for doing it
that way.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 15 Sep 2005 14:50:09 +0000
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: "Nelson, David" <[email-masked]>, [email-masked]
Subject: RE: REMINDER: Call for review of RFC 2618bis-2621bis
Date: Thu, 15 Sep 2005 16:49:50 +0200

Mmmm...

I also do not understand this
   radiusMIB OBJECT-IDENTITY
          STATUS  current
          DESCRIPTION
                "The OID assigned to RADIUS MIB work by the IANA."
           ::= { mib-2 67 }

   radiusAuthClientExtMIB OBJECT-IDENTITY
          STATUS  current
          DESCRIPTION
                "The OID assigned to RADIUS Extensions MIB work by
                 the IANA."
           ::= { mib-2 TBA }

   -- RFC Editor: replace TBA with IANA assigned OID value, and
   -- remove this note.

Why do we need/want 2 OID branches underneath mib-2?
Why can the extensions not be made just within the
radiusAuthClientMIB branch itself?

It seems like there is a lot to be checked.

more below:

> -----Original Message-----
> From: Nelson, David [mailto:[email-masked]]
> Sent: Thursday, September 15, 2005 16:30
> To: Wijnen, Bert (Bert); [email-masked]
> Subject: RE: REMINDER: Call for review of RFC 2618bis-2621bis
> 
> 
> Bert Wijnen writes...
>  
> > So did anyone do MIB SYNTAX checking ...
> 
> I used this tool to check the MIB syntax:
> 
> http://wwwsnmp.cs.utwente.nl/ietf/mibs/validate/
> 

And that tool tells me:

   0     Segmentation Fault 
   48 2 `TBA' should start with a lower case letter 
      2  Object identifier element `TBA' name only allowed as first element 

> > I did a smidiff run that shows the below. I did not yet check,
> > but maybe it helps you as a WG to check.
> 
> I'll take a look at these.  Thanks.
> 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 15 Sep 2005 14:48:16 +0000
Content-class: urn:content-classes:message
Subject: RE: REMINDER: Call for review of RFC 2618bis-2621bis
Date: Thu, 15 Sep 2005 10:47:51 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Bert Wijnen writes...

>   E: f(radiusAuthClient.mi2), (48,24) Sub-Id for item
>      "radiusAuthClientExtMIB" must be "number" or
>      "name(number)" format
>   *** 1 error and 2 warnings in parsing

<snip>

>    ./RADIUS-AUTH-CLIENT-MIB:48: [2] {bad-identifier-case}
>     `TBA' should start with a lower case letter
>    ./RADIUS-AUTH-CLIENT-MIB:48: [2] {object-identifier-not-prefix}
>      Object identifier element `TBA' name only allowed as first
>      element

These appear to be complaints about the IANA placeholder "TBA".

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 15 Sep 2005 14:47:07 +0000
Content-class: urn:content-classes:message
Subject: Issue: RFC 2618bis-2621bis nits
Date: Thu, 15 Sep 2005 10:45:08 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Submitter name: David Nelson
Submitter email address: [email-masked]
Date first submitted: September 15, 2005
Reference: https://psg.com/lists/radiusext/2005/msg00855.html
Document: 2618bis-00 through 2621bis-00
Comment type: 'E'ditorial
Priority: 'S' Must fix
Section: 7, MIB Definitions
Rationale/Explanation of issue:

>   C:\bwijnen\smicng\work>smicng radiusAuthClient.inc
>   W: f(radiusAuthClient.mi2), (29,20) Revision date not in
>      proper order - most recent comes first
>   W: f(radiusAuthClient.mi2), (27,20) The first revision
>      should match the last update for MODULE-IDENTITY
>      radiusAuthClientMIB

Requested change:

Locate the latest revision at the top of the revision history list.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 15 Sep 2005 14:30:49 +0000
Content-class: urn:content-classes:message
Subject: RE: REMINDER: Call for review of RFC 2618bis-2621bis
Date: Thu, 15 Sep 2005 10:29:47 -0400
From: "Nelson, David" <[email-masked]>
To: "Wijnen, Bert \(Bert\)" <[email-masked]>, <[email-masked]>

Bert Wijnen writes...
=20
> So did anyone do MIB SYNTAX checking ...

I used this tool to check the MIB syntax:

http://wwwsnmp.cs.utwente.nl/ietf/mibs/validate/

> I did a smidiff run that shows the below. I did not yet check,
> but maybe it helps you as a WG to check.

I'll take a look at these.  Thanks.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 15 Sep 2005 13:54:03 +0000
Date: Thu, 15 Sep 2005 16:53:57 +0300
From: Jari Arkko <[email-masked]>
To: "Wijnen, Bert (Bert)" <[email-masked]>
CC: Bernard Aboba <[email-masked]>,  "Nelson, David" <[email-masked]>, [email-masked]
Subject: Re: REMINDER: Call for review of RFC 2618bis-2621bis

Ok. Here's the issue entry for Bernard's site:

Must Obsolete Old MIBs
Submitter name: Jari Arkko
Submitter email address: [email-masked]
Date first submitted: September 15th, 2005
Reference: http://ops.ietf.org/lists/radiusext/2005/msg00853.html
Document: 2618-2621bis
Comment type: E
Priority: S
Section: header
Rationale/Explanation of issue:

The document "Updates RFC 2618" but as far as I
can determine, it contains all the objects from 2618
and then adds some. If so, why isn't the designation
"Obsoletes RFC 2618"?

Requested change:

Change this (or these) documents to obsolete their previous
versions, rather just update them. s/Updates 26/Obsoletes 26/

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 15 Sep 2005 13:40:14 +0000
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: Jari Arkko <[email-masked]>, Bernard Aboba <[email-masked]>, "Nelson, David" <[email-masked]>
Cc: [email-masked]
Subject: RE: REMINDER: Call for review of RFC 2618bis-2621bis
Date: Thu, 15 Sep 2005 15:38:24 +0200

In fact, since it uses the same MIB and MODULE-IDENTITY
name and OID, it thereby MUST OBSOLETE RFC2618.

So I agree that it should state: obsoletes RFC2618

Bert

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Jari Arkko
> Sent: Thursday, September 15, 2005 08:54
> To: Bernard Aboba; Nelson, David
> Cc: [email-masked]
> Subject: Re: REMINDER: Call for review of RFC 2618bis-2621bis
> 
> 
> 
> >http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2618
> bis-00.txt
> >  
> >
> I read this. The content seems OK (but I'm not much of an MIB
> expert).
> 
> But I do have a question. The document "updates RFC 2618",
> but as far as I can determine, it contains all the objects from
> 2618 and then adds some. If so, why isn't the designation
> "Obsoletes RFC 2618"?
> 
> --Jari
> 
> 
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 15 Sep 2005 13:40:05 +0000
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: Bernard Aboba <[email-masked]>, [email-masked]
Subject: RE: REMINDER: Call for review of RFC 2618bis-2621bis
Date: Thu, 15 Sep 2005 15:38:25 +0200

I did a very quick check on just the first document.
Inline:

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Bernard Aboba
> Sent: Thursday, September 15, 2005 07:40
> To: [email-masked]
> Subject: REMINDER: Call for review of RFC 2618bis-2621bis
> 
> 
> The revised RADIUS MIB documents are now available on the 
> IETF archive:
> 
> http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2618bis-00.txt

SMICng tells me:

  C:\bwijnen\smicng\work>smicng radiusAuthClient.inc
  W: f(radiusAuthClient.mi2), (29,20) Revision date not in
     proper order - most recent comes first
  W: f(radiusAuthClient.mi2), (27,20) The first revision
     should match the last update for MODULE-IDENTITY
     radiusAuthClientMIB
  E: f(radiusAuthClient.mi2), (48,24) Sub-Id for item
     "radiusAuthClientExtMIB" must be "number" or
     "name(number)" format
  *** 1 error and 2 warnings in parsing

and smilint tells me:

   C:\smi\mibs\work>smilint -m -l 6 -s ./RADIUS-AUTH-CLIENT-MIB
   ./RADIUS-AUTH-CLIENT-MIB:29: [3] {revision-not-descending}
     revision not in reverse chronological order
   ./RADIUS-AUTH-CLIENT-MIB:48: [2] {bad-identifier-case}
    `TBA' should start with a lower case letter
   ./RADIUS-AUTH-CLIENT-MIB:48: [2] {object-identifier-not-prefix}
     Object identifier element `TBA' name only allowed as first
     element

So did anyone do MIB SYNTAX checking and review against the
MIB review guidelines in
    draft-ietf-ops-mib-review-guidelines-04.txt

Further, when you obsolete/update an earlier MIB module with a new
version, then you have to make sure that all changes are legal
according to the rules in the SMI (RFC2578, sect 10, RFC2579, sect 5
and RFC2580, sect 7). Further, the MIB review guidelines also
talk about MIB module revisions in sect 4.9

So the changes need to be carefully evaluated.
I did a smidiff run that shows the below. I did not yet check,
but maybe it helps you as a WG to check.

C:\smi\mibs\work>smidiff ../ietf/RADIUS-AUTH-CLIENT-MIB ./RADIUS-AUTH-CLIENT-MIB
./RADIUS-AUTH-CLIENT-MIB:12 warning: organization of `RADIUS-AUTH-CLIENT-MIB' changed
./RADIUS-AUTH-CLIENT-MIB:12 warning: description of module identity definition `RADIUS-AUTH-CLIENT-MIB' changed
./RADIUS-AUTH-CLIENT-MIB:29 warning: revision `2005-08-30 00:00' added
../ietf/RADIUS-AUTH-CLIENT-MIB:10 info: previous definition of `RADIUS-AUTH-CLIENT-MIB'
./RADIUS-AUTH-CLIENT-MIB:79 warning: legal status change from `current' to `deprecated' for `radiusAuthServerTable'
../ietf/RADIUS-AUTH-CLIENT-MIB:61 info: previous definition of `radiusAuthServerTable'
./RADIUS-AUTH-CLIENT-MIB:88 warning: legal status change from `current' to `deprecated' for `radiusAuthServerEntry'
../ietf/RADIUS-AUTH-CLIENT-MIB:70 info: previous definition of `radiusAuthServerEntry'
./RADIUS-AUTH-CLIENT-MIB:117 warning: legal status change from `current' to `deprecated' for `radiusAuthServerIndex'
../ietf/RADIUS-AUTH-CLIENT-MIB:99 info: previous definition of `radiusAuthServerIndex'
./RADIUS-AUTH-CLIENT-MIB:127 warning: legal status change from `current' to `deprecated' for `radiusAuthServerAddress'
../ietf/RADIUS-AUTH-CLIENT-MIB:109 info: previous definition of `radiusAuthServerAddress'
./RADIUS-AUTH-CLIENT-MIB:136 warning: legal status change from `current' to `deprecated' for `radiusAuthClientServerPortNumber'
../ietf/RADIUS-AUTH-CLIENT-MIB:118 info: previous definition of `radiusAuthClientServerPortNumber'
./RADIUS-AUTH-CLIENT-MIB:145 warning: legal status change from `current' to `deprecated' for `radiusAuthClientRoundTripTime'
../ietf/RADIUS-AUTH-CLIENT-MIB:127 info: previous definition of `radiusAuthClientRoundTripTime'
./RADIUS-AUTH-CLIENT-MIB:171 warning: legal status change from `current' to `deprecated' for `radiusAuthClientAccessRequests'
../ietf/RADIUS-AUTH-CLIENT-MIB:150 info: previous definition of `radiusAuthClientAccessRequests'
./RADIUS-AUTH-CLIENT-MIB:180 warning: legal status change from `current' to `deprecated' for `radiusAuthClientAccessRetransmissions'
../ietf/RADIUS-AUTH-CLIENT-MIB:159 info: previous definition of `radiusAuthClientAccessRetransmissions'
./RADIUS-AUTH-CLIENT-MIB:189 warning: legal status change from `current' to `deprecated' for `radiusAuthClientAccessAccepts'
../ietf/RADIUS-AUTH-CLIENT-MIB:168 info: previous definition of `radiusAuthClientAccessAccepts'
./RADIUS-AUTH-CLIENT-MIB:199 warning: legal status change from `current' to `deprecated' for `radiusAuthClientAccessRejects'
../ietf/RADIUS-AUTH-CLIENT-MIB:177 info: previous definition of `radiusAuthClientAccessRejects'
./RADIUS-AUTH-CLIENT-MIB:208 warning: legal status change from `current' to `deprecated' for `radiusAuthClientAccessChallenges'
../ietf/RADIUS-AUTH-CLIENT-MIB:186 info: previous definition of `radiusAuthClientAccessChallenges'
./RADIUS-AUTH-CLIENT-MIB:220 warning: legal status change from `current' to `deprecated' for `radiusAuthClientMalformedAccessResponses'
./RADIUS-AUTH-CLIENT-MIB:220 warning: description of object definition `radiusAuthClientMalformedAccessResponses' changed
../ietf/RADIUS-AUTH-CLIENT-MIB:198 info: previous definition of `radiusAuthClientMalformedAccessResponses'
./RADIUS-AUTH-CLIENT-MIB:233 warning: legal status change from `current' to `deprecated' for `radiusAuthClientBadAuthenticators'
./RADIUS-AUTH-CLIENT-MIB:233 warning: description of object definition `radiusAuthClientBadAuthenticators' changed
../ietf/RADIUS-AUTH-CLIENT-MIB:211 info: previous definition of `radiusAuthClientBadAuthenticators'
./RADIUS-AUTH-CLIENT-MIB:243 warning: legal status change from `current' to `deprecated' for `radiusAuthClientPendingRequests'
../ietf/RADIUS-AUTH-CLIENT-MIB:221 info: previous definition of `radiusAuthClientPendingRequests'
./RADIUS-AUTH-CLIENT-MIB:257 warning: legal status change from `current' to `deprecated' for `radiusAuthClientTimeouts'
../ietf/RADIUS-AUTH-CLIENT-MIB:234 info: previous definition of `radiusAuthClientTimeouts'
./RADIUS-AUTH-CLIENT-MIB:270 warning: legal status change from `current' to `deprecated' for `radiusAuthClientUnknownTypes'
../ietf/RADIUS-AUTH-CLIENT-MIB:247 info: previous definition of `radiusAuthClientUnknownTypes'
./RADIUS-AUTH-CLIENT-MIB:280 warning: legal status change from `current' to `deprecated' for `radiusAuthClientPacketsDropped'
../ietf/RADIUS-AUTH-CLIENT-MIB:256 info: previous definition of `radiusAuthClientPacketsDropped'
./RADIUS-AUTH-CLIENT-MIB:566 warning: legal status change from `current' to `deprecated' for `radiusAuthClientMIBGroup'
../ietf/RADIUS-AUTH-CLIENT-MIB:292 info: previous definition of `radiusAuthClientMIBGroup'
./RADIUS-AUTH-CLIENT-MIB:543 warning: legal status change from `current' to `deprecated' for `radiusAuthClientMIBCompliance'
../ietf/RADIUS-AUTH-CLIENT-MIB:279 info: previous definition of `radiusAuthClientMIBCompliance'

Bert

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 15 Sep 2005 08:34:48 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue 101: WG Last Call Review
Date: Thu, 15 Sep 2005 11:33:30 +0300
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>

[email-masked] wrote:

> > There's no need to imagine all things that could happen if a=20
> > RADIUS server is compromised, but it is IMHO necessary to at=20
> > least briefly discuss how implementing _this_ document=20
> > changes the existing situation.
> >=20
> > Maybe something like this:
> >=20
>=20
> I'm assuming the text you provided would be in addition to what is
> already there?  Below, I've merged  your text into the=20
> existing text as an entirely new Security section.=20

No, the text was intended as a replacement of what's already there.

The existing text is IMHO unnecessary because it doesn't describe any
security considerations of _this_ document. I don't think we need
to repeat what's already said in RFC 2865 and 3579 in every document
that defines a new RADIUS attribute: we just need to describe what
new security considerations this document has (in addition to
those already adequately described in 2865/3579).

Best regards,
Pasi

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 15 Sep 2005 06:53:49 +0000
Date: Thu, 15 Sep 2005 09:53:30 +0300
From: Jari Arkko <[email-masked]>
To: Bernard Aboba <[email-masked]>,  "Nelson, David" <[email-masked]>
CC:  [email-masked]
Subject: Re: REMINDER: Call for review of RFC 2618bis-2621bis

>http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2618bis-00.txt
>  
>
I read this. The content seems OK (but I'm not much of an MIB
expert).

But I do have a question. The document "updates RFC 2618",
but as far as I can determine, it contains all the objects from
2618 and then adds some. If so, why isn't the designation
"Obsoletes RFC 2618"?

--Jari

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 15 Sep 2005 05:41:06 +0000
Date: Wed, 14 Sep 2005 22:40:24 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: REMINDER: Call for review of RFC 2618bis-2621bis

The revised RADIUS MIB documents are now available on the IETF archive:

http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2618bis-00.txt
http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2619bis-00.txt
http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2620bis-00.txt
http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2621bis-00.txt

Please send review comments to the RADEXT mailing list by September 17, 
2005, using the format described on the RADEXT WG Issues list:
http://www.drizzle.com/~aboba/RADEXT/

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 15 Sep 2005 05:40:17 +0000
Date: Wed, 14 Sep 2005 22:38:58 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: REMINDER:  Review comments on RFC 3576 MIBs

So far, the RFC 3576 MIBs have received only a few comments. 

In order to advance this document, we will need to get more affirmative 
response that WG participants have read it. 

If you have read the documents and believe they are ok, please post this 
indication to the RADEXT WG list. 

If you have read the documents and have an issue with them, please post 
the issue to the RADEXT WG list in the format described on the RADEXT WG 
web page:
http://www.drizzle.com/~aboba/RADEXT/

If you have not read the documents, please do so NOW:
http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-client-mib-01.txt
http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-server-mib-01.txt

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 14 Sep 2005 18:30:54 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue 101: WG Last Call Review
Date: Wed, 14 Sep 2005 11:29:54 -0700
From: "Congdon, Paul T (ProCurve)" <[email-masked]>
To: <[email-masked]>, <[email-masked]>

I deleted some stuff to focus on the three items:
=20
>=20
> Egress-VLANID doesn't necessarily need any special code in=20
> the management interface if it supports entering hexadecimal=20
> numbers (e.g. tagged VID 6 could be entered as 0x01000006).
>=20
> And VLAN-Name attribute already uses 8 bits to represent=20
> these two values; changing that from 0x01/0x02 to, say,=20
> 0x31/0x32 wouldn't use anything more... (and would not=20
> prevent us from defining value values later any more than=20
> 0x01/0x02 does)

Ok.  I'd still like to keep the attributes as similar as possible, so I
propose we also change the value of tagged and untagged to 0x31 and 0x32
in the Egress-VLANID attribute as well.  Thus, your example above of
tagged VID 6 would be entered as 0x31000006.

>=20
> I don't think significant changes are needed; basically, only=20
> a couple of small changes would clarify the document significantly.
> The most important ones would IMHO be:
>=20
> - combining the two figures in 3.1
>=20
> - fixing the figure in 4.1 (explicitly show that the attribute
>   contains both a 64-bit counter and a string according to
>   NAS-Filter-Rule; calling the counter a part of the string
>   is misleading, since it doesn't even consist of printable
>   characters...)
>=20
> - Add figure to section 3.3 (explicitly showing that the
>   attribute contains two different items)
>

Ok, this isn't too bad, we can make these specific changes.
=20
>=20
> There's no need to imagine all things that could happen if a=20
> RADIUS server is compromised, but it is IMHO necessary to at=20
> least briefly discuss how implementing _this_ document=20
> changes the existing situation.
>=20
> Maybe something like this:
>=20

I'm assuming the text you provided would be in addition to what is
already there?  Below, I've merged  your text into the existing text as
an entirely new Security section.=20

How about the following:

7.  Security Considerations=20
   =20
      Since this document describes the use of RADIUS for purposes of=20
      authentication, authorization, and accounting in IEEE 802.1X-
      enabled networks, it is vulnerable to all of the threats that are=20
      present in other RADIUS applications. For a discussion of these=20
      threats, see [RFC2607], [RFC2865], [RFC3162], [RFC3576],=20
      [RFC3579], and [RFC3580].=20
   =20
      Vulnerabilities include:=20
   =20
      Packet modification or forgery=20
      Dictionary attacks=20
      Known plaintext attacks=20
      Compromised RADIUS Server or Proxy
   =20
   7.1.  Packet Modification or Forgery=20
   =20
      As noted in [RFC3580], when used with IEEE 802.1X, all RADIUS=20
      packets MUST be authenticated and integrity protected.  In=20
      addition, as described in [RFC3579], Section 4.2:=20
   =20
         To address the security vulnerabilities of RADIUS/EAP,=20
         implementations of this specification SHOULD support IPsec=20
         [RFC2401] along with IKE [RFC2409] for key management. IPsec=20
         ESP [RFC2406] with non-null transform SHOULD be supported, and=20
         IPsec ESP with a non-null encryption transform and=20
         authentication support SHOULD be used to provide per-packet=20
         confidentiality, authentication, integrity and replay=20
         protection.  IKE SHOULD be used for key management.=20
         =20
   7.2.  Dictionary Attacks=20
   =20
      As discussed in [RFC3579] Section 4.3.3, the RADIUS shared secret=20
      is vulnerable to offline dictionary attack, based on capture of=20
      the Response Authenticator or Message-Authenticator attribute.  In

      order to decrease the level of vulnerability, [RFC2865], Section 3

      recommends:=20
         =20
         The secret (password shared between the client and the RADIUS

         server) SHOULD be at least as large and unguessable as a well-

         chosen password.  It is preferred that the secret be at least=20
         16 octets.=20
         =20
         In addition, the risk of an offline dictionary attack can be=20
         further mitigated by employing IPsec ESP with non-null=20
         transform in order to encrypt the RADIUS conversation, as=20
         described in [RFC3579], Section 4.2.=20
         =20
   7.3.  Known Plaintext Attacks=20
   =20
      Since IEEE 802.1X is based on EAP, which does not support PAP, the

      RADIUS User-Password attribute is not used to carry hidden user=20
      passwords. The hiding mechanism utilizes MD5, defined in=20
      [RFC1321], in order to generate a key stream based on the RADIUS=20
      shared secret and the Request  Authenticator.  Where PAP is in=20
      use, it is possible to collect key streams corresponding to a=20
      given Request Authenticator value, by capturing RADIUS=20
      conversations corresponding to a PAP authentication attempt using=20
      a known password. Since the User-Password is known, the key stream

      corresponding to a given Request Authenticator can be determined=20
      and stored.=20
   =20
      The vulnerability is described in detail in [RFC3579], Section=20
      4.3.4. Even though IEEE 802.1X Authenticators do not support PAP

      authentication, a security vulnerability can still exist where the

      same RADIUS shared secret is used for hiding User-Password as well

      as other attributes.  This can occur, for example, if the same=20
      RADIUS proxy handles authentication requests for both IEEE 802.1X=20
      (which may hide the Tunnel-Password, MS-MPPE-Send-Key and MS-MPPE-
      Recv-Key attributes) and GPRS (which may hide the User-Password=20
      attribute).=20
   =20
      The threat can be mitigated by protecting RADIUS with IPsec ESP=20
      with non-null transform, as described in [RFC3579], Section 4.2. =20
      In addition, the same RADIUS shared secret MUST NOT used for both=20
      IEEE 802.1X authentication and PAP authentication.=20

   7.4 Compromised RADIUS Server or Proxy

      This documents specifies new attributes that can be included
      in existing RADIUS messages. These messages are protected
      using existing security mechanisms; see [RFC2865] and
      [RFC3576] for a more detailed description and related security
      considerations.
 =20
      The security mechanisms in [RFC2865] and [RFC3576] are
      primarily concerned with an outside attacker who modifies
      messages in transit or inserts new messages. They do not
      prevent an authorized RADIUS server or proxy from inserting
      attributes with a malicious purpose in message it sends.
   =20
      An attacker who compromises an authorized RADIUS server or
      proxy can use the attributes defined in this document to
      influence the behavior of the NAS in ways that previously may
      not have been possible. For example, modifications to the=20
      VLAN-related attributes may cause the NAS to permit access to
      other VLANs that were intended. To give another example,
      inserting suitable redirection rules to the NAS-Filter-Rule
      attribute may allow the attacker to eavesdrop or modify
      packets sent by a legitimate client.
 =20
      In general, the NAS cannot know whether the attribute values
      it receives from an authenticated and authorized server are
      well-intentioned or malicious, and thus it is not possible to
      completely protect against attacks by compromised nodes. In
      some cases, the extent of the possible attacks can be limited
      by performing more fine-grained authorization checks at the NAS.=20
      For instance, a NAS could be configured to accept only certain
      VLAN IDs from a certain RADIUS server/proxy, or not to accept
      any redirection rules if it is known they are not used in
      this environment.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 14 Sep 2005 10:54:04 +0000
Date: Wed, 14 Sep 2005 12:53:45 +0200
From: Emile van Bergen <[email-masked]>
To: "Nelson, David" <[email-masked]>
Cc: [email-masked]
Subject: Re: Hints and End-to-End capabilities
Mail-Followup-To: "Nelson, David" <[email-masked]>, [email-masked]

Hi,

On Tue, Sep 13, 2005 at 10:47:42AM -0400, Nelson, David wrote:

> Emile van Bergen writes...
> 
> > Other than backwards compatibility, the hints mechanism has another
> > advantage: it can allow the home AAA to discover the capabilities of
> > the whole chain, because proxies can, and often unintendedly do,
> > indicate their policies with respect to response attribute filtering
> > by performing request attribute filtering in the same way.
> 
> Yes.  It seems that the attribute filtering behavior of proxy servers
> varies widely, so it would need to be taken into account in any
> end-to-end scenario.  Adding a new attribute that contains the
> aggregated capabilities advertisement from the NAS would seem to be of
> little use in proxy chairs where at least one proxy server edits out
> attributes that it doesn't understand (implement).

It /is/ useful. The scenario is this.

a. the home AAA assumes that from its response, nothing but the Code
field (Accept or Reject) will eventually be acted upon by the NAS,
UNLESS

b. it has knowledge, a priori, from hints or a bitmap attribute, that
first, the NAS will act upon certain attributes, and second, the proxy
chain will pass along those attributes.

So if a proxy removes the the capabilities bitmap attribute from the
request, then the result is actually correct: the home AAA may make no
assumptions with respect to the set of response attributes that will be
passed resp. acted upon.

The problem is the reverse: a proxy may pass on unknown request
attributes (incl. the bitmap), but filter all response attributes other
than a well defined set.

> > Looking at all that, the dedicated bitmap attribute seems better:
> > the proxy can clear bits that correspond to attributes it doesn't
> > allow the home AAA to set, without filtering required request
> > attributes.
> 
> Unless, of course, one proxy in the chain decides to filter out the
> new bitmap attribute that it does not understand.  This sort of
> behavior severely hampers the intended forward compatibility
> proposition of RADIUS.  It would be well to understand if this is a
> prevalent practice.

What I've seen most often is this.

Proxies generally divide upstream AAAs into two categories: servers from
which all response attributes are accepted, and servers from which only
a certain minimal set is accepted.

Sometimes the attribute sets for each of the two home AAA categories can
be defined by the administator.

The behaviour with respect to request attributes varies. Many local
access operators don't want details of their network to leak to the
party with the users database, and will only send the bare minimum set
demanded by the party running the home AAA.

I've always advised customers NOT to provide parties like iPass or GRIC
with a free market survey on who runs what brands of NASes and in what
quantity.

> > On the other hand, there will be proxies that will filter response
> > attributes but that do not (yet) know about the
> > NAS-will-heed-bitmap.  And those will still cause access accepts to
> > be received by the NAS that are less restricted than the home AAA
> > intended them to be.
> 
> I think the issue you are raising is that, in some proxy deployments,
> the notion of end-to-end capabilities advertisement may be a fiction.
> When proxies filter unknown attributes, it quickly degenerates to a
> series of hop-by-hop capabilities advertisements.

Which is what I /want/. End-to-end (ignoring proxy policy) is useless.
The problem is proxies /not/ indicating their filtering policy, by /not/
editing the request.

The idea is that the NAS indicates an initial set of attributes, and the
proxies only subtract from that set, so that the home AAA will know the
set of attributes that WILL be acted upon by the NAS.

> > At any rate, I think that
> > 'NAS-through-proxies-will-obey-attribute-X' advertisements are the
> > only capability advertisements that really add something to the
> > protocol.
> 
> Agreed.  The difference between a single bitmap attribute and a
> collection of hint attributes instances is PDU encoding efficiency.  I
> would argue, however, that if hints cannot be made to work reliably in
> a given proxy chain scenario, then the bitmap attribute will similarly
> fail. 

It depends on the policy change that's easier to mandate. It's either

a. require a proxy operator NOT to pass on request attributes that it does
not intend to pass on from the response (impossible for some attributes)

b. require a proxy operator NOT to pass on a Capabilities-Bitmap
attribute as-is if it filters any attributes from the response (breaks
backward compatibility).

Because if neither requirement is obeyed, the home AAA will get a false
positive, and think that the NAS will receive and act upon a certain
(session limiting) attribute, while it will not.

Of course, the only way to give the home AAA a GUARANTEE that the user
only gets service IF the NAS receives AND acts upon a certain set of
attributes, is an alternative I've also considered and rejected, by
proposing a new value for the Code field, Conditional-Accept.

Such a Conditional-Accept MUST include a bitmap attribute containing the
list of attributes (by number, not position) that MUST be heeded by each
proxy and the NAS in order to interpret the Conditional-Accept as an
Accept.

However, this has the problem of requiring standards action and goes
against the RADIUS philosophy of the serverwhat I expressed in the
paragraph you quoted. not publising policy, only providing final
decisions. 

Also, proxies and NASes that do not support Conditional-Accept, will
silently discard the response (as required by RFC2865, see Section 3),
instead of treating it as a reject, causing needless request
retransmits. So as far as I'm concerned, that option is out.

So that means no ABSOLUTE guarantees at the home AAA while there are
proxies in the field that don't indicate their filtering policy in the
hints/capabilties in the request they pass on, but I think it's the only
way to get there.

The only thing you need at some point is for a home AAA operator to
require his downstreams to run capability-compliant proxies, that is,
proxies that perform the AND operation correctly, ie. only keep those
bits set that correspond to attributes it will forward, and clear all
the others.

> > The whole idea with RADIUS is offloading policy to a central place,
> > by asking the server about each individual session that's about to
> > take place. And you only even get to see a user's policy if you
> > supply that user's credentials. No pushing or publishing of parts of
> > it up front.  That's an aspect of RADIUS that should remain
> > unchanged, I think. It makes security analysis so much easier.
> 
> Saying this another way, RADIUS has always been about what the Server
> wants the NAS to do.  NASes have been seen as simple and obedient.
> Dynamic RADIUS has changed this, to the extent that the NAS can be
> take on the "server" role for CoA.  The introduction of the notion
> that the NAS may have policy requirements of the Server is entirely
> new to RADIUS.

I don't know if a NAS may have policy requirements from the server. If a
server sends a CoA or Disconnect request to a NAS, the NAS will send a
response as defined in the relevant standards drafts, and it's up to the
server to decide what to do with it.

I see no behaviour at the NAS that's conditional on dynamic knowledge
about the RADIUS server. Which is good, that should /not/ change, in my
opinion.

Kind regards,

Emile

-- 
E-Advies - Emile van Bergen           [email-masked]      
tel. +31 (0)78 6136282           http://www.e-advies.nl    

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 14 Sep 2005 10:46:31 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue 101: WG Last Call Review
Date: Wed, 14 Sep 2005 13:45:12 +0300
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>

[email-masked] wrote:

> [pc] Here are some proposed resolutions to Pasi's Issue 101 WG=20
> review comments:

I'm happy with most of these proposals; see comments below
for the rest...

> 6) Section 3.3: Using "START OF HEADING" (0x01) and "START OF
> TEXT" (0x02) control characters to indicate tagged/untagged
> might make it unnecessarily difficult to enter this attribute
> in a management interface... maybe something like 0x74/0x75
> ("t"/"u") or 0x31/0x32 ("1"/"2") would be easier?
>=20
> [pc] We were trying to get Egress-VLANID and (now called)
> Egress-VLAN-Name to have as similar a format as possible.
> While Egress-VLAN-Name could be made to be an all text type of
> management interface, Egress-VLANID can not.  The VLANID is a
> simple 12-bit number and won't map well to the keyboard input
> optimization no matter what we do, so some form of special
> formatting for the management interface will be required to
> support these two attributes.  Also, tagged and untagged are
> the only flags we need today, but perhaps this field would
> need to be extended someday (e.g. 802.1ad support), and using
> more bits to represent the two values needed today would seems
> to be wasteful.  I propose no change here.

Egress-VLANID doesn't necessarily need any special code in the
management interface if it supports entering hexadecimal numbers
(e.g. tagged VID 6 could be entered as 0x01000006).

And VLAN-Name attribute already uses 8 bits to represent these
two values; changing that from 0x01/0x02 to, say, 0x31/0x32
wouldn't use anything more... (and would not prevent us from
defining value values later any more than 0x01/0x02 does)

> 9) A comment about the bit figures in Section 3 and 4.
> Currently, all the figures are basically identical: they
> contain the RADIUS Type and Length fields, plus one other
> field (variably called either "Integer", "String" or "Text").
> The contents of this field are then described in English.
>=20
> I think it would be much more understandable if the figure also showed
> the structure. For instance, instead of this (Section 3.1),
>=20
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
> |     Type      |    Length     |            Integer         =20
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
> |        Integer(cont.)         | =20
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
>=20
> this would IMHO be more readable:
>=20
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
> |     Type      |    Length     |   Tag Option  |     (zero)  =20
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
>  (zero) |   VLANID (12 bits)    | =20
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
>
> (Note that I'm not proposing changing the attribute formats at
> all -- so no changes to any software --, just how they are
> presented in the document. And we can keep all the zero
> padding there if we want...)
>
> [pc] To make this clean and follow your recommendation I
> believe it has significant structural changes to the document.
> Most of the attributes do not have diagrams at all.  There
> would need to be a lot of new ASCII art added and it would be
> difficult for string based fields like NAS-Filter-Rule to
> accommodate this.  If we put all the internal field names in
> the base attribute diagram along with Type and Length, it
> would seem that we would need to describe each of the other
> fields individually rather than indicating how to format the
> Integer, Text or String portion.  I'd rather keep the bulk of
> the attribute sections intact and only provide a diagram
> describing how to format the Integer, Text or String porition
> - as is done in 3.1.  We could certainly make 3.2, 3.3 and 3.4
> more consistent with 3.1 and add a diagram on how to format
> the Integer, Text and/or String component.  Would this work?

I don't think significant changes are needed; basically, only
a couple of small changes would clarify the document significantly.
The most important ones would IMHO be:

- combining the two figures in 3.1

- fixing the figure in 4.1 (explicitly show that the attribute
  contains both a 64-bit counter and a string according to=20
  NAS-Filter-Rule; calling the counter a part of the string
  is misleading, since it doesn't even consist of printable
  characters...)

- Add figure to section 3.3 (explicitly showing that the=20
  attribute contains two different items)

> 11) Section 7: It looks like this security considerations
> section was just copied from somewhere without much thought
> for how well it actually applies to this document. Most of the
> text looks redundant to me; we don't need to describe how to
> use IPsec with RADIUS in every document that defines a new
> RADIUS attribute.
>=20
> On the other hand, there's exactly zero discussion about new
> threats caused by the attributes defined in _this_ document.
> And to me it looks like there are new attacks that e.g. a
> malicious or compromised RADIUS server or proxy could do with
> these attributes (compared to the situation where NAS does not
> support these attributes).  At least Egress-VLANID,
> Ingress-Filters and NAS-Filter-Rule have some pretty obvious
> possibilities for abuse... (and maybe some non-obvious as
> well)
>=20
> [pc] Yes, much of this text was copied from 3580, but short of
> trying to imagine all the things that could happen if a RADIUS
> server is comprimized, I'm not sure what else to put here.  We
> could puts some words here about how modified settings of
> things like Ingress-Filters or Filter-Rules could change the
> expected behavior, but the discussion would not be exhaustive.
> I thought the point of this section was to document what the
> vulnerabilities are, not how they might be used.  For example,
> the scheme is vulnerable to packet modification attacks, but
> we can't document what might happen with every possible
> modification of a packet.  Please provide some more
> explanation or examples of what you are looking for here.

There's no need to imagine all things that could happen if a
RADIUS server is compromised, but it is IMHO necessary to at
least briefly discuss how implementing _this_ document changes
the existing situation.

Maybe something like this:
=20
  This documents specifies new attributes that can be included
  in existing RADIUS messages. These messages are protected
  using existing security mechanisms; see [RFC2865] and
  [RFC3576] for a more detailed description and related security
  considerations.

  The security mechanisms in [RFC2865] and [RFC3576] are
  primarily concerned with an outside attacker who modifies
  messages in transit or inserts new messages. They do not
  prevent an authorized RADIUS server or proxy from inserting
  attributes with a malicious purpose in messagse it sends.

  An attacker who compromises an authorized RADIUS server or
  proxy can use the attributes defined in this document to
  influence the behavior of the NAS in ways that previously may
  not have been possible. For example, modifications to the
  VLAN-related attributes may cause the NAS to permit access to
  other VLANs that were intended. To give another example,
  inserting suitable redirection rules to the NAS-Filter-Rule
  attribute may allow the attacker to eavesdrop or modify
  packets sent by a legitimate client.

  In general, the NAS cannot know whether the attribute values
  it receives from an authenticated and authorized server are=20
  well-intentioned or malicious, and thus it is not possible to=20
  completely protect against attacks by compromised nodes. In=20
  some cases, the extent of the possible attacks can be limited=20
  by performing more fine-grained authorization checks at the NAS.=20
  For instance, a NAS could be configured to accept only certain=20
  VLAN IDs from a certain RADIUS server/proxy, or not to accept
  any redirection rules if it is known they are not used in=20
  this environment.

Best regards,
Pasi

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 13 Sep 2005 17:04:53 +0000
Content-class: urn:content-classes:message
Subject: Issue 101: WG Last Call Review
Date: Tue, 13 Sep 2005 10:04:14 -0700
From: "Congdon, Paul T (ProCurve)" <[email-masked]>
To: <[email-masked]>, <[email-masked]>

[pc] Here are some proposed resolutions to Pasi's Issue 101 WG review
comments:

Overall impression: NAS/QoS-Filter-Rule part is quite messy, other parts
are reasonably OK. I'll send my comments about NAS-Filter-Rule in a
separate email.

1) Section 1.1 contains some unnecessary terminology that is not used
anywhere later in the document: "Access Point (AP)", "Association",
"Port Access Entity (PAE)", "Station (STA)"

[pc] - agreed, to be removed.

2) Section 2.2: "If accounting is enabled on the NAS, it MUST generate
an Accounting-Request (Stop) message upon session termination."

So the NAS must send a Stop message, even though it has not sent a Start
message for this session yet? RFC 2866 seems suggest that a session
always has a Start message before Stop, but does not seem to outright
prohibit sending a stand-alone Stop message. Is this a common practice,
or are there any problems associated with it?

[pc] I believe that this should not cause any problem, but to be honest,
we could use some input from others.  I'm aware of some implementations
that send a start and then immediately follow with a stop, but this
could be more resource intensive than needed.  The stop without a start
would either be ignored by the server or appropriately acknowledge the
termination of the session that didn't start.  This could be useful for
diagnostic purposes.  I'd love to hear from other Radius vendors as to
whether this would be a problem or not.  Again, my assumption is that it
isn't.

3) Section 3.1: 802.1Q does not use the abbreviation "VLANID"
but rather "VID". Should this document also follow that convention?
(but maybe VLANID is more understandable)

[pc] Yes, 802.1Q most often uses VID for VLAN Identifier. It sometimes
uses VLAN ID (with a space).  However, RFC 3580 uses VLANID and since
this document is most likely used in conjunction with RFC 3580, I
suggest we just leave VLANID as is.=20

4) Section 3.1: "Padding bits SHOULD be 0 (zero)." Why "SHOULD"
instead of "MUST"? (according to RFC 2119, it would mean there are valid
reasons to send something else in some circumstances?) (This same issue
occurs also in Section 4.2.)

[pc] This can be changed to MUST.  The desired behavior, IMO, is to
require the bits to be set to 0, but not require them to be checked on
receipt.  The simple MUST or SHOULD wording doesn't really reflect this,
so it is probably best that we make this a MUST.  Agree to change this
SHOULD to a MUST here and in 4.2=20

5) Section 3.3: If VLAN-Name has basically the same meaning as
Egress-VLANID, IMHO their names should reflect this. Perhaps
"Egress-VLAN-Name"?

[pc] Sure, no objection.  Change the name of the VLAN-Name attribute to
Egress-VLAN-Name everywhere in the document.

6) Section 3.3: Using "START OF HEADING" (0x01) and "START OF TEXT"
(0x02) control characters to indicate tagged/untagged might make it
unnecessarily difficult to enter this attribute in a management
interface... maybe something like 0x74/0x75
("t"/"u") or 0x31/0x32 ("1"/"2") would be easier?

[pc] We were trying to get Egress-VLANID and (now called)
Egress-VLAN-Name to have as similar a format as possible.  While
Egress-VLAN-Name could be made to be an all text type of management
interface, Egress-VLANID can not.  The VLANID is a simple 12-bit number
and won't map well to the keyboard input optimization no matter what we
do, so some form of special formatting for the management interface will
be required to support these two attributes.  Also, tagged and untagged
are the only flags we need today, but perhaps this field would need to
be extended someday (e.g. 802.1ad support), and using more bits to
represent the two values needed today would seems to be wasteful.  I
propose no change here.

7) Section 3.3: Probably should have reference to UTF-8? [RFC3629]

[pc] yes, Add a reference to [RFC3629] here and then a formal reference
in section 8.

8) Section 3.4: "The table, expressed as an 8 octet string, maps the
incoming priority (if one exists - the default is 0) into one of seven
regenerated priorities." If the regenerated priority is an integer in
range 0-7, should that be "eight regenerated priorities"?

[pc] yes, change to "eight regenerated priorities"

9) A comment about the bit figures in Section 3 and 4.=20
Currently, all the figures are basically identical: they contain the
RADIUS Type and Length fields, plus one other field (variably called
either "Integer", "String" or "Text").=20
The contents of this field are then described in English.

I think it would be much more understandable if the figure also showed
the structure. For instance, instead of this (Section 3.1),

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
|     Type      |    Length     |            Integer         =20
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
|        Integer(cont.)         | =20
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20

this would IMHO be more readable:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
|     Type      |    Length     |   Tag Option  |     (zero)  =20
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
 (zero) |   VLANID (12 bits)    | =20
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20

(Note that I'm not proposing changing the attribute formats at all -- so
no changes to any software --, just how they are presented in the
document. And we can keep all the zero padding there if we want...)

[pc] To make this clean and follow your recommendation I believe it has
significant structural changes to the document.  Most of the attributes
do not have diagrams at all.  There would need to be a lot of new ASCII
art added and it would be difficult for string based fields like
NAS-Filter-Rule to accommodate this.  If we put all the internal field
names in the base attribute diagram along with Type and Length, it would
seem that we would need to describe each of the other fields
individually rather than indicating how to format the Integer, Text or
String portion.  I'd rather keep the bulk of the attribute sections
intact and only provide a diagram describing how to format the Integer,
Text or String porition - as is done in 3.1.  We could certainly make
3.2, 3.3 and 3.4 more consistent with 3.1 and add a diagram on how to
format the Integer, Text and/or String component.  Would this work? =20

10) Section 5: If the semantics of Acct-EAP-Auth-Method are identical to
Diameter EAP (as Section 4.2 claims), then it can also be included in
Access-Accept messages. (Or if it can't, then the semantics are not
identical, and need to be described in this document.)

[pc] agreed, but I believe this attribute is going to be removed from
the draft per issue 114.

11) Section 7: It looks like this security considerations section was
just copied from somewhere without much thought for how well it actually
applies to this document. Most of the text looks redundant to me; we
don't need to describe how to use IPsec with RADIUS in every document
that defines a new RADIUS attribute.

On the other hand, there's exactly zero discussion about new threats
caused by the attributes defined in _this_ document.
And to me it looks like there are new attacks that e.g. a malicious or
compromised RADIUS server or proxy could do with these attributes
(compared to the situation where NAS does not support these attributes).
At least Egress-VLANID, Ingress-Filters and NAS-Filter-Rule have some
pretty obvious possibilities for abuse... (and maybe some non-obvious as
well)

[pc] Yes, much of this text was copied from 3580, but short of trying to
imagine all the things that could happen if a RADIUS server is
comprimized, I'm not sure what else to put here.  We could puts some
words here about how modified settings of things like Ingress-Filters or
Filter-Rules could change the expected behavior, but the discussion
would not be exhaustive.  I thought the point of this section was to
document what the vulnerabilities are, not how they might be used.  For
example, the scheme is vulnerable to packet  modification attacks, but
we can't document what might happen with every possible modification of
a packet.  Please provide some more explanation or examples of what you
are looking for here.=20

12) References: Both 802.1Q and .1D look normative to me, but
RFC1321 and 802.11i probably are just informative.

[pc] agreed.  Swap these reference locations.

13) References: Document cites [DiamEAP] and [NASREQ], but they're not
included in the references section. Both are normative.

[pc] agreed.  Add these references.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 13 Sep 2005 14:49:05 +0000
Content-class: urn:content-classes:message
Subject: RE: Hints and End-to-End capabilities
Date: Tue, 13 Sep 2005 10:47:42 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Emile van Bergen writes...

> Other than backwards compatibility, the hints mechanism has another
> advantage: it can allow the home AAA to discover the capabilities of
the
> whole chain, because proxies can, and often unintendedly do, indicate
> their policies with respect to response attribute filtering by
> performing request attribute filtering in the same way.

Yes.  It seems that the attribute filtering behavior of proxy servers
varies widely, so it would need to be taken into account in any
end-to-end scenario.  Adding a new attribute that contains the
aggregated capabilities advertisement from the NAS would seem to be of
little use in proxy chairs where at least one proxy server edits out
attributes that it doesn't understand (implement).

> However, there are cases it may be undesireable for a proxy to filter
an
> attribute from a request that it does intend to filter from any
> response. Attributes that are required in access requests or that only
> make sense in those will be among them.

Agreed.
=20
> Looking at all that, the dedicated bitmap attribute seems better: the
> proxy can clear bits that correspond to attributes it doesn't allow
the
> home AAA to set, without filtering required request attributes.

Unless, of course, one proxy in the chain decides to filter out the new
bitmap attribute that it does not understand.  This sort of behavior
severely hampers the intended forward compatibility proposition of
RADIUS.  It would be well to understand if this is a prevalent practice.

=20
> On the other hand, there will be proxies that will filter response
> attributes but that do not (yet) know about the NAS-will-heed-bitmap.
> And those will still cause access accepts to be received by the NAS
that
> are less restricted than the home AAA intended them to be.

I think the issue you are raising is that, in some proxy deployments,
the notion of end-to-end capabilities advertisement may be a fiction.
When proxies filter unknown attributes, it quickly degenerates to a
series of hop-by-hop capabilities advertisements.

> At any rate, I think that 'NAS-through-proxies-will-obey-attribute-X'
> advertisements are the only capability advertisements that really add
> something to the protocol.

Agreed.  The difference between a single bitmap attribute and a
collection of hint attributes instances is PDU encoding efficiency.  I
would argue, however, that if hints cannot be made to work reliably in a
given proxy chain scenario, then the bitmap attribute will similarly
fail.=20
=20
> The whole idea with RADIUS is offloading policy to a central place, by
> asking the server about each individual session that's about to take
> place. And you only even get to see a user's policy if you supply that
> user's credentials. No pushing or publishing of parts of it up front.
> That's an aspect of RADIUS that should remain unchanged, I think. It
> makes security analysis so much easier.

Saying this another way, RADIUS has always been about what the Server
wants the NAS to do.  NASes have been seen as simple and obedient.
Dynamic RADIUS has changed this, to the extent that the NAS can be take
on the "server" role for CoA.  The introduction of the notion that the
NAS may have policy requirements of the Server is entirely new to
RADIUS.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 13 Sep 2005 14:36:09 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue 133:  State Attribute MUST be included in "Authorize-Only" Requests
Date: Tue, 13 Sep 2005 10:36:11 -0400
From: "Avi Lior" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>

Hi Bernard,

I might be missing something.  A NAS would only have State attribute to
send in an Access-Request Authorize-Only if it received the State
attribute in the COA or DM.

[Note 1] in section 5.44 Table of Attributes in 2865 may also be wrong
since a NAS can only include the State attribute in an Access-Request if
it received one in the Challenge that it is replying to.

So shouldn't it be that:

The NAS MUST include the State attribute in an DM ACK, DM NAK, COA ACK,
COA NAK and Access-Request Authorize-Only message if it received the
State attribute in the COA or DM message.

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Monday, September 12, 2005 11:10 PM
> To: [email-masked]
> Subject: Issue 133: State Attribute MUST be included in=20
> "Authorize-Only" Requests
>=20
> Issue 133: State Attribute MUST be included in=20
> "Authorize-Only" Requests Submitter name: Bernard Aboba=20
> Submitter email address: [email-masked] Date first=20
> submitted: September 12, 2005
> Reference: http://ops.ietf.org/lists/radiusext/2005/msg00842.html
> Document: RFC3576bis
> Comment type: T
> Priority: S
> Section: Various
> Rationale/Explanation of issue:
>=20
> RFC 2865 Section 4.1 says:
>=20
> "An Access-Request MUST contain either a User-Password or a=20
> CHAP-Password or a State."
>=20
> This statement is subsequently updated in other RADIUS RFCs=20
> to also include additional authentication attributes (e.g.=20
> EAP-Message or Digest attributes).  However, the statement
> remains: an Access-Request without authentication attributes=20
> MUST include a State attribute.=20
>=20
> Since an Access-Request with Service-Type "Authorization-Only"
> does not include authentication attributes, under RFC 2865,=20
> this message is illegal unless a State attribute is included.=20
>=20
> RFC 3576 indicates that 0-1 State attributes may be included=20
> in CoA or Disconnect Request, ACK or NAK messages, and RFC=20
> 3576 Section 3.2, Note 7 describes the use of the State
> attribute:
>=20
>    [Note 7] The State Attribute is available to be sent by the RADIUS
>    server to the NAS in a Disconnect-Request or CoA-Request=20
> message and
>    MUST be sent unmodified from the NAS to the RADIUS server in a
>    subsequent ACK or NAK message.  If a Service-Type Attribute with
>    value "Authorize Only" is included in a Disconnect-Request or CoA-
>    Request along with a State Attribute, then the State Attribute MUST
>    be sent unmodified from the NAS to the RADIUS server in=20
> the resulting
>    Access-Request sent to the RADIUS server, if any.  The State
>    Attribute is also available to be sent by the RADIUS server to the
>    NAS in a CoA-Request that also includes a Termination-Action
>    Attribute with the value of RADIUS-Request.  If the client performs
>    the Termination-Action by sending a new Access-Request upon
>    termination of the current session, it MUST include the State
>    Attribute unchanged in that Access-Request.  In either usage, the
>    client MUST NOT interpret the Attribute locally.  A Disconnect-
>    Request or CoA-Request packet must have only zero or one State
>    Attribute.  Usage of the State Attribute is implementation=20
> dependent.
>    If the RADIUS server does not recognize the State Attribute in the
>    Access-Request, then it MUST send an Access-Reject.
>=20
> However, RFC 3576 does not state that a State attribute is=20
> REQUIRED in a Disconnect or CoA-Request with Service-Type =3D=20
> "Authorize Only", nor does it state that an Access-Request=20
> with Service-Type =3D "Authorize Only"
> MUST include a State attribute.=20
>=20
> --
> to unsubscribe send a message to=20
> [email-masked] with the word 'unsubscribe' in=20
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 13 Sep 2005 09:41:15 +0000
Date: Tue, 13 Sep 2005 11:40:38 +0200
From: Emile van Bergen <[email-masked]>
To: Bernard Aboba <[email-masked]>
Cc: [email-masked]
Subject: Re: Clarification on RFC3576: Must Proxy-State be copied by the NAS? (fwd)
Mail-Followup-To: Bernard Aboba <[email-masked]>, [email-masked]

Hi,

I completely agree -- the NAS has server role in this exchange, and just
like Proxy-State MUST be echoed by the server for Access-Request and
Accounting-Request packets, it MUST be echoed by the NAS for
Disconnect-Request (and other RFC3576 messages where the NAS functions
as the server), for exactly the same reasons.

The situation seems quite symmetrical to me.

Cheers,

Emile.

On Mon, Sep 12, 2005 at 07:14:26PM -0700, Bernard Aboba wrote:

> 
> -----Original Message-----
> From: Jim Martin [mailto:[email-masked]] 
> Sent: Monday, September 12, 2005 3:57 AM
> To: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; Bernard Aboba
> Subject: Clarification on RFC3576: Must Proxy-State be copied by the
> NAS?
> 
> Gentlepeople,
>      I have a question regarding RFC3576, specifically the behavior  
> of the Proxy-State attribute when contained in a Disconnect Message.  
> Fundamentally, the question is, if a Disconnect-Request is received  
> by a NAS which contains a Proxy-State, MUST the NAS  copy this Proxy- 
> State into the associated Disconnect-Response?
> 
>      While there is no /explicit/ statement that says "Proxy-state  
> must be preserved by the client receiving the Disconnect-Request",  
> there are a couple of places where it is clearly implied.
> 
>      First in section 2.3, in discussing the behavior of forwarding  
> proxies with respect to these messages, it says:
> 
>       When using a forwarding proxy, the proxy must be able to alter the
>        packet as it passes through in each direction.  When the proxy
>        forwards a Disconnect or CoA-Request, it MAY add a Proxy-State
>        Attribute, and when the proxy forwards a response, it MUST remove
>        its Proxy-State Attribute if it added one.  Proxy-State is always
>        added or removed after any other Proxy-States, but no other
>        assumptions regarding its location within the list of Attributes
>        can be made.  Since Disconnect and CoA responses are  
> authenticated
>        on the entire packet contents, the stripping of the Proxy-State
>        Attribute invalidates the integrity check - so the proxy needs to
>        recompute it.  A forwarding proxy MUST NOT modify existing Proxy-
>        State, State, or Class Attributes present in the packet.
> 
> To me, this seems a clear implication that the NAS would include the  
> proxy-state in the response, and hence the need for text to specify  
> that it must be removed by the proxy.  This is further supported by  
> the following excerpt from the table in Section 3.2:
> 
>     Disconnect Messages
> 
>     Request   ACK      NAK   #   Attribute
> [text deleted]
>     0+        0+       0+   33   Proxy-State
> 
>      Do you (jointly or severally) agree with my assessment?  
> Clarification would be very helpful.
> 
>      Thanks!
> 
>      - Jim
> 
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
-- 
E-Advies - Emile van Bergen           [email-masked]      
tel. +31 (0)78 6136282           http://www.e-advies.nl    

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 13 Sep 2005 03:10:37 +0000
Date: Mon, 12 Sep 2005 20:10:12 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Issue 133:  State Attribute MUST be included in "Authorize-Only" Requests

Issue 133: State Attribute MUST be included in "Authorize-Only" Requests
Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: September 12, 2005
Reference: http://ops.ietf.org/lists/radiusext/2005/msg00842.html
Document: RFC3576bis
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:

RFC 2865 Section 4.1 says:

"An Access-Request MUST contain either a User-Password or a 
CHAP-Password or a State."

This statement is subsequently updated in other RADIUS RFCs
to also include additional authentication attributes
(e.g. EAP-Message or Digest attributes).  However, the statement
remains: an Access-Request without authentication attributes
MUST include a State attribute. 

Since an Access-Request with Service-Type "Authorization-Only"
does not include authentication attributes, under RFC 2865, this
message is illegal unless a State attribute is included. 

RFC 3576 indicates that 0-1 State attributes may be included
in CoA or Disconnect Request, ACK or NAK messages, and 
RFC 3576 Section 3.2, Note 7 describes the use of the State
attribute:

   [Note 7] The State Attribute is available to be sent by the RADIUS
   server to the NAS in a Disconnect-Request or CoA-Request message and
   MUST be sent unmodified from the NAS to the RADIUS server in a
   subsequent ACK or NAK message.  If a Service-Type Attribute with
   value "Authorize Only" is included in a Disconnect-Request or CoA-
   Request along with a State Attribute, then the State Attribute MUST
   be sent unmodified from the NAS to the RADIUS server in the resulting
   Access-Request sent to the RADIUS server, if any.  The State
   Attribute is also available to be sent by the RADIUS server to the
   NAS in a CoA-Request that also includes a Termination-Action
   Attribute with the value of RADIUS-Request.  If the client performs
   the Termination-Action by sending a new Access-Request upon
   termination of the current session, it MUST include the State
   Attribute unchanged in that Access-Request.  In either usage, the
   client MUST NOT interpret the Attribute locally.  A Disconnect-
   Request or CoA-Request packet must have only zero or one State
   Attribute.  Usage of the State Attribute is implementation dependent.
   If the RADIUS server does not recognize the State Attribute in the
   Access-Request, then it MUST send an Access-Reject.

However, RFC 3576 does not state that a State
attribute is REQUIRED in a Disconnect or CoA-Request
with Service-Type = "Authorize Only", nor does it state that an 
Access-Request with Service-Type = "Authorize Only"
MUST include a State attribute. 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 13 Sep 2005 02:25:34 +0000
Content-class: urn:content-classes:message
Subject: RE: REMINDER:  Review comments on RFC 3576 MIBs (fwd)
Date: Tue, 13 Sep 2005 07:55:11 +0530
From: "Nagi Reddy Jonnala \(njonnala\)" <[email-masked]>
To: <[email-masked]>
Cc: "Bernard Aboba" <[email-masked]>, <[email-masked]>

Hi Inderpreet,

Thank you for your comments.

DAC and DAS terminology would still be there but in Bernard suggested
format. Please see the below e-mail thread "RFC 3576bis Comments" for
more comments.

https://psg.com/lists/radiusext/2005/msg00756.html

We'll take care of the typo in the next revision.

Thanks
Nagi.

-----Original Message-----=20
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Bernard Aboba
Sent: Tuesday, September 13, 2005 3:00 AM
To: [email-masked]
Subject: RE: REMINDER: Review comments on RFC 3576 MIBs (fwd)

---------- Forwarded message ----------
Date: Mon, 12 Sep 2005 11:25:03 -0400
From: Inderpreet Singh <[email-masked]>
To: Bernard Aboba <[email-masked]>, [email-masked]
Subject: RE: REMINDER:  Review comments on RFC 3576 MIBs

I have read the documents and am ok with the contents.

1. Wanted to confirm that the discussion on the terminology DAS and DAC
stands and that there are no changes planned to either the base RFC 3576
or this MIB draft.

2. Page 6 - Section Terminology, para 2 there is a small typo.  On line
3 of para 2, change "itand" to "it and"

Thanks

---
Inderpreet Singh
Chief Architect
Chantry Networks Inc., A Siemens Company [email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Bernard Aboba
Sent: Sunday, September 11, 2005 1:32 AM
To: [email-masked]
Subject: REMINDER: Review comments on RFC 3576 MIBs

So far, the RFC 3576 MIBs have received only 3 comments, from two=20
individuals.   This either means that the document is in very good
shape,=20
or that hardly anyone has read it. =20

In order to advance this document, we need to distinguish these two
outcomes.=20

If you have read the documents and believe they are ok, please post this
indication to the RADEXT WG list.=20

If you have read the documents and have an issue with them, please post
the issue to the RADEXT WG list in the format described on the RADEXT WG
web page:
http://www.drizzle.com/~aboba/RADEXT/

If you have not read the documents, please do so NOW:
http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-client-mib
-01.
txt
http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-server-mib
-01.
txt

If we do not hear from anyone, we will assume that there is little or no
interest in implementing this document.=20

--
to unsubscribe send a message to [email-masked] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

--
to unsubscribe send a message to [email-masked] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 13 Sep 2005 02:14:41 +0000
Date: Mon, 12 Sep 2005 19:14:26 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Clarification on RFC3576: Must Proxy-State be copied by the NAS? (fwd)

-----Original Message-----
From: Jim Martin [mailto:[email-masked]] 
Sent: Monday, September 12, 2005 3:57 AM
To: [email-masked]; [email-masked]; [email-masked];
[email-masked]; Bernard Aboba
Subject: Clarification on RFC3576: Must Proxy-State be copied by the
NAS?

Gentlepeople,
     I have a question regarding RFC3576, specifically the behavior  
of the Proxy-State attribute when contained in a Disconnect Message.  
Fundamentally, the question is, if a Disconnect-Request is received  
by a NAS which contains a Proxy-State, MUST the NAS  copy this Proxy- 
State into the associated Disconnect-Response?

     While there is no /explicit/ statement that says "Proxy-state  
must be preserved by the client receiving the Disconnect-Request",  
there are a couple of places where it is clearly implied.

     First in section 2.3, in discussing the behavior of forwarding  
proxies with respect to these messages, it says:

      When using a forwarding proxy, the proxy must be able to alter the
       packet as it passes through in each direction.  When the proxy
       forwards a Disconnect or CoA-Request, it MAY add a Proxy-State
       Attribute, and when the proxy forwards a response, it MUST remove
       its Proxy-State Attribute if it added one.  Proxy-State is always
       added or removed after any other Proxy-States, but no other
       assumptions regarding its location within the list of Attributes
       can be made.  Since Disconnect and CoA responses are  
authenticated
       on the entire packet contents, the stripping of the Proxy-State
       Attribute invalidates the integrity check - so the proxy needs to
       recompute it.  A forwarding proxy MUST NOT modify existing Proxy-
       State, State, or Class Attributes present in the packet.

To me, this seems a clear implication that the NAS would include the  
proxy-state in the response, and hence the need for text to specify  
that it must be removed by the proxy.  This is further supported by  
the following excerpt from the table in Section 3.2:

    Disconnect Messages

    Request   ACK      NAK   #   Attribute
[text deleted]
    0+        0+       0+   33   Proxy-State

     Do you (jointly or severally) agree with my assessment?  
Clarification would be very helpful.

     Thanks!

     - Jim

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 13 Sep 2005 01:55:19 +0000
Date: Mon, 12 Sep 2005 14:37:40 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked], [email-masked]
cc: [email-masked]
Subject: Request to consider "RADIUS Extension for Digest Authentication" as a Proposed Standard

The RADEXT WG would like to request that the IESG consider "RADIUS 
Extension for Digest Authentication" as a Proposed Standard.  The document 
is available for inspection here:

http://www.ietf.org/internet-drafts/draft-ietf-radext-digest-auth-05.txt

To our knowledge, this version resolves all issues that were brought up 
during RADEXT WG last call.  Both of the RADEXT WG chairs have reviewed 
the document.  Discussion of this document has not been 
contentious, and we believe that an appeal is unlikely. 

Since early versions of this specification have been deployed, we believe 
that it is likely that this specification will be implemented and 
deployed as well.  Since the specification is a dependency of 3GPP2, there 
is considerable interest within the 3GPP2 community relating to it. 

A summary of the issues encountered in WG last call and their 
resolution is available here:
http://www.drizzle.com/~aboba/RADEXT

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 13 Sep 2005 01:51:03 +0000
Date: Mon, 12 Sep 2005 14:29:35 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: RE: REMINDER:  Review comments on RFC 3576 MIBs (fwd)

---------- Forwarded message ----------
Date: Mon, 12 Sep 2005 11:25:03 -0400
From: Inderpreet Singh <[email-masked]>
To: Bernard Aboba <[email-masked]>, [email-masked]
Subject: RE: REMINDER:  Review comments on RFC 3576 MIBs

I have read the documents and am ok with the contents.

1. Wanted to confirm that the discussion on the terminology DAS and DAC
stands and that there are no changes planned to either the base RFC 3576 or
this MIB draft.

2. Page 6 - Section Terminology, para 2 there is a small typo.  On line 3 of
para 2, change "itand" to "it and"

Thanks

---
Inderpreet Singh
Chief Architect
Chantry Networks Inc., A Siemens Company
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Bernard Aboba
Sent: Sunday, September 11, 2005 1:32 AM
To: [email-masked]
Subject: REMINDER: Review comments on RFC 3576 MIBs

So far, the RFC 3576 MIBs have received only 3 comments, from two 
individuals.   This either means that the document is in very good shape, 
or that hardly anyone has read it.  

In order to advance this document, we need to distinguish these two 
outcomes. 

If you have read the documents and believe they are ok, please post this 
indication to the RADEXT WG list. 

If you have read the documents and have an issue with them, please post 
the issue to the RADEXT WG list in the format described on the RADEXT WG 
web page:
http://www.drizzle.com/~aboba/RADEXT/

If you have not read the documents, please do so NOW:
http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-client-mib-01.
txt
http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-server-mib-01.
txt

If we do not hear from anyone, we will assume that there is little or no 
interest in implementing this document. 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 12 Sep 2005 09:51:34 +0000
Date: Mon, 12 Sep 2005 11:51:03 +0200
From: Emile van Bergen <[email-masked]>
To: [email-masked]
Subject: Re: A bit of background on [RFC3580] Section 5.3
Mail-Followup-To: [email-masked]

Hi,

On Sun, Sep 11, 2005 at 07:42:18PM -0700, Bernard Aboba wrote:

> > If you take a look the password hiding algorithm, assuming <= 16 octet
> > passwords to leave out the chaining for simplicity, where ^ denotes XOR,
> > and . denotes concatenation:
> > 
> > 	User-Password' = User-Password ^ md5 (Secret . Req-Authenticator)
> > 
> > you can see that if you know one User-Password and User-Password', you
> > know the MD5 hash of (Secret . Req-Authenticator).
> > 
> > This same hash is also used in the response packet to 'encrypt' response
> > attributes. That means the attacker who captures a request and response,
> > is able to decrypt the request- and response attributes for that session
> > and all future sessions using the same Secret and Authenticator. This
> > includes the sessions themselves if they are somehow protected by the
> > contents of response attributes, as is the case with MPPE-*-Key.
> 
> Attributes hidden in the Access-Accept (such as Tunnel-Password & 
> MPPE-*-Key) use a salt. 
> 
> For example, from RFC 2868, Section 3.5:
> 
>             b(1) = MD5(S + R + A)    c(1) = p(1) xor b(1)   C = c(1)
> 
> Where S = secret, R = Request Auth, A = Salt. 
> 
> Since MD5 utilizes padding, knowing MD5(S + R) (e.g. discovering 
> the keystream via known plaintext attack on PAP) doesn't provide much help 
> in computing MD5(S + R + A). 

True. I didn't analyze how much security the salt actually adds, because
it depends on the details of MD5, so I started from the worst case where
every response using an RA for which the hash is known can be decrypted. 

As you say, it's indeed an additional barrier the attacker has to take,
so the situation with PAP is even less bleak than I painted it.

> Of course if you can obtain S (such as via an offline dictionary
> attack), that is a different story. 

Of course. If you obtain S, all is lost and the installation's RADIUS
security is FUBAR.

On a related note, would it be a good idea if the practice of using a
different secret in each direction would be more widely adopted? 

If you obtain an S that's used from client to server only, you can't
forge responses or decrypt their attributes, only perform on-line
attacks on passwords and sniff passwords from other authentications. It
also may shield against MD5's issues a bit better than the salt at the
end.

It's very easy to do, and the feature to allow two secrets to be
specified can be added gradually and independently at clients and
servers.

Cheers,

Emile.

-- 
E-Advies - Emile van Bergen           [email-masked]      
tel. +31 (0)78 6136282           http://www.e-advies.nl    

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 12 Sep 2005 02:42:57 +0000
Date: Sun, 11 Sep 2005 19:42:18 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Emile van Bergen <[email-masked]>
cc: [email-masked], Alan DeKok <[email-masked]>
Subject: Re: A bit of background on [RFC3580] Section 5.3

> If you take a look the password hiding algorithm, assuming <= 16 octet
> passwords to leave out the chaining for simplicity, where ^ denotes XOR,
> and . denotes concatenation:
> 
> 	User-Password' = User-Password ^ md5 (Secret . Req-Authenticator)
> 
> you can see that if you know one User-Password and User-Password', you
> know the MD5 hash of (Secret . Req-Authenticator).
> 
> This same hash is also used in the response packet to 'encrypt' response
> attributes. That means the attacker who captures a request and response,
> is able to decrypt the request- and response attributes for that session
> and all future sessions using the same Secret and Authenticator. This
> includes the sessions themselves if they are somehow protected by the
> contents of response attributes, as is the case with MPPE-*-Key.

Attributes hidden in the Access-Accept (such as Tunnel-Password & 
MPPE-*-Key) use a salt. 

For example, from RFC 2868, Section 3.5:

            b(1) = MD5(S + R + A)    c(1) = p(1) xor b(1)   C = c(1)

Where S = secret, R = Request Auth, A = Salt. 

Since MD5 utilizes padding, knowing MD5(S + R) (e.g. discovering 
the keystream via known plaintext attack on PAP) doesn't provide much help 
in computing MD5(S + R + A). 

Of course if you can obtain S (such as via an offline dictionary attack), 
that is a different story. 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 12 Sep 2005 00:29:12 +0000
Date: Sun, 11 Sep 2005 17:28:52 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Alan DeKok <[email-masked]>
cc: [email-masked]
Subject: Re: A bit of background on [RFC3580] Section 5.3 

>   Would there be interested in a PAP replacement?  Something like
> Tunnel-Password comes to mind.  A 16-bit salt would make attacks more
> difficult, but if the salt is coming from the same low-entropy pool as
> the RA, I'm not sure it would help.

That is partially what the discussion about Keywrap is about.  The known 
plaintext attacks are enabled by the use of a stream cipher;  if a 
credible block cipher (like AES) were used instead, it would not be a 
problem. 

> > For example, a NAS can attempt to satisfy the global uniqueness
> > property by utilizing the IP address in the high order bits of the
> > RA and then utilizing a pseudo-random number in the low order bits.
> 
>   Is it worth codifying recommendations?  i.e. RA = (IP + counter +
> pseudo-random number + ...)  That would help guide implementors, at
> least.

Perhaps.  There are alternatives, of course.  MAC address + reboot counter 
+ pseudo-random number would work as well.  

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sun, 11 Sep 2005 23:30:23 +0000
Date: Mon, 12 Sep 2005 01:29:52 +0200
From: Emile van Bergen <[email-masked]>
To: [email-masked]
Cc: Avi Lior <[email-masked]>
Subject: Hints and End-to-End capabilities
Mail-Followup-To: [email-masked], Avi Lior <[email-masked]>

Hi,

Sorry for replying to my own post yet again, hopefully you'll consider
this addition worthwhile, since we're drifting in the general direction
of another capabilities effort:

http://www.watersprings.org/pub/id/draft-lior-radext-end-to-end-caps-01.txt

On Fri, Sep 09, 2005 at 11:58:16PM +0200, Emile van Bergen wrote:

> The only purpose I see for any sort of capability advertising in RADIUS
> is that a NAS can tell in advance that it will act on an authorization
> attribute.
> 
> Most prominent example (and a real world one I had to deal with): if a
> NAS does not support IP filtering attributes, it's allowed to ignore
> them (like any other attribute), while the home AAA would want to make
> its accept/reject decision conditional on whether or not the NAS will
> actually apply the filter. 
> 
> But at the RADIUS level, we already have a mechanism for that: the
> inclusion of the relevant response attribute, possibly with a dummy or
> null value, in the access request. 
> 
> Normally the value is used as a hint for the response, but it also tells
> the server that the NAS knows about the attribute. It does not seem a
> big change to specify that the NAS MUST NOT include hints in access
> requests for attributes that it does not support in access accepts.
> 
> If even that's is too much to ask, and you want to transport the list of
> supported attributes in a slightly more compressed way, I suggest a
> variable length bitmap, where each numbered bit from LSB to MSB conveys
> the supported status ('NAS will heed') of the correspondingly numbered
> IANA attribute. But you'd need similar language anyway ("Do not set the
> bit unless you actually intend to honor the attribute").

Other than backwards compatibility, the hints mechanism has another
advantage: it can allow the home AAA to discover the capabilities of the
whole chain, because proxies can, and often unintendedly do, indicate
their policies with respect to response attribute filtering by
performing request attribute filtering in the same way.

However, there are cases it may be undesireable for a proxy to filter an
attribute from a request that it does intend to filter from any
response. Attributes that are required in access requests or that only
make sense in those will be among them.

The most prominent example is User-Name, even: no NAS can leave it out,
and no proxy can filter it from the request, but both may want to
indicate that they do not support User-Name overwriting (a deprecated,
pre-Chargable-User-Identity practice, granted, but it may be a condition
for an accept in older deployments. It's also in some roaming contracts
that won't expire for a while).

Looking at all that, the dedicated bitmap attribute seems better: the
proxy can clear bits that correspond to attributes it doesn't allow the
home AAA to set, without filtering required request attributes.

On the other hand, there will be proxies that will filter response
attributes but that do not (yet) know about the NAS-will-heed-bitmap.
And those will still cause access accepts to be received by the NAS that
are less restricted than the home AAA intended them to be.

I plan to file a proposal that's an alternative to Avi Lior's End-to-End
capabilities document, based on clear and pure per-attribute 'NAS will
heed' semantics, however transmitted, with proxies required to indicate
their filtering policy, and aimed primarily at response attributes that
function to limit to user's session.

I would appreciate to hear though it if people think I would waste my
time because Lior's approach is better, and whether you have a
preference towards the hints or bitmap approach, if any, especially
considering existing filtering practice and behaviour in a heterogenous
network of NASes and proxies.

I'll then research the situation wrt. request attributes that cannot or
should not be filtered from the request but are routinely filtered from
responses. I think what's best ultimately depends on the number of
attributes that are routinely used in both requests and replies, the
number of optional-but-limiting attributes among them, and existing
practice with respect to filtering in either direction.

At any rate, I think that 'NAS-through-proxies-will-obey-attribute-X'
advertisements are the only capability advertisements that really add
something to the protocol. The home server may want to know what the
NASes plans are with the session limiting attributes it intends to send
in its Access Accept before sending it.

Server advertisements, on the other hand, effectively tell the RADIUS
client about part of the server's policy in advance, at the cost of
preauthentications, CoA or caching from other sessions (which is only
possible if the advertisement is home AAA wide in scope), and the NAS
applying part of the policy, without too much benefit. 

The whole idea with RADIUS is offloading policy to a central place, by
asking the server about each individual session that's about to take
place. And you only even get to see a user's policy if you supply that
user's credentials. No pushing or publishing of parts of it up front.
That's an aspect of RADIUS that should remain unchanged, I think. It
makes security analysis so much easier.

Kind regards,

Emile.

-- 
E-Advies - Emile van Bergen           [email-masked]      
tel. +31 (0)78 6136282           http://www.e-advies.nl    

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sun, 11 Sep 2005 21:13:19 +0000
Date: Sun, 11 Sep 2005 23:12:35 +0200
From: Emile van Bergen <[email-masked]>
To: Bernard Aboba <[email-masked]>
Cc: [email-masked], Alan DeKok <[email-masked]>
Subject: Re: A bit of background on [RFC3580] Section 5.3
Mail-Followup-To: Bernard Aboba <[email-masked]>, [email-masked], Alan DeKok <[email-masked]>

Hi,

On Sat, Sep 10, 2005 at 10:17:02PM -0700, Bernard Aboba wrote:

> A bit about the intent of the cited sentence in [RFC3580] 
> Section 5.3. 
> 
> Section 5.3 relates to known plaintext attacks against PAP, 
> where the attacker attempts to authenticate to a NAS and 
> then collects the User-Password attribute sent by the RADIUS client, 
> in order to derive the keystream used for attribute hiding. 

[SNIP]

There's a bit of an uneasy feeling I get when reading that text, and RFC
3579 section 4.3.4, and it's not from the risk of the possible attacks
on RADIUS, but rather the risk that comes from unbalanced PAP bashing!

First: every bit of RADIUS security depends entirely on the
cryptographic strength of the RNG generating the authenticator, combined
with the strength of the shared secret. That's well known ever since it
was conceived.

To stress that dependency in an alarmist fashion suggests that we've
learned something new, and we haven't. 

Security depending on a strong RNG and a strong secret is true for many,
many protocols. Ask any TCP implementor who was ridiculed (and rightly
so) for using a weak sequence number generator. 

The situation with RADIUS is no different. We even have 128 bits instead
of the 32 available in TCP, so the number and width of deltas before a
wraparound is much higher. ;-)

The only thing we can't stress enough is shared secret hygiene. RADIUS
is as secure as its administrator, and that also goes for most
protocols.  

I've more than once seen holier-than-thou roaming partners deploying
IPSEC to shield that oh-so-weak RADIUS and then mailing the IPSEC PSK in
the clear.

I think that the PAP issue is slightly more complex than it's portrayed
here, because these texts don't go into the issues of weighing PAP
against its alternatives.

If you take a look the password hiding algorithm, assuming <= 16 octet
passwords to leave out the chaining for simplicity, where ^ denotes XOR,
and . denotes concatenation:

	User-Password' = User-Password ^ md5 (Secret . Req-Authenticator)

you can see that if you know one User-Password and User-Password', you
know the MD5 hash of (Secret . Req-Authenticator).

This same hash is also used in the response packet to 'encrypt' response
attributes. That means the attacker who captures a request and response,
is able to decrypt the request- and response attributes for that session
and all future sessions using the same Secret and Authenticator. This
includes the sessions themselves if they are somehow protected by the
contents of response attributes, as is the case with MPPE-*-Key.

As you can see, so far I agree completely with those texts.

However, you still have to weigh

a. the difficulty of tapping a RADIUS connection long enough to generate
a significant number of captured Request Authenticator -> hash combo's,
to increase your chance of being able to compromise a future session that
uses a captured RA, vs.

b. the difficulty of cracking a RADIUS backend database containing ALL
cleartext passwords of ALL users (which you need in the case of most
CHAP-like algorithms), allowing you to compromise ALL future sessions.

With PAP you don't need to store plaintext passwords or password
equivalents, and that fact must not be left out of the equasion.

It's either plaintext session, hashed database for PAP, or hashed
session, plaintext (or equivalent) database for CHAP, incl. MSCHAPv2. 

The choice simply depends on the situation.

In most cases, I rather use PAP with a hashed database, accepting the
risk of an individual compromised session (dependent the repeating of
the RA while RADIUS is sniffed), than CHAP with a plaintext database,
accepting the risk of ALL passwords being compromised (including the
subsequent sessions that occur while RADIUS is sniffed).

The hashed database can use a good salt, making the off line dictionary
attack that's needed after obtaining the database hard, because it must
be done for each password individually.

Summarizing, I dare say a CHAP solution will often be less secure than
one using PAP -- if you look at the whole picture.

Cheers,

Emile.

-- 
E-Advies - Emile van Bergen           [email-masked]      
tel. +31 (0)78 6136282           http://www.e-advies.nl    

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Envelope-to: [email-masked]
Delivery-date: Sun, 11 Sep 2005 16:06:18 +0000
From: "Alan DeKok" <[email-masked]>
To: Bernard Aboba <[email-masked]>
Subject: Re: A bit of background on [RFC3580] Section 5.3 
Cc: [email-masked]
Date: Sun, 11 Sep 2005 12:07:29 -0400
Message-Id: <[email-masked]>

Bernard Aboba <[email-masked]> wrote:
> As a result, Section 5.3 is attempting to discourage the 
> use of PAP and the potential cascading vulnerablities that
> can result. 

  It would be clearer for the average reader is some document said
outright "PAP is deprecated.  Don't use it."

> If PAP cannot be deprecated entirely, then it is best if its 
> use is isolated to accounts that have limited access rights.  

  On the same NAS that uses EAP... leading to leveraged attacks.

> If these principles are followed, it possible to limit the 
> use of PAP without forcing a RADIUS proxy to utilize a 
> different IP address for PAP and EAP authentication.

  Would there be interested in a PAP replacement?  Something like
Tunnel-Password comes to mind.  A 16-bit salt would make attacks more
difficult, but if the salt is coming from the same low-entropy pool as
the RA, I'm not sure it would help.

  Quoting out of order:

> For example, a NAS can attempt to satisfy the global uniqueness
> property by utilizing the IP address in the high order bits of the
> RA and then utilizing a pseudo-random number in the low order bits.

  Is it worth codifying recommendations?  i.e. RA = (IP + counter +
pseudo-random number + ...)  That would help guide implementors, at
least.

  Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sun, 11 Sep 2005 05:31:43 +0000
Date: Sat, 10 Sep 2005 22:31:36 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: REMINDER:  Review comments on RFC 3576 MIBs

So far, the RFC 3576 MIBs have received only 3 comments, from two 
individuals.   This either means that the document is in very good shape, 
or that hardly anyone has read it.  

In order to advance this document, we need to distinguish these two 
outcomes. 

If you have read the documents and believe they are ok, please post this 
indication to the RADEXT WG list. 

If you have read the documents and have an issue with them, please post 
the issue to the RADEXT WG list in the format described on the RADEXT WG 
web page:
http://www.drizzle.com/~aboba/RADEXT/

If you have not read the documents, please do so NOW:
http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-client-mib-01.txt
http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-server-mib-01.txt

If we do not hear from anyone, we will assume that there is little or no 
interest in implementing this document. 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sun, 11 Sep 2005 05:29:57 +0000
Date: Sat, 10 Sep 2005 22:29:47 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: RADIUS Digest Authentication: FINAL REVIEW COMPLETED

The RADIUS Digest Authentication document has now completed final RADEXT 
WG review.   Issues 79, 121, 122, 126 and 127 were submitted; of these 
only 121 and 122 remain open. 

Since the remaining issues are editorial in nature, we would like to 
request the authors to rapidly address these issues, so that a new 
version of the document can be provided that we can send off to the IESG. 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sun, 11 Sep 2005 05:17:56 +0000
Date: Sat, 10 Sep 2005 22:17:02 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: A bit of background on [RFC3580] Section 5.3

A bit about the intent of the cited sentence in [RFC3580] 
Section 5.3. 

Section 5.3 relates to known plaintext attacks against PAP, 
where the attacker attempts to authenticate to a NAS and 
then collects the User-Password attribute sent by the RADIUS client, 
in order to derive the keystream used for attribute hiding. 
This attack is easy to mount because RFC 2865 does not require
that the RADIUS Access-Request be integrity protected.  

Since the User-Password keystream is a function of the Shared 
Secret and the Request Authenticator, a user's password should
be considered compromised if the Request Authenticator 
(User-Password) repeats on any NAS utilizing a given RADIUS 
shared secret. 

In order to prevent this attack, RFC 2865 requires the 
Request Authenticator to be globally and temporally unique,
but not all NASes satisfy this requirement.  For example,
a NAS can attempt to satisfy the global uniqueness property
by utilizing the IP address in the high order bits of the
RA and then utilizing a pseudo-random number in the low
order bits.  However, not all NAS devices have sufficient
entropy to produce high quality pseudo-random numbers. 

If in addition, the same RADIUS shared secret is used on
for more than one NAS, the chance of compromise increases
significantly. 
 
Once an attacker has compromised user passwords, they can
gain access to all media which utilize those credentials,
enabling known plaintext attacks on other hidden attributes
such as Tunnel-Password and MPPE-Keys. 

These other hidden attributes cannot be attacked by an
unauthenticated attacker because these attributes are only
sent in an Access-Accept, which implies a successful
authentication.  So the attacker must first obtain
access to compromised passwords before trying this more
difficult attack. 

However, once this attacks collects sufficient keystream
material, if the RA + salt ever repeats on a NAS utilizing
a given shared secret, then the EAP MSK or Tunnel-Password
is compromised. 

As a result, Section 5.3 is attempting to discourage the 
use of PAP and the potential cascading vulnerablities that
can result. 

If PAP cannot be deprecated entirely, then it is best if its 
use is isolated to accounts that have limited access rights.  
Also, EAP made a conscious decision not to support PAP, 
so re-introduction of PAP support into EAP is undesirable. 

If these principles are followed, it possible to limit the 
use of PAP without forcing a RADIUS proxy to utilize a 
different IP address for PAP and EAP authentication.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sat, 10 Sep 2005 02:04:18 +0000
Content-class: urn:content-classes:message
Subject: RE: REMINDER: Call for review of RFC 2618bis-2621bis
Date: Fri, 9 Sep 2005 22:00:15 -0400
From: "Nelson, David" <[email-masked]>
To: "Romascanu, Dan \(Dan\)" <[email-masked]>, "Bernard Aboba" <[email-masked]>, <[email-masked]>

> The rfc2620bis document is not available by now.

The IETF Help Desk "ticket" has been cleared, and the draft is now in =
the I-D repository.

Somehow or other, it seems that each time I submit the group of four =
drafts at the same time, at least one goes missing for a while.  :-(

Dave

=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sat, 10 Sep 2005 00:22:52 +0000
Date: Sat, 10 Sep 2005 02:22:40 +0200
From: Emile van Bergen <[email-masked]>
To: [email-masked], [email-masked]
Subject: Issue: Capability Attribute rationale and scenarios unclear
Mail-Followup-To: [email-masked], [email-masked]

Capability Attribute rationale and scenarios unclear

Submitter name: Emile van Bergen
Submitter email address: [email-masked]
Date first submitted: September 10, 2005
Reference: http://ops.ietf.org/lists/radiusext/2005/msg00824.html
Document: http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius-lo-04.txt
Comment type: T
Priority: S
Section: 8
Rationale/Explanation of issue:

>From the text:

  "8. Capability Attribute
  
   The capability attribute allows the RADIUS client to indicate whether
   civic and/or geospatial location information can be provided to the
   RADIUS server.  This is useful to avoid sending location information
   with every request if no further out-of-band arrangements are made
   with regard to the transport of location information.  

   The AAA server uses the capability attribute to indicate that the AAA
   client has to provide civic and/or geospatial location information as
   part of this particular protocol exchange.  If the AAA server does
   not send a capability attribute then the AAA client MUST NOT return
   location information.  The user's authorization policies MUST be
   consulted by the AAA server before requesting location information
   delivery from the AAA client.  If the AAA server encounters that the
   AAA client does not support the desired location information it might
   respond with an Access-Reject with the corresponding error cause
   attribute (with the Location-Info-Required error code)."

The reason to avoid sending location information is not clear. From the
rest of the document, it would appear that the sending of location
information is entirely conditional on the user's policy, not on any
other consideration.

In RADIUS, the RADIUS client can only learn about the user's policy from
RADIUS responses to an access request. So I would suggest to put the
following text somewhere:

  "Without prior knowledge of the user's policy, the RADIUS client MUST
  NOT send Location attributes in an Access Request.

  If the home RADIUS server requires location information for
  authentication and has permission from the user, it sends an Access-
  Challenge containing Location-Info-Required to request the
  information, upon which the RADIUS client will reissue its Access
  Request, including the Location attributes (and echoing the State
  attribute as per RFC 2865).

  If the home RADIUS server does not require location information to
  perform its authentication, but the user's policy allows location
  information to be transmitted by the RADIUS client, the RADIUS server
  informs the RADIUS client of that policy in the Access Accept packet."

It seems there's no capability negotiation needed, and as RADIUS servers
are currently not required to keep any dynamic per-client data, leave
alone per-NAS data, that should only be added when absolutely required.

Kind regards,

Emile van Bergen.

-- 
E-Advies - Emile van Bergen           [email-masked]      
tel. +31 (0)78 6136282           http://www.e-advies.nl    

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 09 Sep 2005 23:42:45 +0000
Date: Sat, 10 Sep 2005 01:42:42 +0200
From: Emile van Bergen <[email-masked]>
To: Alan DeKok <[email-masked]>
Cc: [email-masked]
Subject: Re: Capabilities (was Re: AW: Review of draft-ietf-geopriv-radius-lo-04.txt )
Mail-Followup-To: Alan DeKok <[email-masked]>, [email-masked]

Hi,

On Fri, Sep 09, 2005 at 07:08:10PM -0400, Alan DeKok wrote:

> Emile van Bergen <[email-masked]> wrote:
> > >   I would also expect that NASes will *not* want to send all of the
> > > available information for all capabilities.  
> > 
> > Seriously though, if that's information that's actually relevant at
> > authentication time, ie. required to determine the level of access, why
> > not?
> 
>   The NAS may not know it's required for authentication, so the NAS
> may not send it.

The NAS should send all it has, unless there are definitive reasons not
to.

You have other options than enabling information sets per individual
authentication. You can either

1. configure the included information set statically, at the NAS.

2. if you want to use a different set per upstream proxy or home AAA, 
   have the NAS send all and filter the set at the local proxy.

3. if you really, really need a different set per individual user,
   then you need a challenge, for which the following applies.

> > If it's efficiency, extra round trips and extra state are far more
> > costly than a few more bytes in an access request.
> 
>   Yes.
> 
> > The only purpose I see for any sort of capability advertising in RADIUS
> > is that a NAS can tell in advance that it will act on an authorization
> > attribute.
> 
>   For extensions to RADIUS (i.e. NAS is required to properly use
> attribute FOO in Access-Accept), the only way to ensure correctness is
> some kind of extended capability ACK/NAK.  This was discussed
> previously.
> 
> > Normally the value is used as a hint for the response, but it also tells
> > the server that the NAS knows about the attribute. It does not seem a
> > big change to specify that the NAS MUST NOT include hints in access
> > requests for attributes that it does not support in access accepts.
> 
>   Sure.  But most NASes already don't include hints.  So using the
> lack of hints as information is inappropriate.

Are you sure? 

The only case is where a NAS must indicate support for a certain
attribute, is when that support is a prerequisite in the home AAA's
policy for an access accept.

And the only way for the home AAA to obtain that information sure enough
for a reject is a change in NAS implementations. 

And the simplest change at the NAS is to actually start using the hints
mechanism.

Keep in mind that making a NAS answer challenges with that information
is also a change. The hint is a smaller change and more efficient.

> > If even that's is too much to ask, and you want to transport the list of
> > supported attributes in a slightly more compressed way, I suggest a
> > variable length bitmap, where each numbered bit from LSB to MSB conveys
> > the supported status ('NAS will heed') of the correspondingly numbered
> > IANA attribute. But you'd need similar language anyway ("Do not set the
> > bit unless you actually intend to honor the attribute").
> 
>   That makes sense.  But you still need an extended ACK/NAK to ensure
> that the RADIUS server knows the NAS will enforce it.

Why isn't the hints mechanism enough?

If you need to reject every NAS that does not yet implement ack/nak to
tell you about its support for an attribute, you can as well reject
every NAS that does not implement the hint. 

In both cases you need a change at the NAS. The process and migration
problems are exactly the same.

If the hints seem inefficient because you only need to test the
attribute's presence, consider a bitmap to compress them.

>   And you will need something else for values.  e.g. Service-Type FOO
> is supported, but Service-Type BAR is not.  (That example doesn't make
> sense for Service-Type, but it may make sense for other capabilities.)

Capabilities is a bit vague. You mean that there can be standard
attributes where a home AAA would want to make his accept conditional on
the range of values that the NAS would act upon?

I say a NAS can only be compliant with the standard that specifies a
session-limiting attribute if it implements all values that make sense
in the context. 

Remember that this whole mechanism only makes sense for attributes or
values that limit a user's session in some way. 

I don't see a need to make this more fine grained than the attribute
level.

Cheers,

Emile.

-- 
E-Advies - Emile van Bergen           [email-masked]      
tel. +31 (0)78 6136282           http://www.e-advies.nl    

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 09 Sep 2005 23:09:05 +0000
Date: Sat, 10 Sep 2005 01:09:00 +0200
From: Emile van Bergen <[email-masked]>
To: Avi Lior <[email-masked]>, Bernard Aboba <[email-masked]>, "Nelson, David" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Capabilities (was Re: AW: Review of draft-ietf-geopriv-radius-lo-04.txt )
Mail-Followup-To: Avi Lior <[email-masked]>, Bernard Aboba <[email-masked]>, "Nelson, David" <[email-masked]>, [email-masked], [email-masked]

Sorry, confusing typo here:

On Sat, Sep 10, 2005 at 01:03:41AM +0200, Emile van Bergen wrote:

>    Only the home AAA advertising to its upstream the policy that it
                                          ^^^^^^^^

Of course that should read 'downstream', ie. towards the NAS.

>    needs Location, else don't bother sending an access request, would
>    prevent the access request and the challenge. But the general idea
>    with RADIUS is not that home AAA push their policies downstream, but
>    that downstream queries upstream in the individual case.

Cheers,

Emile.

-- 
E-Advies - Emile van Bergen           [email-masked]      
tel. +31 (0)78 6136282           http://www.e-advies.nl    

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Envelope-to: [email-masked]
Delivery-date: Fri, 09 Sep 2005 23:06:30 +0000
From: "Alan DeKok" <[email-masked]>
To: Emile van Bergen <[email-masked]>
Subject: Re: Capabilities (was Re: AW: Review of draft-ietf-geopriv-radius-lo-04.txt ) 
Cc: [email-masked]
Date: Fri, 09 Sep 2005 19:08:10 -0400
Message-Id: <[email-masked]>

Emile van Bergen <[email-masked]> wrote:
> >   I would also expect that NASes will *not* want to send all of the
> > available information for all capabilities.  
> 
> Seriously though, if that's information that's actually relevant at
> authentication time, ie. required to determine the level of access, why
> not?

  The NAS may not know it's required for authentication, so the NAS
may not send it.

> If it's efficiency, extra round trips and extra state are far more
> costly than a few more bytes in an access request.

  Yes.

> The only purpose I see for any sort of capability advertising in RADIUS
> is that a NAS can tell in advance that it will act on an authorization
> attribute.

  For extensions to RADIUS (i.e. NAS is required to properly use
attribute FOO in Access-Accept), the only way to ensure correctness is
some kind of extended capability ACK/NAK.  This was discussed
previously.

> Normally the value is used as a hint for the response, but it also tells
> the server that the NAS knows about the attribute. It does not seem a
> big change to specify that the NAS MUST NOT include hints in access
> requests for attributes that it does not support in access accepts.

  Sure.  But most NASes already don't include hints.  So using the
lack of hints as information is inappropriate.

> If even that's is too much to ask, and you want to transport the list of
> supported attributes in a slightly more compressed way, I suggest a
> variable length bitmap, where each numbered bit from LSB to MSB conveys
> the supported status ('NAS will heed') of the correspondingly numbered
> IANA attribute. But you'd need similar language anyway ("Do not set the
> bit unless you actually intend to honor the attribute").

  That makes sense.  But you still need an extended ACK/NAK to ensure
that the RADIUS server knows the NAS will enforce it.

  And you will need something else for values.  e.g. Service-Type FOO
is supported, but Service-Type BAR is not.  (That example doesn't make
sense for Service-Type, but it may make sense for other capabilities.)

  Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 09 Sep 2005 23:04:10 +0000
Date: Sat, 10 Sep 2005 01:03:41 +0200
From: Emile van Bergen <[email-masked]>
To: Avi Lior <[email-masked]>
Cc: Bernard Aboba <[email-masked]>, "Nelson, David" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Capabilities (was Re: AW: Review of draft-ietf-geopriv-radius-lo-04.txt )
Mail-Followup-To: Avi Lior <[email-masked]>, Bernard Aboba <[email-masked]>, "Nelson, David" <[email-masked]>, [email-masked], [email-masked]

Hi,

(Cross posting to GEOPRIV-WG; this discussion pertains to
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius-lo-04.txt,
in particular section 8).

On Fri, Sep 09, 2005 at 04:49:09PM -0400, Avi Lior wrote:

> > The question is why GEOPRIV has decided not to send location 
> > by default. 
> 
> Initially we did exactly that we sent the location information in the
> Access-Request.  But Geopriv being about privacy, was concerned what if
> the user did not want to have their location exposed.
> 
> So now we have the case where in some systems, the user's policy of
> whether or not to expose location is stored in the a database and during
> authentication the AAA learns that policy.

Presumably you mean that the NAS learns the user's policy from the home
server, who has access to the user's profile.

I see that your position is in line with that, but I still do not see the
point.

1. If the home AAA makes access or billing conditional on Location, the
   user's own policy is irrelevant; the home AAA will only list the user
   in his database if the user agrees with his location being
   transmitted to the home AAA. 

   So if that is the case, if the home AAA doesn't see Location in a
   request without State, it challenges. If it sees no Location in a
   request with State, it rejects. 

   Advertising the positive case (NAS supports GEOPRIV and will send
   Location when challenged) in the access request does not prevent the
   challenge.

   Advertising the negative case (NAS supports GEOPRIV but will not send
   Location when challenged) will prevent the challenge and allow the
   home AAA to send a reject immediately. 
   
   But that's a corner case that seems hardly worth dealing with. You'll
   either have a NAS that supports it and needs a challenge, or a
   pre-GEOPRIV NAS that won't do any negative GEOPRIV-advertising
   either.

   Only the home AAA advertising to its upstream the policy that it
   needs Location, else don't bother sending an access request, would
   prevent the access request and the challenge. But the general idea
   with RADIUS is not that home AAA push their policies downstream, but
   that downstream queries upstream in the individual case.

   In short: if Location is /needed/ by the home AAA, then you need a
   Challenge step anyway, a. for the NAS to learn about the user's
   policy, and b. for the AAA server to postpone its decision until it
   learns the presence or value of Location.

2. If Location is optional, and only used for statistics, marketing,
   and other shady purposes, then NAS can learn from the access accept
   whether the user allows Location to be included in accounting
   packets (start, interim and stop).
   
   The access accept could include a dummy Location value in that case,
   and we could have language saying that the NAS MUST NOT send Location
   in accounting unless an empty Location attribute is present in the
   access accept.

In both cases: no advertising needed. Or even helpful.

> > > But that advertisement is also an extra transaction. What's 
> > the home 
> > > AAA supposed to do, keep state from separate pseudo-authentications 
> > > that include the advertised information for later use? That doesn't 
> > > sound like RADIUS, at all.
>  
> > Right. 
> 
> Wrong.
> 
> No the advertizement is not an extra transaction.  It comes in the
> Access-Request.

But if the NAS may only include Location if it learns the user's policy
first, for privacy reason, then telling the NAS about the user's policy
/is/ an extra transaction. You need that one, too.

You're not advocating (phew) that each user is to advertise his policy
towards each NAS in advance, and no other form of advertising would
prevent that step.

> And by the way, RADIUS does keep transactional state.  

Please see my other post. 

The NAS does not keep state about users after they log off, so it can't
cache the user's policy, and the home AAA does not keep state per NAS,
so it can't use information about a NAS (negative support) from earlier
authentications, unless you add a whole new dimension to building a
compliant RADIUS server.

Kind regards,

Emile.

-- 
E-Advies - Emile van Bergen           [email-masked]      
tel. +31 (0)78 6136282           http://www.e-advies.nl    

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 09 Sep 2005 21:58:40 +0000
Date: Fri, 9 Sep 2005 23:58:16 +0200
From: Emile van Bergen <[email-masked]>
To: Alan DeKok <[email-masked]>
Cc: Avi Lior <[email-masked]>, [email-masked]
Subject: Re: Capabilities (was Re: AW: Review of draft-ietf-geopriv-radius-lo-04.txt )
Mail-Followup-To: Alan DeKok <[email-masked]>, Avi Lior <[email-masked]>, [email-masked]

Hi,

On Fri, Sep 09, 2005 at 03:14:32PM -0400, Alan DeKok wrote:

> "Avi Lior" <[email-masked]> wrote:
> > The only debate that we are having which is specific to Location is
> > whether or not the NAS advertizes its location capabilities in the
> > access request.  Well Bernard thinks no, I think yes.  But regardless of
> > that specific debate we already have evidence that a mechanism for
> > advertizing the NAS capability is required -- CUI and Prepaid etc.....
> 
>   If that advertising mechanism is general, then it can be shared
> across all capabilities, meaning this isn't a strictly
> location-capability problem.
> 
>   I would also expect that NASes will *not* want to send all of the
> available information for all capabilities.  

Seriously though, if that's information that's actually relevant at
authentication time, ie. required to determine the level of access, why
not?

If it's trust, see my other post about it.

If it's packet size, then it seems we're trying to solve the problem at
way too high a layer.

If it's efficiency, extra round trips and extra state are far more
costly than a few more bytes in an access request.

> Rather, they should send an Access-Request with an "extended
> capability" notification, and leave additional negotiations to later
> stages of the authentication conversation.

The only purpose I see for any sort of capability advertising in RADIUS
is that a NAS can tell in advance that it will act on an authorization
attribute.

Most prominent example (and a real world one I had to deal with): if a
NAS does not support IP filtering attributes, it's allowed to ignore
them (like any other attribute), while the home AAA would want to make
its accept/reject decision conditional on whether or not the NAS will
actually apply the filter. 

But at the RADIUS level, we already have a mechanism for that: the
inclusion of the relevant response attribute, possibly with a dummy or
null value, in the access request. 

Normally the value is used as a hint for the response, but it also tells
the server that the NAS knows about the attribute. It does not seem a
big change to specify that the NAS MUST NOT include hints in access
requests for attributes that it does not support in access accepts.

If even that's is too much to ask, and you want to transport the list of
supported attributes in a slightly more compressed way, I suggest a
variable length bitmap, where each numbered bit from LSB to MSB conveys
the supported status ('NAS will heed') of the correspondingly numbered
IANA attribute. But you'd need similar language anyway ("Do not set the
bit unless you actually intend to honor the attribute").

Cheers,

Emile.

-- 
E-Advies - Emile van Bergen           [email-masked]      
tel. +31 (0)78 6136282           http://www.e-advies.nl    

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 09 Sep 2005 21:38:59 +0000
Date: Fri, 9 Sep 2005 23:38:47 +0200
From: Emile van Bergen <[email-masked]>
To: Avi Lior <[email-masked]>
Cc: "Nelson, David" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Capabilities (was Re: AW: Review of draft-ietf-geopriv-radius-lo-04.txt )
Mail-Followup-To: Avi Lior <[email-masked]>, "Nelson, David" <[email-masked]>, [email-masked], [email-masked]

Hi,

On Fri, Sep 09, 2005 at 05:24:32PM -0400, Avi Lior wrote:

> > > And by the way, RADIUS does keep transactional state. 
> > 
> > The RADIUS protocol was designed so that RADIUS servers could 
> > be stateless.  This is achieved by passing the state "cookie" 
> > back to the RADIUS clients in the form of the State and Class 
> > attributes. 
> 
> Exactly.  State is how RADIUS can keep transactional state.

For complete clarity: indeed, state per transaction. 

No state per NAS, per client, or per user.

Of course policies may any keep per-NAS, per-client or per-user
statistics they want, and even use such per-NAS, per-client or per-user
information in subsequent authentications, but there's nothing in the
protocol that specifically caters for or requires state for anything
other than individual transactions.

Cheers,

Emile.

-- 
E-Advies - Emile van Bergen           [email-masked]      
tel. +31 (0)78 6136282           http://www.e-advies.nl    

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 09 Sep 2005 21:24:02 +0000
Content-class: urn:content-classes:message
Subject: RE: Capabilities (was Re: AW: Review of draft-ietf-geopriv-radius-lo-04.txt )
Date: Fri, 9 Sep 2005 17:24:32 -0400
From: "Avi Lior" <[email-masked]>
To: "Nelson, David" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Hi David,

See inline....=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Nelson, David
> Sent: Friday, September 09, 2005 4:58 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: Capabilities (was Re: AW: Review of=20
> draft-ietf-geopriv-radius-lo-04.txt )
>=20
> Avi Lior writes...
>=20
> > Initially we did exactly that we sent the location=20
> information in the=20
> > Access-Request.  But Geopriv being about privacy, was concerned what
> if
> > the user did not want to have their location exposed.
>=20
> Well, it seems to me that if the user is *really* concerned=20
> about disclosure of private information, then no location=20
> information should be sent until the identity of the Home AAA=20
> server has been authenticated, potentially by an EAP method=20
> providing mutual authentication.
>=20
> That might mean that location information cannot be sent=20
> until the successful completion of authentication, i.e. after=20
> the Access-Accept is received at the NAS.  Depending on the=20
> level of privacy assurance that GEOPRIV is seeking to obtain,=20
> it might be very difficult using the current AAA architectures.

Well I think we are going a bit overboard here.  I appreciate your
commnet but RADIUS and DIAMETER are what they are and a lot worse can
happen if you start to question the trust model of IETF based AAA
protocols.

And under the current charter we are not suppose to fix these issues.

> > And by the way, RADIUS does keep transactional state.=20
>=20
> The RADIUS protocol was designed so that RADIUS servers could=20
> be stateless.  This is achieved by passing the state "cookie"=20
> back to the RADIUS clients in the form of the State and Class=20
> attributes.=20

Exactly.  State is how RADIUS can keep transactional state.
=20
>=20
> --
> to unsubscribe send a message to=20
> [email-masked] with the word 'unsubscribe' in=20
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 09 Sep 2005 20:59:16 +0000
Content-class: urn:content-classes:message
Subject: RE: Capabilities (was Re: AW: Review of draft-ietf-geopriv-radius-lo-04.txt )
Date: Fri, 9 Sep 2005 16:58:20 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>

Avi Lior writes...

> Initially we did exactly that we sent the location information in the
> Access-Request.  But Geopriv being about privacy, was concerned what
if
> the user did not want to have their location exposed.

Well, it seems to me that if the user is *really* concerned about
disclosure of private information, then no location information should
be sent until the identity of the Home AAA server has been
authenticated, potentially by an EAP method providing mutual
authentication.

That might mean that location information cannot be sent until the
successful completion of authentication, i.e. after the Access-Accept is
received at the NAS.  Depending on the level of privacy assurance that
GEOPRIV is seeking to obtain, it might be very difficult using the
current AAA architectures.

> And by the way, RADIUS does keep transactional state.=20

The RADIUS protocol was designed so that RADIUS servers could be
stateless.  This is achieved by passing the state "cookie" back to the
RADIUS clients in the form of the State and Class attributes.=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 09 Sep 2005 20:58:44 +0000
Content-class: urn:content-classes:message
Subject: RE: Capabilities (was Re: AW: Review of draft-ietf-geopriv-radius-lo-04.txt )
Date: Fri, 9 Sep 2005 16:59:14 -0400
From: "Avi Lior" <[email-masked]>
To: "Emile van Bergen" <[email-masked]>, "Bernard Aboba" <[email-masked]>
Cc: "Nelson, David" <[email-masked]>, <[email-masked]>

BTW this trust issue is also an issue with Diameter

Both are hop-by-hop secure so have the same issues.  Although Diameter
has a redirection capability as a work around - which will be
interesting to see if it ever gets deployed in high transaction
environments.

Even using EAP. Although the authentication is End-to-End the result of
the authenticaiton, typically a key is sent back to the NAS through
proxies.  The proxies see the Key.
=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Emile van Bergen
> Sent: Friday, September 09, 2005 2:48 PM
> To: Bernard Aboba
> Cc: Nelson, David; [email-masked]
> Subject: Re: Capabilities (was Re: AW: Review of=20
> draft-ietf-geopriv-radius-lo-04.txt )
>=20
> Hi,
>=20
> On Thu, Sep 08, 2005 at 12:22:51PM -0700, Bernard Aboba wrote:
>=20
> > > > The RADIUS server may REQUIRE location in order to evaluate a=20
> > > > authentication/authorization policy.  That policy could=20
> state that=20
> > > > if location is not provided then allow the user on with certain=20
> > > > constraints.
> >=20
> > Yes, but the RADIUS server can do this *after* it has=20
> indicated that=20
> > it requires the NAS to provide location information via an=20
> Access-Challenge.
> >=20
> > For example, the NAS initially does not send location=20
> information; the=20
> > RADIUS server sends an Access-Challenge asking for it;  the=20
> NAS still=20
> > does not send it, and then the RADIUS server sends an Access-Accept=20
> > with limited authorizations, instead of an Access-Reject.
> >=20
> > In this scenario, there is still no need for "capabilities=20
> advertisement"=20
> > by a NAS.=20
> >=20
> > > In the case of location information, what is the problem with the=20
> > > NAS always providing any location information that it has to the=20
> > > RADIUS server?
> >=20
> > It may be undesirable for the NAS to send location by=20
> default.  But as=20
> > argued earlier, this is not a problem -- the RADIUS server=20
> can ask for=20
> > the information.
> >=20
> > > If the issue is that the User wants the NAS to only disclose=20
> > > location to RADIUS servers that he trusts, I think there=20
> is a lot of=20
> > > heavy lifting to do.
> >=20
> > I'd argue that the only RADIUS server that a user can trust is its=20
> > home RADIUS server. There can be no notion of a user trusting=20
> > intermediate proxies.
>=20
> If I ever understood RADIUS, trust has always been entirely=20
> hop-by-hop.
> The user connects at the NAS and trusts it to make a=20
> decision. The NAS sends a RADIUS request to a server it=20
> trusts to give it an accept or reject. That server in turn=20
> may query a database it trusts, or another RADIUS server that=20
> it trusts.=20
>=20
> Hiding credentials from proxies (by using a=20
> challenge-response protocol or an encrypted tunnel such as=20
> TTLS) is an orthogonal matter.=20
>=20
> If a local NAS or AAA doesn't want to trust his upstream=20
> AAA's, then the choice of authentication protocol would needs=20
> /very/ careful attention, to say the least. That there can be=20
> no notion of trusting your proxies, rules out every=20
> authentication protocol in current existence other than
> EAP-TTLSv1 or EAP-PEAPv2, if I see it correctly, both of=20
> which are in draft stage and hardly implemented yet.
>=20
> There's a fundamental issue: how can you ever sensibly ask=20
> someone you don't trust, whether or not to provide service to=20
> a user you don't know?
>=20
> I'd say, never query a proxy you don't trust, /unless/ you're=20
> using an EAP method that provides server authentication,=20
> message integrity, confidentiality, cryptographic binding,=20
> you only rely on the accept/reject messages inside the=20
> tunnel, and you've /thorougly/ verified your assumptions.
>=20
> Cheers,
>=20
>=20
> Emile.
>=20
> --=20
> E-Advies - Emile van Bergen           [email-masked]     =20
> tel. +31 (0)78 6136282           http://www.e-advies.nl   =20
>=20
> --
> to unsubscribe send a message to=20
> [email-masked] with the word 'unsubscribe' in=20
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 09 Sep 2005 20:48:54 +0000
Content-class: urn:content-classes:message
Subject: RE: Capabilities (was Re: AW: Review of draft-ietf-geopriv-radius-lo-04.txt )
Date: Fri, 9 Sep 2005 16:49:09 -0400
From: "Avi Lior" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, "Emile van Bergen" <[email-masked]>
Cc: "Nelson, David" <[email-masked]>, <[email-masked]>

Hi Bernard,
=20

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]]=20
> Sent: Friday, September 09, 2005 4:09 PM
> To: Emile van Bergen
> Cc: Avi Lior; Nelson, David; [email-masked]
> Subject: Re: Capabilities (was Re: AW: Review of=20
> draft-ietf-geopriv-radius-lo-04.txt )
>=20
> > In such deployments you simply send location in access request. The=20
> > local AAA determines whether he trusts the path towards home AAA=20
> > enough to forward location. End of story.
>=20
> That is certainly one way to configure the system, and it=20
> definitely simplifies things.=20

Absolutely.

> The question is why GEOPRIV has decided not to send location=20
> by default.=20

Initially we did exactly that we sent the location information in the
Access-Request.  But Geopriv being about privacy, was concerned what if
the user did not want to have their location exposed.

So now we have the case where in some systems, the user's policy of
whether or not to expose location is stored in the a database and during
authentication the AAA learns that policy.

> > But that advertisement is also an extra transaction. What's=20
> the home=20
> > AAA supposed to do, keep state from separate pseudo-authentications=20
> > that include the advertised information for later use? That doesn't=20
> > sound like RADIUS, at all.
=20
> Right.=20

Wrong.

No the advertizement is not an extra transaction.  It comes in the
Access-Request.

And by the way, RADIUS does keep transactional state.  But even if it
didn't upon receiving the Adevertizement it can respond with a challenge
right away.

>=20
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 09 Sep 2005 20:11:11 +0000
Content-class: urn:content-classes:message
Subject: RE: REMINDER: Final Review Comments DUE TODAY on RADIUS Digest Document
Date: Fri, 9 Sep 2005 16:04:09 -0400
From: "Nelson, David" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>

All aspects of RADEXT Issue 122 have been resolved in the -04 draft,
except for the following:

(1)

> The third paragraph contains the phrase "If the RADIUS client
recognizes
> the nonce...".  This could use some clarification.  The definition of
> "nonce" in Section 1.1 is "An unpredictable value...".  How is it
> possible for the RADIUS client to recognize an unpredictable value?
> Does this simply that the RADIUS client maintains a history of
recently
> used nonce values?  Or is there another meaning?
>=20
> Requested changes:
>=20
> Please add clarification.

I think what this text is trying to say is that:

"If the RADIUS client recognizes the presence of an HTTP Digest nonce
data element..."

What is being recognized is the data element, not the content of the
data element.

(2)

> Move Diameter gateway considerations to the Diameter SIP Application
> draft.
>=20
> 4.1 RADIUS Client Diameter Server
> 4.1 Diameter Client, RADIUS Server
> 4.3 Limitations
>=20
> Requested Changes:
>
> Delete these sections and add a general reference to the Diameter SIP
> draft.  This presumes, of course, that consensus is concurrently
> obtained in the AAA WG to make this change.

The delete part was accomplished, but the reference to the compatibility
description to appear in the Diameter SIP Application draft was not
added.  RADEXT WG work items must have *some* form of Diameter
Compatibility section, so at least a reference is required.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 09 Sep 2005 20:09:39 +0000
Date: Fri, 9 Sep 2005 13:09:24 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Emile van Bergen <[email-masked]>
cc: Avi Lior <[email-masked]>,  "Nelson, David" <[email-masked]>, [email-masked]
Subject: Re: Capabilities (was Re: AW: Review of draft-ietf-geopriv-radius-lo-04.txt )

> In such deployments you simply send location in access request. The
> local AAA determines whether he trusts the path towards home AAA enough
> to forward location. End of story.

That is certainly one way to configure the system, and it definitely 
simplifies things. 

The question is why GEOPRIV has decided not to send location by default. 

> But that advertisement is also an extra transaction. What's the home AAA
> supposed to do, keep state from separate pseudo-authentications that
> include the advertised information for later use? That doesn't sound
> like RADIUS, at all.

Right. 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 09 Sep 2005 19:32:10 +0000
Date: Fri, 9 Sep 2005 21:31:47 +0200
From: Emile van Bergen <[email-masked]>
To: Avi Lior <[email-masked]>
Cc: Bernard Aboba <[email-masked]>, "Nelson, David" <[email-masked]>, [email-masked]
Subject: Re: Capabilities (was Re: AW: Review of draft-ietf-geopriv-radius-lo-04.txt )
Mail-Followup-To: Avi Lior <[email-masked]>, Bernard Aboba <[email-masked]>, "Nelson, David" <[email-masked]>, [email-masked]

Hi,

On Thu, Sep 08, 2005 at 03:41:55PM -0400, Avi Lior wrote:

> Hi Bernard, 
> 
> > -----Original Message-----
> > From: [email-masked] 
> > [mailto:[email-masked]] On Behalf Of Bernard Aboba
> > Sent: Thursday, September 08, 2005 3:23 PM
> > To: Nelson, David
> > Cc: [email-masked]
> > Subject: RE: Capabilities (was Re: AW: Review of 
> > draft-ietf-geopriv-radius-lo-04.txt )
> > 
> > > > The RADIUS server may REQUIRE location in order to evaluate a 
> > > > authentication/authorization policy.  That policy could 
> > state that 
> > > > if location is not provided then allow the user on with certain 
> > > > constraints.
> > 
> > Yes, but the RADIUS server can do this *after* it has 
> > indicated that it requires the NAS to provide location 
> > information via an Access-Challenge. 
> > 
> > For example, the NAS initially does not send location 
> > information; the RADIUS server sends an Access-Challenge 
> > asking for it;  the NAS still does not send it, and then the 
> > RADIUS server sends an Access-Accept with limited 
> > authorizations, instead of an Access-Reject.  
> 
> Not exactly.  If the NAS does not support the above challenge, then it
> will terminate the session.
> 
> > In this scenario, there is still no need for "capabilities 
> > advertisement" by a NAS. 
> 
> I still think that there is.
> 
> There is also the efficiency aspect.  We should only challlenge for
> location if we know that the NAS supports it.  Otherwise we are invoking
> an extra transaction for nothing.

Isn't it the case that you only challenge for location if:

1. you didn't already receive location in the access request, because
the NAS or local AAA doesn't trust the proxy chain towards you;
2. you require location in order to determine the level of access you'll
grant;
3. you assume that suddenly the NAS will trust the proxies enough to
include location when challenged?

> It may be fine in simple enterprise solution to have these extra
> transactions.  But in large deployements with 50 million subs, this is
> not acceptable.

In such deployments you simply send location in access request. The
local AAA determines whether he trusts the path towards home AAA enough
to forward location. End of story.

> > > In the case of location information, what is the problem 
> > with the NAS 
> > > always providing any location information that it has to the RADIUS 
> > > server?
> > 
> > It may be undesirable for the NAS to send location by 
> > default.  But as argued earlier, this is not a problem -- the 
> > RADIUS server can ask for the information. 
> 
> But it SHOULD only do so when RADIUS Server knows that the NAS supports
> it.  A hence we need an advertizement.

But that advertisement is also an extra transaction. What's the home AAA
supposed to do, keep state from separate pseudo-authentications that
include the advertised information for later use? That doesn't sound
like RADIUS, at all.

If I may be blunt for a moment, this issue is so application specific
(not wanting to send an attribute that belongs in an access request the
first time 'round) that it doesn't warrant a generic new capability from
RADIUS.

What's the condition that the NAS uses whether or not to send the
attribute? I mean, it can show its capabilities for all it wants, but
that's information from it, not towards it to help it make its decision.

If it wants to base its decision whether or not to include Location on
whether or not the particular home AAA for that authentication will make
a different decision based on the value Location, then you need two
round trips anyway.

Or would you want the NAS to remember state per home AAA? It won't 
learn who the home AAA is from anything in RADIUS, so you can rule that
out if you want to keep the protocol sane.

If you have a RADIUS routing tree containing trusted and untrusted
proxies, and the NAS wants to know, guaranteed, what the full path will
be before doing the actual authentication in order to determine which
attributes it wants to include in its access request, then you need A. a
preauthentication (extra round trip! Just like challenge!) to learn the
path, B. a requirement for each proxy to include its identity and some
credentials in the access accept so that the NAS gets it, C. a guarantee
that a subsequent real authentication will take the exacy same path.

All that just does not seem reasonable. If you don't want to go that
far, then for the NAS to conditionally include Location in its access
request makes no sense, because it doesn't have enough information to
make that decision.

The only alternative model for conditionally sending Location is for
each hop to make the decision whether or not to include Location in
access requests proxied upstream, depending on its level of trust in the
upstream it's about to query.

Combine that with a requirement that a home AAA that uses Location to
base its access level on, MUST echo Location in its access accept, and
that IF a proxy passes it upstream (towards home AAA), it MUST also pass
it downstream (towards NAS).

Then, the NAS can always send Location if it trusts the RADIUS server it
sends the request to. Next, if the NAS doesn't get Location back, it can
conclude that it was not used by the home AAA to base its
accept/reject/access level decision on, and apply a local policy, such
as reject.

That means no challenges, no capability advertising, and a trust model
that's in line with RADIUS.

Cheers,

Emile.

-- 
E-Advies - Emile van Bergen           [email-masked]      
tel. +31 (0)78 6136282           http://www.e-advies.nl    

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Envelope-to: [email-masked]
Delivery-date: Fri, 09 Sep 2005 19:13:04 +0000
From: "Alan DeKok" <[email-masked]>
To: "Avi Lior" <[email-masked]>
Subject: Re: Capabilities (was Re: AW: Review of draft-ietf-geopriv-radius-lo-04.txt ) 
Cc: [email-masked]
Date: Fri, 09 Sep 2005 15:14:32 -0400
Message-Id: <[email-masked]>

"Avi Lior" <[email-masked]> wrote:
> The only debate that we are having which is specific to Location is
> whether or not the NAS advertizes its location capabilities in the
> access request.  Well Bernard thinks no, I think yes.  But regardless of
> that specific debate we already have evidence that a mechanism for
> advertizing the NAS capability is required -- CUI and Prepaid etc.....

  If that advertising mechanism is general, then it can be shared
across all capabilities, meaning this isn't a strictly
location-capability problem.

  I would also expect that NASes will *not* want to send all of the
available information for all capabilities.  Rather, they should send
an Access-Request with an "extended capability" notification, and
leave additional negotiations to later stages of the authentication
conversation.

  This, I believe, would address all issues.

  Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 09 Sep 2005 18:48:45 +0000
Date: Fri, 9 Sep 2005 20:48:23 +0200
From: Emile van Bergen <[email-masked]>
To: Bernard Aboba <[email-masked]>
Cc: "Nelson, David" <[email-masked]>, [email-masked]
Subject: Re: Capabilities (was Re: AW: Review of draft-ietf-geopriv-radius-lo-04.txt )
Mail-Followup-To: Bernard Aboba <[email-masked]>, "Nelson, David" <[email-masked]>, [email-masked]

Hi,

On Thu, Sep 08, 2005 at 12:22:51PM -0700, Bernard Aboba wrote:

> > > The RADIUS server may REQUIRE location in order to evaluate a
> > > authentication/authorization policy.  That policy could state that if
> > > location is not provided then allow the user on with certain
> > > constraints.
> 
> Yes, but the RADIUS server can do this *after* it has indicated that it 
> requires the NAS to provide location information via an Access-Challenge. 
> 
> For example, the NAS initially does not send location information; the 
> RADIUS server sends an Access-Challenge asking for it;  the NAS still does 
> not send it, and then the RADIUS server sends an Access-Accept with 
> limited authorizations, instead of an Access-Reject.  
> 
> In this scenario, there is still no need for "capabilities advertisement" 
> by a NAS. 
> 
> > In the case of location information, what is the problem with the NAS
> > always providing any location information that it has to the RADIUS
> > server?
> 
> It may be undesirable for the NAS to send location by default.  But as 
> argued earlier, this is not a problem -- the RADIUS server can ask for the 
> information. 
> 
> > If the issue is that the User wants the NAS to only disclose location to
> > RADIUS servers that he trusts, I think there is a lot of heavy lifting
> > to do.  
> 
> I'd argue that the only RADIUS server that a user can trust is its home 
> RADIUS server. There can be no notion of a user trusting intermediate 
> proxies.  

If I ever understood RADIUS, trust has always been entirely hop-by-hop.
The user connects at the NAS and trusts it to make a decision. The NAS
sends a RADIUS request to a server it trusts to give it an accept or
reject. That server in turn may query a database it trusts, or another
RADIUS server that it trusts. 

Hiding credentials from proxies (by using a challenge-response protocol
or an encrypted tunnel such as TTLS) is an orthogonal matter. 

If a local NAS or AAA doesn't want to trust his upstream AAA's, then the
choice of authentication protocol would needs /very/ careful attention,
to say the least. That there can be no notion of trusting your proxies,
rules out every authentication protocol in current existence other than
EAP-TTLSv1 or EAP-PEAPv2, if I see it correctly, both of which are in
draft stage and hardly implemented yet.

There's a fundamental issue: how can you ever sensibly ask someone you
don't trust, whether or not to provide service to a user you don't know?

I'd say, never query a proxy you don't trust, /unless/ you're using an
EAP method that provides server authentication, message integrity,
confidentiality, cryptographic binding, you only rely on the
accept/reject messages inside the tunnel, and you've /thorougly/
verified your assumptions.

Cheers,

Emile.

-- 
E-Advies - Emile van Bergen           [email-masked]      
tel. +31 (0)78 6136282           http://www.e-advies.nl    

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 09 Sep 2005 18:30:19 +0000
Date: Fri, 9 Sep 2005 11:29:47 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: REMINDER: Final Review Comments DUE TODAY on RADIUS Digest Document

The RADEXT WG will complete its final review of the RADIUS Digest document 
by Friday, September 9, 2005 (tommorrow).  If you have any remaining 
issues relating to this document, please submit them by end of day 
tommorrow.  

The document is available here: 
http://www.ietf.org/internet-drafts/draft-ietf-radext-digest-auth-04.txt

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 09 Sep 2005 15:32:44 +0000
Content-class: urn:content-classes:message
Subject: RE: Capabilities (was Re: AW: Review of draft-ietf-geopriv-radius-lo-04.txt )
Date: Fri, 9 Sep 2005 11:32:07 -0400
From: "Avi Lior" <[email-masked]>
To: "Nelson, David" <[email-masked]>, <[email-masked]>

Sure,

So if as a minimum using Bernards approach for the location document we
require to have a mechanism for the the Home Server to send a Challenge
requesting the NAS deliver location information.

Great.  That is one part of the capability exchange draft.

The only debate that we are having which is specific to Location is
whether or not the NAS advertizes its location capabilities in the
access request.  Well Bernard thinks no, I think yes.  But regardless of
that specific debate we already have evidence that a mechanism for
advertizing the NAS capability is required -- CUI and Prepaid etc.....

So I think both these abilities are needed.
=20

> -----Original Message-----
> From: Nelson, David [mailto:[email-masked]]=20
> Sent: Thursday, September 08, 2005 3:12 PM
> To: Avi Lior; [email-masked]
> Subject: RE: Capabilities (was Re: AW: Review of=20
> draft-ietf-geopriv-radius-lo-04.txt )
>=20
> Avi Lior writes...
>=20
> > BTW this is already in the capability draft...and there it=20
> is stronger=20
> > then just hints.  Because if the NAS says I support X and=20
> the Server=20
> > says I want X then the NAS MUST provide X.
>=20
> Yes, but I think the current thread is debating whether there=20
> is an actual *requirement* for the current capabilities=20
> draft, or something like it, or whether a simpler approach=20
> would work just as well.
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Envelope-to: [email-masked]
Delivery-date: Thu, 08 Sep 2005 22:13:21 +0000
From: "Alan DeKok" <[email-masked]>
To: "Sanchez, Mauricio (PNB Roseville)" <[email-masked]>
Subject: Re: Issue 100: Security Considerations (IEEE802 WG Last Call) 
Cc: [email-masked]
Date: Thu, 08 Sep 2005 18:14:50 -0400
Message-Id: <[email-masked]>

"Sanchez, Mauricio (PNB Roseville)" <[email-masked]> wrote:
> One could say that the cat is out of the bag. Section 7 was taken mostly
> from existing RFCs, in particular RFC3580.  The specific sentence your
> issue relates to already exists verbatim in RFC3580 section 5.3.  My
> proposal is to change the last sentence in section 7 to:
> 
> "For IEEE 802.X environments, best practices outlined in [RFC3580]
> mandate the use of different RADIUS shared secrets for IEEE 802.1X
> authentication and PAP authentication."
> 
> An normative reference will also need to be added to RFC3580 in section
> 8.1.

  This change would address any concerns I have.

  Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 08 Sep 2005 21:56:34 +0000
Content-class: urn:content-classes:message
Subject: Issue 130: Diameter Compatibility (IEEE 802 Last call) 
Date: Thu, 8 Sep 2005 14:56:10 -0700
From: "Sanchez, Mauricio (PNB Roseville)" <[email-masked]>
To: <[email-masked]>

Bernard writes...=20

> Issue 130: Diameter Compatibility
> Submitter name: Bernard Aboba
> Submitter email address: [email-masked] Date first=20
> submitted: August 29, 2005
> Reference:=20
> Document: IEEE802-00
> Comment type: T
> Priority: S
> Section: Various
> Rationale/Explanation of issue:
> The document does not contain a Diameter Compatibility=20
> section, as required by the RADEXT WG charter.=20
>=20
> In reviewing the document, there appears to a major=20
> compatibility problem between this document and Diameter=20
> NASREQ (RFC 4005).=20
>=20
> The NAS-Filter-Rule attribute defined in the document is not=20
> compatible with the NAS-Filter-Rule attribute defined in RFC=20
> 4005, which is based on the IPFilterRule type defined in RFC 3588.=20
> This incompatibility will break RADIUS/Diameter gateways.=20
> [Jari Arkko]  This is a problem.=20
>=20
> My suggestion is to define the restrict the NAS-Filter-Rule=20
> attribute to the RFC 3588 syntax, and define additional=20
> attributes for other purposes, such as Layer 2 filtering and=20
> HTTP redirect. It is ok if the same general syntax is used=20
> for these other filters, but they need to be defined as=20
> separate attributes to enable translation of NAS-Filter-Rule=20
> AVP from RADIUS to Diameter and back.
> [Jari Arkko] Sounds like a good suggestion to me.=20
> [John Loughney] I agree. Bernard's proposal seems reasonable.=20

Say we did break out NAS-Filter-Rule into multiple attributes, each with
its own type value.  How would I be able to guarantee strict ordering,
given that RADIUS proxies do not have to preserve order for attributes
of different types?  Maintenance of order is vital.

Cheers,
MS=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 08 Sep 2005 21:30:54 +0000
Content-class: urn:content-classes:message
Subject: Issue 100: Security Considerations (IEEE802 WG Last Call)
Date: Thu, 8 Sep 2005 14:30:28 -0700
From: "Sanchez, Mauricio (PNB Roseville)" <[email-masked]>
To: <[email-masked]>

Alan writes...

> Issue 100: Security Considerations
> Submitter name: Alan DeKok
> Submitter email address: [email-masked]
> Date first submitted: July 11, 2005
> Reference: http://ops.ietf.org/lists/radiusext/2005/msg00524.html
> Document: IEEE802-00
> Comment type: T
> Priority: S
> Section: 7.3
> Rationale/Explanation of issue:
> The last sentence of section 7 has strong new requirements on RADIUS
>=20
>   The last sentence of section 7 is also the last section of=20
> the document, and says:
>=20
>       In addition, the same RADIUS shared secret MUST NOT=20
> used for both=20
>       IEEE 802.1X authentication and PAP authentication.=20
>=20
>   It's a little surprising to have a requirement with such a=20
> large impact as the last sentence in the document, with no=20
> further discussion.
>=20
> This requirement means that it may be impossible for=20
> implementations to call themselves "unconditionally=20
> compliant".  Since RADIUS servers cannot control the=20
> authentication methods used by a NAS, there is no way for an=20
> implementation to know if a particular shared secret is used=20
> for IEEE 802.1X or PAP authentication.
>=20
> When a RADIUS server is proxying requests from one or more=20
> NASes to a home server, it may not have a choice about how=20
> many shared secrets it uses.  In order to satisfy the MUST in=20
> section 7.3, the proxying server MUST send send packets from=20
> two different IP addresses.  This configuration may not be=20
> possible in many deployments.
>=20
>   In addition, 802.1X devices may pass through EAP for user=20
> authentication, but also implement device administrator=20
> authentication via RADIUS.  Implementors should be guided as=20
> to how to implement administrator authentication without=20
> breaking the security of user authentication.
>=20
> Requested change:
>=20
>   1. Change the MUST to a SHOULD.
>=20
>   2. Add the following suggested text:
>=20
> 	Implementors are strongly cautioned to treat the=20
> preceding SHOULD
> 	as a MUST.  Issues with the RADIUS protocol prevent the above
> 	requirement from being a MUST in all deployments.
>=20
> 	If the device supports administrator authentication via RADIUS,
> 	that authentication MUST NOT use PAP.  That is, a device
> 	such as an access point that implements IEEE 802.1X
> 	authentication MUST NOT send a User-Password attribute in any
> 	Access-Request packet.  Another authentication method MUST be
> 	used, though we do not suggest one here.
>=20
> 	RADIUS server implementations that proxy both PAP and IEEE
> 	802.1X authentication to another RADIUS server SHOULD use
> 	multiple source IP addresses for the proxied packets.  Where
> 	this configuration is used, the implementation MUST NOT
> 	use the same source IP address for both IEEE 802.1X
> 	authentication and for PAP authentication.  In those
> 	deployments, the same RADIUS shared secret MUST NOT used for
> 	both IEEE 802.1X authentication and PAP authentication.

One could say that the cat is out of the bag. Section 7 was taken mostly
from existing RFCs, in particular RFC3580.  The specific sentence your
issue relates to already exists verbatim in RFC3580 section 5.3.  My
proposal is to change the last sentence in section 7 to:

"For IEEE 802.X environments, best practices outlined in [RFC3580]
mandate the use of different RADIUS shared secrets for IEEE 802.1X
authentication and PAP authentication."

An normative reference will also need to be added to RFC3580 in section
8.1.

Cheers,
MS=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 08 Sep 2005 20:32:10 +0000
Date: Thu, 8 Sep 2005 16:31:37 -0400
From: Barney Wolff <[email-masked]>
To: Bernard Aboba <[email-masked]>
Cc: "Nelson, David" <[email-masked]>, [email-masked]
Subject: Re: Capabilities (was Re: AW: Review of draft-ietf-geopriv-radius-lo-04.txt )

On Thu, Sep 08, 2005 at 12:22:51PM -0700, Bernard Aboba wrote:
> In this scenario, there is still no need for "capabilities advertisement" 
> by a NAS. 

In each and every case, there is probably some way to negotiate capabilities
individually; the question is whether there are enough cases to make a
general way to discover/negotiate capabilities worthwhile.

I have discomfort with endless efforts to turn RADIUS into a heavyweight
protocol, little less complex than Diameter.  But if you're going to do
it, one capability mechanism seems preferable to N.

-- 
Barney Wolff         http://www.databus.com/bwresume.pdf
I never met a computer I didn't like.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 08 Sep 2005 19:41:30 +0000
Content-class: urn:content-classes:message
Subject: RE: Capabilities (was Re: AW: Review of draft-ietf-geopriv-radius-lo-04.txt )
Date: Thu, 8 Sep 2005 15:41:55 -0400
From: "Avi Lior" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, "Nelson, David" <[email-masked]>
Cc: <[email-masked]>

Hi Bernard,=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Thursday, September 08, 2005 3:23 PM
> To: Nelson, David
> Cc: [email-masked]
> Subject: RE: Capabilities (was Re: AW: Review of=20
> draft-ietf-geopriv-radius-lo-04.txt )
>=20
> > > The RADIUS server may REQUIRE location in order to evaluate a=20
> > > authentication/authorization policy.  That policy could=20
> state that=20
> > > if location is not provided then allow the user on with certain=20
> > > constraints.
>=20
> Yes, but the RADIUS server can do this *after* it has=20
> indicated that it requires the NAS to provide location=20
> information via an Access-Challenge.=20
>=20
> For example, the NAS initially does not send location=20
> information; the RADIUS server sends an Access-Challenge=20
> asking for it;  the NAS still does not send it, and then the=20
> RADIUS server sends an Access-Accept with limited=20
> authorizations, instead of an Access-Reject. =20

Not exactly.  If the NAS does not support the above challenge, then it
will terminate the session.

> In this scenario, there is still no need for "capabilities=20
> advertisement"=20
> by a NAS.=20

I still think that there is.

There is also the efficiency aspect.  We should only challlenge for
location if we know that the NAS supports it.  Otherwise we are invoking
an extra transaction for nothing.

It may be fine in simple enterprise solution to have these extra
transactions.  But in large deployements with 50 million subs, this is
not acceptable.

=20
> > In the case of location information, what is the problem=20
> with the NAS=20
> > always providing any location information that it has to the RADIUS=20
> > server?
>=20
> It may be undesirable for the NAS to send location by=20
> default.  But as argued earlier, this is not a problem -- the=20
> RADIUS server can ask for the information.=20

But it SHOULD only do so when RADIUS Server knows that the NAS supports
it.  A hence we need an advertizement.

> > If the issue is that the User wants the NAS to only=20
> disclose location=20
> > to RADIUS servers that he trusts, I think there is a lot of heavy=20
> > lifting to do.
>=20
> I'd argue that the only RADIUS server that a user can trust=20
> is its home RADIUS server. There can be no notion of a user=20
> trusting intermediate proxies. =20

I agree with that.
=20
> --
> to unsubscribe send a message to=20
> [email-masked] with the word 'unsubscribe' in=20
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 08 Sep 2005 19:23:11 +0000
Date: Thu, 8 Sep 2005 12:22:51 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: "Nelson, David" <[email-masked]>
cc: [email-masked]
Subject: RE: Capabilities (was Re: AW: Review of draft-ietf-geopriv-radius-lo-04.txt )

> > The RADIUS server may REQUIRE location in order to evaluate a
> > authentication/authorization policy.  That policy could state that if
> > location is not provided then allow the user on with certain
> > constraints.

Yes, but the RADIUS server can do this *after* it has indicated that it 
requires the NAS to provide location information via an Access-Challenge. 

For example, the NAS initially does not send location information; the 
RADIUS server sends an Access-Challenge asking for it;  the NAS still does 
not send it, and then the RADIUS server sends an Access-Accept with 
limited authorizations, instead of an Access-Reject.  

In this scenario, there is still no need for "capabilities advertisement" 
by a NAS. 

> In the case of location information, what is the problem with the NAS
> always providing any location information that it has to the RADIUS
> server?

It may be undesirable for the NAS to send location by default.  But as 
argued earlier, this is not a problem -- the RADIUS server can ask for the 
information. 

> If the issue is that the User wants the NAS to only disclose location to
> RADIUS servers that he trusts, I think there is a lot of heavy lifting
> to do.  

I'd argue that the only RADIUS server that a user can trust is its home 
RADIUS server. There can be no notion of a user trusting intermediate 
proxies.  

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 08 Sep 2005 19:17:26 +0000
Date: Thu, 8 Sep 2005 12:17:20 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: "Nelson, David" <[email-masked]>
cc: [email-masked]
Subject: RE: Capabilities (was Re: AW: Review of draft-ietf-geopriv-radius-lo-04.txt )

> RADIUS has always embraced the notion of "hints" that the NAS may send
> to the RADIUS Server in an Access-Request.  It seems to me that your
> proposal might be thought of as "hints" that the RADIUS Server may send
> to the NAS in an Access-Challenge.  That does seem quite useful and
> quite elegant.

It is not only useful and elegant, it is also compatible with RFC 2865 - 
the best of all possible worlds. 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 08 Sep 2005 19:13:37 +0000
Content-class: urn:content-classes:message
Subject: RE: Capabilities (was Re: AW: Review of draft-ietf-geopriv-radius-lo-04.txt )
Date: Thu, 8 Sep 2005 15:11:53 -0400
From: "Nelson, David" <[email-masked]>
To: "Avi Lior" <[email-masked]>, <[email-masked]>

Avi Lior writes...

> BTW this is already in the capability draft...and there it is stronger
> then just hints.  Because if the NAS says I support X and the Server
> says I want X then the NAS MUST provide X.

Yes, but I think the current thread is debating whether there is an
actual *requirement* for the current capabilities draft, or something
like it, or whether a simpler approach would work just as well.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 08 Sep 2005 19:08:54 +0000
Content-class: urn:content-classes:message
Subject: RE: Capabilities (was Re: AW: Review of draft-ietf-geopriv-radius-lo-04.txt )
Date: Thu, 8 Sep 2005 15:09:28 -0400
From: "Avi Lior" <[email-masked]>
To: "Nelson, David" <[email-masked]>, <[email-masked]>

Hi David,

You could call it hints...

BTW this is already in the capability draft...and there it is stronger
then just hints.  Because if the NAS says I support X and the Server
says I want X then the NAS MUST provide X.

When we say hint it means to me that its up to the NAS to determine
whether it delivers X.=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Nelson, David
> Sent: Thursday, September 08, 2005 2:19 PM
> To: [email-masked]
> Subject: RE: Capabilities (was Re: AW: Review of=20
> draft-ietf-geopriv-radius-lo-04.txt )
>=20
> Alan DeKok Writes...
>=20
> >   For RADIUS conversations that don't use Access-Challenge, the=20
> > solution is to extend them to use Access-Challenge.  This is=20
> > "fail-safe" under the current design, in that existing=20
> implementations=20
> > will treat unsupported Access-Challenge as reject.  The=20
> method above=20
> > for capability exchange can then be used to enforce capability=20
> > requirements.
>=20
> RADIUS has always embraced the notion of "hints" that the NAS=20
> may send to the RADIUS Server in an Access-Request.  It seems=20
> to me that your proposal might be thought of as "hints" that=20
> the RADIUS Server may send to the NAS in an Access-Challenge.=20
>  That does seem quite useful and quite elegant.
>=20
>=20
> --
> to unsubscribe send a message to=20
> [email-masked] with the word 'unsubscribe' in=20
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 08 Sep 2005 19:06:11 +0000
Content-class: urn:content-classes:message
Subject: RE: Capabilities (was Re: AW: Review of draft-ietf-geopriv-radius-lo-04.txt )
Date: Thu, 8 Sep 2005 15:05:14 -0400
From: "Nelson, David" <[email-masked]>
To: "Avi Lior" <[email-masked]>, <[email-masked]>

Avi Lior writes...

> The RADIUS server may REQUIRE location in order to evaluate a
> authentication/authorization policy.  That policy could state that if
> location is not provided then allow the user on with certain
> constraints.

OK.  I can understand that.

In the case of location information, what is the problem with the NAS
always providing any location information that it has to the RADIUS
server?
=20
If the issue is that the User wants the NAS to only disclose location to
RADIUS servers that he trusts, I think there is a lot of heavy lifting
to do.  User to RADIUS Server trust is not established until the
successful completion of authentication.  In proxy environments there
may be several non-trusted RADIUS Servers in the proxy chain.  The User
can only establish a trust relationship with the Home RADIUS Server.

If the User's level of trust is not the issue, then what is?

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 08 Sep 2005 19:03:59 +0000
Content-class: urn:content-classes:message
Subject: RE: Capabilities (was Re: AW: Review of draft-ietf-geopriv-radius-lo-04.txt )
Date: Thu, 8 Sep 2005 15:04:26 -0400
From: "Avi Lior" <[email-masked]>
To: "Alan DeKok" <[email-masked]>
Cc: <[email-masked]>, "Bernard Aboba" <[email-masked]>

Hi Alan,

=20

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf=20
> Of Alan DeKok
> Sent: Thursday, September 08, 2005 2:26 PM
> To: Avi Lior
> Cc: [email-masked]; Bernard Aboba
> Subject: Re: Capabilities (was Re: AW: Review of=20
> draft-ietf-geopriv-radius-lo-04.txt )
>=20
> "Avi Lior" <[email-masked]> wrote:
> >  Hi Alan,
> >=20
> > See inline....
> ...
>=20
>   I concur with David's assesment.

No I don't because there is still a problem as I posted to Davids
statement.

You point this case out yourself here.

>   If the NAS SHOULD provide capabilites, then authentication=20
> can still succeed if the capabilities are not provided.  If=20
> the NAS MUST provide capabilites, then authentication MUST=20
> fail if the capabilities are not provided.

Not exactly.... If the NAS says I can provide location and it does not,
then the RADIUS server MAY still allow the session on.  But here it is
the RADIUS server deciding what really happens to the session.  With
Bernards approach we can have the session terminate when we don't want
it to terminate.
=20
>   The problem comes in when the RADIUS server wishes to=20
> handle the session differently, depending on the NAS=20
> capabilities.  If the RADIUS server challenges the NAS, the=20
> session MAY be dropped, even though the RADIUS server MAY be=20
> prepared to provide a lesser level of service.

Right....This is the case I am trying to get everyone to understand.

>   In that case, the NAS MUST always advertise it's new capabilities.
> The presence of the advertisement tells the RADIUS server=20
> that full capability negotiation is possible.  The absence of=20
> the advertisement tells the RADIUS server that no capability=20
> negotiation is possible.

Exactly.....
=20
>   One serious issue I had with the capabilities draft was=20
> that it discussed the above situation, but didn't require the=20
> NAS to always advertise it's capabilities.  I can't see how,=20
> then, the capability negotiation could proceed.

True...we could tighten the draft on this issue....but I assumed perhaps
incorrectly that if a NAS supports the capability-draft then it MUST
advertize what it can provide.  But we can tighten the specification.

I think you and I are on the same page now.

>   Is the above design sufficient for your needs?

Yes, to summarize:=20
Having a capability exchange for location -- that is the NAS indicating
its support for a feature is required to support the use case you
describe above and I described in various other emails.

=20
>   Alan DeKok.
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 08 Sep 2005 18:52:56 +0000
Content-class: urn:content-classes:message
Subject: RE: Capabilities (was Re: AW: Review of draft-ietf-geopriv-radius-lo-04.txt )
Date: Thu, 8 Sep 2005 14:53:21 -0400
From: "Avi Lior" <[email-masked]>
To: "Nelson, David" <[email-masked]>, <[email-masked]>

Hi David,

Please see inline....=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Nelson, David
> Sent: Thursday, September 08, 2005 1:58 PM
> To: [email-masked]
> Subject: RE: Capabilities (was Re: AW: Review of=20
> draft-ietf-geopriv-radius-lo-04.txt )
>=20
> Avi Lior writes...
>=20
> > However, if a RADIUS server challenges for location information and
> the
> > NAS does not support location information, the NAS will treat the=20
> > challenge as an Access-Reject and drop the session.
> >=20
> > The is problematic.  Because the RADIUS server may request location
> and
> > if it can't get the location information it may still want=20
> to provide=20
> > service.
>=20
> Bernard Aboba has previously argued, convincingly IMHO, that=20
> if the RADIUS server simply *wants* to get location=20
> information, it can request in the Access-Accept that=20
> location information be included in Accounting-Request=20
> messages, if it happens to be available at the NAS.
> If the RADIUS server *needs* to get location information,=20
> then the NAS would be doing the right thing to terminate the=20
> session when it does not support location.

This is where I think that we have an issue.

The RADIUS server may REQUIRE location in order to evaluate a
authentication/authorization policy.  That policy could state that if
location is not provided then allow the user on with certain
contstraints.

The current approach will not allow this to happen. In certain cases the
session will be rejected by the NAS.  So this is where I am consistantly
disagreeing with Bernard.=20

> > >   For (a), the NAS can simply drop any session where it=20
> doesn't get=20
> > > the information it needs.  The NAS *MUST* also advertise the=20
> > > information it needs in Access-Request packets, otherwise=20
> the RADIUS=20
> > > server won't know to send the information.  (The format of this=20
> > > advertisement is less of an
> issue.)
> >=20
> > You mean in Access-Accept not Access-Request right?
>=20
> The NAS doesn't send Access-Accept messages, so how could the=20
> NAS advertise its requirements in anything other than an=20
> Access-Request?

I guess it depends how you read the above statement.  But what we are
saying is:

The NAS must also advertize the information it needs in an Access-Accept
packet in an Access-Request packet.

Or something like that....

> --
> to unsubscribe send a message to=20
> [email-masked] with the word 'unsubscribe' in=20
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Envelope-to: [email-masked]
Delivery-date: Thu, 08 Sep 2005 18:24:40 +0000
From: "Alan DeKok" <[email-masked]>
To: "Avi Lior" <[email-masked]>
Subject: Re: Capabilities (was Re: AW: Review of draft-ietf-geopriv-radius-lo-04.txt ) 
Cc: [email-masked], "Bernard Aboba" <[email-masked]>
Date: Thu, 08 Sep 2005 14:26:19 -0400
Message-Id: <[email-masked]>

"Avi Lior" <[email-masked]> wrote:
>  Hi Alan,
> 
> See inline....
...

  I concur with David's assesment.

  If the NAS SHOULD provide capabilites, then authentication can still
succeed if the capabilities are not provided.  If the NAS MUST provide
capabilites, then authentication MUST fail if the capabilities are not
provided.

  The problem comes in when the RADIUS server wishes to handle the
session differently, depending on the NAS capabilities.  If the RADIUS
server challenges the NAS, the session MAY be dropped, even though the
RADIUS server MAY be prepared to provide a lesser level of service.

  In that case, the NAS MUST always advertise it's new capabilities.
The presence of the advertisement tells the RADIUS server that full
capability negotiation is possible.  The absence of the advertisement
tells the RADIUS server that no capability negotiation is possible.

  One serious issue I had with the capabilities draft was that it
discussed the above situation, but didn't require the NAS to always
advertise it's capabilities.  I can't see how, then, the capability
negotiation could proceed.

  Is the above design sufficient for your needs?

  Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 08 Sep 2005 18:20:13 +0000
Content-class: urn:content-classes:message
Subject: RE: Capabilities (was Re: AW: Review of draft-ietf-geopriv-radius-lo-04.txt )
Date: Thu, 8 Sep 2005 14:18:41 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Alan DeKok Writes...

>   For RADIUS conversations that don't use Access-Challenge, the
> solution is to extend them to use Access-Challenge.  This is
> "fail-safe" under the current design, in that existing implementations
> will treat unsupported Access-Challenge as reject.  The method above
> for capability exchange can then be used to enforce capability
> requirements.

RADIUS has always embraced the notion of "hints" that the NAS may send
to the RADIUS Server in an Access-Request.  It seems to me that your
proposal might be thought of as "hints" that the RADIUS Server may send
to the NAS in an Access-Challenge.  That does seem quite useful and
quite elegant.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 08 Sep 2005 17:59:24 +0000
Content-class: urn:content-classes:message
Subject: RE: Capabilities (was Re: AW: Review of draft-ietf-geopriv-radius-lo-04.txt )
Date: Thu, 8 Sep 2005 13:58:20 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Avi Lior writes...

> However, if a RADIUS server challenges for location information and
the
> NAS does not support location information, the NAS will treat the
> challenge as an Access-Reject and drop the session.
>=20
> The is problematic.  Because the RADIUS server may request location
and
> if it can't get the location information it may still want to provide
> service.

Bernard Aboba has previously argued, convincingly IMHO, that if the
RADIUS server simply *wants* to get location information, it can request
in the Access-Accept that location information be included in
Accounting-Request messages, if it happens to be available at the NAS.
If the RADIUS server *needs* to get location information, then the NAS
would be doing the right thing to terminate the session when it does not
support location.

> >   For (a), the NAS can simply drop any session where it
> > doesn't get the information it needs.  The NAS *MUST* also
> > advertise the information it needs in Access-Request packets,
> > otherwise the RADIUS server won't know to send the
> > information.  (The format of this advertisement is less of an
issue.)
>=20
> You mean in Access-Accept not Access-Request right?

The NAS doesn't send Access-Accept messages, so how could the NAS
advertise its requirements in anything other than an Access-Request?

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 08 Sep 2005 17:45:38 +0000
Content-class: urn:content-classes:message
Subject: RE: Capabilities (was Re: AW: Review of draft-ietf-geopriv-radius-lo-04.txt )
Date: Thu, 8 Sep 2005 13:46:05 -0400
From: "Avi Lior" <[email-masked]>
To: "Alan DeKok" <[email-masked]>, "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>

 Hi Alan,

See inline....

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Alan DeKok
> Sent: Thursday, September 08, 2005 1:02 PM
> To: Bernard Aboba
> Cc: [email-masked]
> Subject: Capabilities (was Re: AW: Review of=20
> draft-ietf-geopriv-radius-lo-04.txt )
>=20
> Bernard Aboba <[email-masked]> wrote:
> > [ re: location ]
> >
> > However, I don't see a need for "Capabilities Announcement"=20
> by the NAS.=20
>=20
>   I agree. =20

For location I don't agree.  Currently we all seem to agree that if the
RADIUS server wants location it simply challenges for the location
information.  No problem here.

However, if a RADIUS server challenges for location information and the
NAS does not support location information, the NAS will treat the
challenge as an Access-Reject and drop the session.

The is problematic.  Because the RADIUS server may request location and
if it can't get the location information it may still want to provide
service.

So the correct way to do this is to have the NAS advertize its location
capability and then the RADIUS server will know whether it should ask
for location.

In the case where a RADIUs server does not receive and advertizment it
may still challenge but then it will do so at the peril of having the
NAS reject the session.

This is a more complete solution don't you agree?

>For the larger capabilities case, I see the=20
> requirements as follows:
>=20
>  a) NAS requires information from the RADIUS server
>  b) RADIUS server requires the NAS implement X
>=20
>   For (a), the NAS can simply drop any session where it=20
> doesn't get the information it needs.  The NAS *MUST* also=20
> advertise the information it needs in Access-Request packets,=20
> otherwise the RADIUS server won't know to send the=20
> information.  (The format of this advertisement is less of an issue.)

You mean in Access-Accept not Access-Request right?

>   For (b), the current RADIUS spec says that it's permissible=20
> for NASes to ignore attributes they don't understand, making=20
> (b) impossible to satisfy in the current RADIUS system.
>=20
>   The solution discussed previously is two-fold.  For=20
> existing RADIUS conversations that use Access-Challenge, a=20
> "capability request"
> attribute can be sent by the RADIUS server to the NAS.  In=20
> order to be sure that the NAS supports that capability, the=20
> NAS must reply with an "capability ack" in the next Access-Request.

But if the NAS does not support this challenge it will drop the session.

>   For RADIUS conversations that don't use Access-Challenge,=20
> the solution is to extend them to use Access-Challenge.  This=20
> is "fail-safe" under the current design, in that existing=20
> implementations will treat unsupported Access-Challenge as=20
> reject.  The method above for capability exchange can then be=20
> used to enforce capability requirements.
>=20
>   In conclusion, I think a capabilities protocol outlined as=20
> above would be very useful, and would fit in with existing=20
> RADIUS deployments and practices.

However there is another way to achieve B)

The RADIUS server requires the NAS to deliver capability X based on what
it received during the advertizement.  This is far simpler.

If RADIUS requires NAS to deliver X it may send capbility X in the
access-accept.  Or it may sent capability x back in a Challenge.
Ofcourse if the NAS did not advertize that it supported X in the first
case then the RADIUS server should not send it.

If the NAS never advertized X and RADIUS request it then:
-if the NAS does not support capabillity it will simply ignore the
request
-if the NAS does not support challenge it and a challenge is used it
will reject.
Etc....

I think that this approach is far simpler.  No?

>   Alan DeKok.
>=20
> --
> to unsubscribe send a message to=20
> [email-masked] with the word 'unsubscribe' in=20
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Envelope-to: [email-masked]
Delivery-date: Thu, 08 Sep 2005 17:01:21 +0000
From: "Alan DeKok" <[email-masked]>
To: Bernard Aboba <[email-masked]>
Subject: Capabilities (was Re: AW: Review of draft-ietf-geopriv-radius-lo-04.txt )
Cc: [email-masked]
Date: Thu, 08 Sep 2005 13:02:29 -0400
Message-Id: <[email-masked]>

Bernard Aboba <[email-masked]> wrote:
> [ re: location ]
>
> However, I don't see a need for "Capabilities Announcement" by the NAS. 

  I agree.  For the larger capabilities case, I see the requirements
as follows:

 a) NAS requires information from the RADIUS server
 b) RADIUS server requires the NAS implement X

  For (a), the NAS can simply drop any session where it doesn't get
the information it needs.  The NAS *MUST* also advertise the
information it needs in Access-Request packets, otherwise the RADIUS
server won't know to send the information.  (The format of this
advertisement is less of an issue.)

  For (b), the current RADIUS spec says that it's permissible for
NASes to ignore attributes they don't understand, making (b)
impossible to satisfy in the current RADIUS system.

  The solution discussed previously is two-fold.  For existing RADIUS
conversations that use Access-Challenge, a "capability request"
attribute can be sent by the RADIUS server to the NAS.  In order to be
sure that the NAS supports that capability, the NAS must reply with an
"capability ack" in the next Access-Request.

  For RADIUS conversations that don't use Access-Challenge, the
solution is to extend them to use Access-Challenge.  This is
"fail-safe" under the current design, in that existing implementations
will treat unsupported Access-Challenge as reject.  The method above
for capability exchange can then be used to enforce capability
requirements.

  In conclusion, I think a capabilities protocol outlined as above
would be very useful, and would fit in with existing RADIUS
deployments and practices.

  Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 08 Sep 2005 12:26:06 +0000
Content-class: urn:content-classes:message
Subject: RE: REMINDER: Call for review of RFC 2618bis-2621bis
Date: Thu, 8 Sep 2005 08:23:10 -0400
From: "Nelson, David" <[email-masked]>
To: "Romascanu, Dan \(Dan\)" <[email-masked]>, "Bernard Aboba" <[email-masked]>, <[email-masked]>

> The rfc2620bis document is not available by now.

Yes.  I've opened a "ticket" with the Secretatiat to get this addressed.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 08 Sep 2005 09:28:46 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue 130:  Diameter Compatibility
Date: Thu, 8 Sep 2005 12:28:18 +0300
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

I agree, Bernard's proposal seems reasonable.

John=20

>-----Original Message-----
>From: [email-masked]=20
>[mailto:[email-masked]] On Behalf Of ext Jari Arkko
>Sent: 08 September, 2005 11:04
>To: Bernard Aboba
>Cc: [email-masked]
>Subject: Re: Issue 130: Diameter Compatibility
>
>Bernard Aboba wrote:
>
>>The NAS-Filter-Rule attribute defined in the document is not=20
>compatible=20
>>with the NAS-Filter-Rule attribute defined in RFC 4005, which=20
>is based=20
>>on the IPFilterRule type defined in RFC 3588.
>>This incompatibility will break RADIUS/Diameter gateways.=20
>> =20
>>
>This is a problem.
>
>>My suggestion is to define the restrict the NAS-Filter-Rule attribute=20
>>to the RFC 3588 syntax, and define additional attributes for other=20
>>purposes, such as Layer 2 filtering and HTTP redirect. It is=20
>ok if the=20
>>same general syntax is used for these other filters, but they need to=20
>>be defined as separate attributes to enable translation of=20
>>NAS-Filter-Rule AVP from RADIUS to Diameter and back.
>> =20
>>
>Sounds like a good suggestion to me.
>
>--Jari
>
>
>--
>to unsubscribe send a message to=20
>[email-masked] with the word 'unsubscribe' in=20
>a single line as the message text body.
>archive: <http://psg.com/lists/radiusext/>
>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 08 Sep 2005 08:04:30 +0000
Date: Thu, 08 Sep 2005 11:04:15 +0300
From: Jari Arkko <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC:  [email-masked]
Subject: Re: Issue 130:  Diameter Compatibility

Bernard Aboba wrote:

>The NAS-Filter-Rule attribute defined in the document is not 
>compatible with the NAS-Filter-Rule attribute defined in RFC 4005,
>which is based on the IPFilterRule type defined in RFC 3588. 
>This incompatibility will break RADIUS/Diameter gateways. 
>  
>
This is a problem.

>My suggestion is to define the restrict the NAS-Filter-Rule
>attribute to the RFC 3588 syntax, and define additional
>attributes for other purposes, such as Layer 2 filtering
>and HTTP redirect. It is ok if the same general syntax
>is used for these other filters, but they need to be 
>defined as separate attributes to enable translation of
>NAS-Filter-Rule AVP from RADIUS to Diameter and back. 
>  
>
Sounds like a good suggestion to me.

--Jari

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 08 Sep 2005 07:25:16 +0000
content-class: urn:content-classes:message
Subject: RE: REMINDER: Call for review of RFC 2618bis-2621bis
Date: Thu, 8 Sep 2005 10:24:55 +0300
From: "Romascanu, Dan \(Dan\)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>

The rfc2620bis document is not available by now.=20

Dan

=20
=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Thursday, September 08, 2005 10:07 AM
> To: [email-masked]
> Subject: REMINDER: Call for review of RFC 2618bis-2621bis
>=20
> The revised RADIUS MIB documents are now available on the=20
> IETF archive:
>=20
> http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2618b
> is-00.txt
> http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2619b
> is-00.txt
> http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2620b
> is-00.txt
> http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2621b
> is-00.txt
>=20
> Please send review comments to the RADEXT mailing list by=20
> September 17, 2005, using the format described on the RADEXT=20
> WG Issues list:
> http://www.drizzle.com/~aboba/RADEXT/
>=20
>=20
>=20
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 08 Sep 2005 07:07:28 +0000
Date: Thu, 8 Sep 2005 00:07:17 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: REMINDER: Call for review of RFC 2618bis-2621bis

The revised RADIUS MIB documents are now available on the IETF archive:

http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2618bis-00.txt
http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2619bis-00.txt
http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2620bis-00.txt
http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2621bis-00.txt

Please send review comments to the RADEXT mailing list by September 17, 
2005, using the format described on the RADEXT WG Issues list:
http://www.drizzle.com/~aboba/RADEXT/

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 08 Sep 2005 07:00:49 +0000
Date: Thu, 8 Sep 2005 00:00:35 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: REMINDER:  Review comments on RFC 3576 MIBs

So far, the RFC 3576 MIBs have received only 3 comments, from two 
individuals.  

In order to advance this document, we will need to get more affirmative 
response that WG participants have read it. 

If you have read the documents and believe they are ok, please post this 
indication to the RADEXT WG list. 

If you have read the documents and have an issue with them, please post 
the issue to the RADEXT WG list in the format described on the RADEXT WG 
web page:
http://www.drizzle.com/~aboba/RADEXT/

If you have not read the documents, please do so NOW:
http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-client-mib-01.txt
http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-server-mib-01.txt

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 08 Sep 2005 06:56:34 +0000
Date: Wed, 7 Sep 2005 23:56:13 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: REMINDER: Final Review Comments Requested on RADIUS Digest Document

The RADEXT WG will complete its final review of the RADIUS Digest document 
by Friday, September 9, 2005 (tommorrow).  If you have any remaining 
issues relating to this document, please submit them by end of day 
tommorrow.  

The document is available here: 
http://www.ietf.org/internet-drafts/draft-ietf-radext-digest-auth-04.txt

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 08 Sep 2005 06:41:05 +0000
Date: Wed, 7 Sep 2005 23:40:55 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Issue 130:  Diameter Compatibility

Issue 130: Diameter Compatibility
Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: August 29, 2005
Reference: 
Document: IEEE802-00
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:

The document does not contain a Diameter Compatibility section, as 
required 
by the RADEXT WG charter. 

In reviewing the document, there appears to a major compatibility
problem between this document and Diameter NASREQ (RFC 4005). 

The NAS-Filter-Rule attribute defined in the document is not 
compatible with the NAS-Filter-Rule attribute defined in RFC 4005,
which is based on the IPFilterRule type defined in RFC 3588. 
This incompatibility will break RADIUS/Diameter gateways. 

My suggestion is to define the restrict the NAS-Filter-Rule
attribute to the RFC 3588 syntax, and define additional
attributes for other purposes, such as Layer 2 filtering
and HTTP redirect. It is ok if the same general syntax
is used for these other filters, but they need to be 
defined as separate attributes to enable translation of
NAS-Filter-Rule AVP from RADIUS to Diameter and back. 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 08 Sep 2005 06:40:31 +0000
Date: Wed, 7 Sep 2005 23:40:03 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Issue 129: Editorial nits

Issue 129:  Editorial NITs
Submitter name: Paul Congdon
Submitter email address: [email-masked] Date first submitted:
08-10-2005
Reference: 
Document: IEEE 802 Extensions
Comment type: E
Priority: 1
Section: various
Rationale/Explanation of issue:

1. Pg 3, end of second paragraph. Seems like a reference to RFC3580
would be appropriate

2. Pg 3, middle of sixth paragraph. We aren't providing the 'full set'
of VLAN functionality either.  Suggest replacing "...the full set of
VLAN functionality" with "...a more complete set of VLAN functionality
as defined by IEEE 802.1Q-2003"
 
3. Pg 3, end of sixth paragraph.  Reference to IEEE-802.1Q should
probably be the Bridge-MIB or RFC 2674

4. Pg 4. The following terms aren't really used and should be removed;
Access Point (AP), Association, Port Access Entity (PAE), Stations
(STA).

5. Pg 10, 3.4 User-Priority-Table. The reference to 802.1D should
probably be 802.1D-2004.

6. Pg 10, 3.4 User-Priority-Table, 1st paragraph of String. There are 8
regenerated priorities, not 7.

7. Pg 12, First item 2). The way this item is worded it makes it sound
like you must have a flush rule present and as the first item.  Suggest
rewording as follows: Base encapsulation filter rules MUST appear after
a flush rule (if present) and before IP tunnel,...

8. Pg 12, first paragraph after list. If you only wanted to filter
specific traffic, but allow other stuff you would want the list to end
with an 'accept all' rule.  The behavior we have defined is more of a
firewall type behavior rather than a router behavior.  We should
document a syntax for the 'accept all' rule and make a note to the
implementer of how to do this.  Suggest adding a note that describes how
to terminate the list with a rule that allows all traffic.  I believe
the rule is: permit both ip from any to any.  We may need an L2 rule as
well.

9. Pg 12, last paragraph on Filter-ID and NAS-Filter-Rule.  The
paragraph is clumsy.  Suggest replacing the start of the second sentence
with, "These attributes are not intended to be used..."

10. Pg 15, Note: at top of page. Seems like a missing word or something
in the second sentence.  Suggest, "Also, [ports] optional argument is
not valid for ..."

11. Pg 17, Editorial note in Text section.  I think you can just delete
this now.  Isn't the text about fragmenting these below?

12. Pg 23, end of page. RFC 2866 and RFC 2867 are normative, but never
referenced.  Perhaps we should be referencing them somewhere or move
them to informative references.  Also, IEEE802.11i reference should be
IEEE80211i (all one word - no dot).

13. Pg 28, Acknowledgments. Since all the wireless stuff has been
removed, we can remove Dorothy Stanley of Agere from this list of names.

Requested change:

1. Change ending of last sentence to "...based on tunnel attributes in
[RFC2868] and usage of these in [RFC3580]."

2. Replace "...the full set of VLAN functionality" with "...a more
complete set of VLAN functionality as defined by IEEE 802.1Q-2003"

3. Replace "...to the MIB variables supported in [IEEE 802.1Q]." with
"...to the management variables supported in IEEE 802.1Q-2003 and MIB
objects defined by RFC 2674.

4. Remove Access Point (AP), Association, Port Access Entity (PAE),
Stations (STA).

5. Change 802.1D to IEEE 802.1D-2004

6. Change 'seven' to 'eight' in the first sentence of the Text
description

7. Change the start of item 2) to, "Base encapsulation filter rules MUST
appear after a flush rule (if present) and before IP tunnel,..."

8. Add a note to the text that describes how to terminate the list with
a rule that accepts everything else.  Perhaps the rule is: "permit both
ip from any to any"

9. Replace the start of the second sentence with, "These attributes are
not intended to be used..."

10. Replace start of second sentence with, "Also, [ports] optional
argument is not valid for ..."

11. Remove editorial note

12. Move RFC 2866 and RFC 2867 to informative section or reference them
somewhere normatively.  Also fix the typo in the 802.11i reference.

13. Remove Dorothy Stanley of Agere from this list of names.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 08 Sep 2005 05:58:12 +0000
Content-class: urn:content-classes:message
Subject: RE: RFC 3576bis Comments
Date: Thu, 8 Sep 2005 11:27:09 +0530
From: "Nagi Reddy Jonnala \(njonnala\)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>

Thank you for your comments. We'll incorporate these changes in the next
revision. =20

Does the WG have any more issues reg. terminology confusion?

Thanks
Nagi.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Bernard Aboba
Sent: Saturday, September 03, 2005 4:58 PM
To: [email-masked]
Subject: Re: RFC 3576bis Comments

Some additional comments on references.  These documents do not include
a normative reference to RFC 4001, but probably should:

   [RFC4001]  Daniele, M., Haberman, B., Routhier, S., and J.
              Schoenwaelder, "Textual Conventions for Internet Network
              Addresses", RFC 4001, February 2005.

On Sat, 3 Sep 2005, Bernard Aboba wrote:

> Some comments on draft-ietf-radext-dynauth-client-mib-01.txt. Most of=20
> these comments also apply to the dynauth-server-mib document.
>=20
> The initial sections could use some re-organization.  My suggestion is

> to start the document with Section 2 - Introduction.  Section 1
> (Requirements) would become Section 1.1, and Terminology would become=20
> Section 1.2.
>=20
> Section 2 (Introduction) refers to RFC 2619 and 2621.  It should also=20
> probably refer to the RFC 2619bis and RFC 2621bis documents.
>=20
> To address some of the terminology confusion, my suggestion is that=20
> the Terminology section be rewritten as follows:
>=20
> "1.2  Terminology
>=20
>    Dynamic Authorization Server (DAS)
>=20
>    The component that resides on the NAS which processes the=20
>    Disconnect and Change-of-Authorization (CoA) Request packets=20
>    [RFC3576] sent by the Dynamic Authorization Client.=20
>=20
>    Dynamic Authorization Client (DAC)
>=20
>    The component which sends Disconnect and CoA-Request packets=20
>    to the Dynamic Authorization Server.  While often residing on the=20
>    RADIUS server,  it is also possible for this component to
>    be located on a separate host, such as a Rating Engine. =20
>=20
>    Dynamic Authorization Server Port
>=20
>    The UDP port on which the Dynamic Authorization server listens for
>    the Disconnect and CoA requests sent by the Dynamic Authorization
>    Client."
>=20
> Section 5
>=20
> Rewrite the first paragraph:
>=20
> "5.  Overview
>=20
>    "Dynamic Authorization Extensions to RADIUS" [RFC3576] defines
>    the operation of Disconnect-Request, Disconnect-ACK,
Disconnect-NAK,
>    CoA-Request, CoA-ACK and CoA-NAK packets.  [DYNSERV] defines the
>    Dynamic Authorization Server MIB and the relationship with other
>    MIB modules.  This MIB module for the Dynamic Authorization
>    Client contains the following:"
>=20
>=20
> Capitalization
>=20
> The term "authenticator" is inconsistently capitalized. =20
>=20

--
to unsubscribe send a message to [email-masked] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 07 Sep 2005 06:37:06 +0000
Content-class: urn:content-classes:message
Subject: RE: RFC 3576bis Comments
Date: Tue, 6 Sep 2005 23:35:47 -0700
From: "Murtaza Chiba \(mchiba\)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C5B376.750BA647
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Thanks Bernard,  we will take care of these comments.

Regards,
Murtaza

-----Original Message-----
From: [email-masked] on behalf of Bernard Aboba
Sent: Sat 03-Sep-05 3:32
To: [email-masked]
Subject: RFC 3576bis Comments
=20
Some comments on draft-ietf-radext-dynauth-client-mib-01.txt. Most of=20
these comments also apply to the dynauth-server-mib document.=20

The initial sections could use some re-organization.  My suggestion is =
to=20
start the document with Section 2 - Introduction.  Section 1=20
(Requirements) would become Section 1.1, and Terminology would become=20
Section 1.2.

Section 2 (Introduction) refers to RFC 2619 and 2621.  It should also=20
probably refer to the RFC 2619bis and RFC 2621bis documents.=20

To address some of the terminology confusion, my suggestion is that the=20
Terminology section be rewritten as follows:

"1.2  Terminology

   Dynamic Authorization Server (DAS)

   The component that resides on the NAS which processes the=20
   Disconnect and Change-of-Authorization (CoA) Request packets=20
   [RFC3576] sent by the Dynamic Authorization Client.=20

   Dynamic Authorization Client (DAC)

   The component which sends Disconnect and CoA-Request packets=20
   to the Dynamic Authorization Server.  While often residing on the=20
   RADIUS server,  it is also possible for this component to
   be located on a separate host, such as a Rating Engine. =20

   Dynamic Authorization Server Port

   The UDP port on which the Dynamic Authorization server listens for
   the Disconnect and CoA requests sent by the Dynamic Authorization
   Client."

Section 5

Rewrite the first paragraph:

"5.  Overview

   "Dynamic Authorization Extensions to RADIUS" [RFC3576] defines
   the operation of Disconnect-Request, Disconnect-ACK, Disconnect-NAK,
   CoA-Request, CoA-ACK and CoA-NAK packets.  [DYNSERV] defines the
   Dynamic Authorization Server MIB and the relationship with other
   MIB modules.  This MIB module for the Dynamic Authorization
   Client contains the following:"

Capitalization

The term "authenticator" is inconsistently capitalized. =20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

------_=_NextPart_001_01C5B376.750BA647
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7233.8">
<TITLE>RE: RFC 3576bis Comments</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<BR>

<P><FONT SIZE=3D2>Thanks Bernard,&nbsp; we will take care of these =
comments.<BR>
<BR>
Regards,<BR>
Murtaza<BR>
<BR>
-----Original Message-----<BR>
From: [email-masked] on behalf of Bernard Aboba<BR>
Sent: Sat 03-Sep-05 3:32<BR>
To: [email-masked]<BR>
Subject: RFC 3576bis Comments<BR>
<BR>
Some comments on draft-ietf-radext-dynauth-client-mib-01.txt. Most =
of<BR>
these comments also apply to the dynauth-server-mib document.<BR>
<BR>
The initial sections could use some re-organization.&nbsp; My suggestion =
is to<BR>
start the document with Section 2 - Introduction.&nbsp; Section 1<BR>
(Requirements) would become Section 1.1, and Terminology would =
become<BR>
Section 1.2.<BR>
<BR>
Section 2 (Introduction) refers to RFC 2619 and 2621.&nbsp; It should =
also<BR>
probably refer to the RFC 2619bis and RFC 2621bis documents.<BR>
<BR>
To address some of the terminology confusion, my suggestion is that =
the<BR>
Terminology section be rewritten as follows:<BR>
<BR>
&quot;1.2&nbsp; Terminology<BR>
<BR>
&nbsp;&nbsp; Dynamic Authorization Server (DAS)<BR>
<BR>
&nbsp;&nbsp; The component that resides on the NAS which processes =
the<BR>
&nbsp;&nbsp; Disconnect and Change-of-Authorization (CoA) Request =
packets<BR>
&nbsp;&nbsp; [RFC3576] sent by the Dynamic Authorization Client.<BR>
<BR>
&nbsp;&nbsp; Dynamic Authorization Client (DAC)<BR>
<BR>
&nbsp;&nbsp; The component which sends Disconnect and CoA-Request =
packets<BR>
&nbsp;&nbsp; to the Dynamic Authorization Server.&nbsp; While often =
residing on the<BR>
&nbsp;&nbsp; RADIUS server,&nbsp; it is also possible for this component =
to<BR>
&nbsp;&nbsp; be located on a separate host, such as a Rating =
Engine.&nbsp;<BR>
<BR>
&nbsp;&nbsp; Dynamic Authorization Server Port<BR>
<BR>
&nbsp;&nbsp; The UDP port on which the Dynamic Authorization server =
listens for<BR>
&nbsp;&nbsp; the Disconnect and CoA requests sent by the Dynamic =
Authorization<BR>
&nbsp;&nbsp; Client.&quot;<BR>
<BR>
Section 5<BR>
<BR>
Rewrite the first paragraph:<BR>
<BR>
&quot;5.&nbsp; Overview<BR>
<BR>
&nbsp;&nbsp; &quot;Dynamic Authorization Extensions to RADIUS&quot; =
[RFC3576] defines<BR>
&nbsp;&nbsp; the operation of Disconnect-Request, Disconnect-ACK, =
Disconnect-NAK,<BR>
&nbsp;&nbsp; CoA-Request, CoA-ACK and CoA-NAK packets.&nbsp; [DYNSERV] =
defines the<BR>
&nbsp;&nbsp; Dynamic Authorization Server MIB and the relationship with =
other<BR>
&nbsp;&nbsp; MIB modules.&nbsp; This MIB module for the Dynamic =
Authorization<BR>
&nbsp;&nbsp; Client contains the following:&quot;<BR>
<BR>
<BR>
Capitalization<BR>
<BR>
The term &quot;authenticator&quot; is inconsistently =
capitalized.&nbsp;<BR>
<BR>
--<BR>
to unsubscribe send a message to [email-masked] with<BR>
the word 'unsubscribe' in a single line as the message text body.<BR>
archive: &lt;<A =
HREF=3D"http://psg.com/lists/radiusext/">http://psg.com/lists/radiusext/<=
/A>&gt;<BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C5B376.750BA647--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 06 Sep 2005 19:29:41 +0000
content-class: urn:content-classes:message
Subject: RE: Review of DIGEST-04 document
Date: Tue, 6 Sep 2005 12:33:59 -0700
From: "Salowey, Joe" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>

Issue 79 is mostly resolved by DIGEST-04.  The only thing that is not
covered is the discussion of the RADIUS proxy behavior from the list.  I
think the current text is sufficient unless someone thinks we need to
differentiate RADIUS proxy from RAIDUS server.=20

Joe

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]]=20
> Sent: Tuesday, August 30, 2005 8:39 AM
> To: [email-masked]
> Subject: Review of DIGEST-04 document
>=20
> A new version of the RADIUS Digest Authentication document is=20
> now available for inspection:
> http://www.drizzle.com/~aboba/RADEXT/draft-ietf-radext-digest-
> auth-04.txt
>=20
> When it shows up on the IETF archive, it will be available here:
> http://www.ietf.org/internet-drafts/draft-ietf-radext-digest-a
> uth-04.txt
>=20
> Please check the specification over carefully.  If you have=20
> submitted an issue, please post mail to the RADEXT WG mailing=20
> list indicating whether your issue has been resolved. =20
>=20
> We are asking that RADEXT WG participants complete their=20
> final review by Friday, September 9, 2005.=20
>=20
> --
> to unsubscribe send a message to=20
> [email-masked] with the word 'unsubscribe' in=20
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 06 Sep 2005 14:43:26 +0000
Cc: <[email-masked]>, <[email-masked]>, "Bernard Aboba" <[email-masked]>, <[email-masked]>
From: John Schnizlein <[email-masked]>
Subject: DHCP server location - was RE: Review of draft-ietf-geopriv-radius-lo-04.txt 
Date: Tue, 6 Sep 2005 10:43:06 -0400
To: "Tschofenig, Hannes" <[email-masked]>

Answering your question: I think there is no meaningful relationship 
between the location of the DHCP server and the host.  The utility of 
including the 'what' element value (zero) for the location of the DHCP 
server in draft-ietf-geopriv-dhcp-civil-06 has been questioned in IESG 
review as well.

John

On Sep 3, 2005, at 3:41 PM, Tschofenig, Hannes wrote:

> i have a question for you: you are the co-author of rfc 3825. now,
> consider the discussions we have in the emergency context (in geopriv &
> ecrit) and the idea to provide location information using dhcp to the
> end host for inclusion into an emergency call. do you think that there
> is a relationship between the location of the dhcp server/dhcp relay 
> and
> the location of the end host?

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sun, 04 Sep 2005 21:04:33 +0000
Date: Sun, 4 Sep 2005 14:03:52 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: "Tschofenig, Hannes" <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: AW: AW: Review of draft-ietf-geopriv-radius-lo-04.txt

> if we talk about location-based authorization and if this authorization
> step is mandatory then the radius server will ask the nas to provide
> location information and if he cannot provide it then an access reject
> must be sent. 

Right. 

> if the home network operator just wants to print location information to
> the bill (something like 'wlan hotspot at abc in munich') then the
> radius server might not want to send an access reject if the nas cannot
> provide it. maybe the best way to address this aspect is not to request
> location information with the access-challenge but later when accounting
> messages are exchanged. 

If the RADIUS server needs location info for authorization then it needs 
to send an Access-Challenge expressing that need.  If does not require 
location information in the Access-Request but would like it in the 
Accounting packets if available, it can include a "send location" 
attribute in an Access-Accept. 

Summary:

a. RADIUS Server REQUIRES location in Access-Request or 
Accounting-Request:  server sends an Access-Challenge with an attribute 
that expresses what is required. 

b. RADIUS server would like location information in the Accounting-Request 
but does not require it:  RADIUS server sends an Access-Accept with an 
attribute that expresses what is desired. 

c. RADIUS server REQUIRES location in Access-Request, but has not received 
it after sending an Access-Challenge:  RADIUS server 
sends an Access-Reject with an Error-Cause attribute with value "Missing 
Location Information"

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sun, 04 Sep 2005 14:46:50 +0000
Content-class: urn:content-classes:message
Subject: AW: AW: Review of draft-ietf-geopriv-radius-lo-04.txt
Date: Sun, 4 Sep 2005 16:46:27 +0200
From: "Tschofenig, Hannes" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

hi bernard,=20

> > The radius server might also understand either civic,=20
> geospatial or  both.=20
>=20
> We need to distinguish between the RADIUS Accounting Server=20
> and the RADIUS=20
> Authentication Server.  The RADIUS Accounting Server can be=20
> assumed to=20
> "understand" anything (e.g. it just writes AVPs to stable=20
> storage).  The=20
> RADIUS Server should be thought of as either REQUIRING or NOT=20
> REQUIRING an=20
> attribute.  If an attribute is REQUIRED the RADIUS Server=20
> will request it=20
> in an Access-Challenge. =20

if we talk about location-based authorization and if this authorization
step is mandatory then the radius server will ask the nas to provide
location information and if he cannot provide it then an access reject
must be sent.=20

if the home network operator just wants to print location information to
the bill (something like 'wlan hotspot at abc in munich') then the
radius server might not want to send an access reject if the nas cannot
provide it. maybe the best way to address this aspect is not to request
location information with the access-challenge but later when accounting
messages are exchanged.=20

ciao
hannes

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sun, 04 Sep 2005 14:27:04 +0000
Content-class: urn:content-classes:message
Subject: AW: AW: Review of draft-ietf-geopriv-radius-lo-04.txt
Date: Sun, 4 Sep 2005 16:26:20 +0200
From: "Tschofenig, Hannes" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

hi bernard,=20

i went through your suggestions and i don't think i have a disagreement
with what you say.=20

ciao
hannes

> > The radius server might also understand either civic,=20
> geospatial or  both.=20
>=20
> We need to distinguish between the RADIUS Accounting Server=20
> and the RADIUS=20
> Authentication Server.  The RADIUS Accounting Server can be=20
> assumed to=20
> "understand" anything (e.g. it just writes AVPs to stable=20
> storage).  The=20
> RADIUS Server should be thought of as either REQUIRING or NOT=20
> REQUIRING an=20
> attribute.  If an attribute is REQUIRED the RADIUS Server=20
> will request it=20
> in an Access-Challenge. =20
>=20
> > whether the desire to support this functionality justifies=20
> the introduction of an avp is subject for discussion.=20
>=20
> I think there is a need for an attribute to be sent from the=20
> RADIUS Server=20
> to the NAS to describe what it wants (e.g. Geospatial, Civil),
> what=20
> location is to be sent (user or NAS)),
>  and how it=20
> wants it.  Presumably this attribute can be sent in an=20
> Access-Challenge.=20
>=20
> There is also a need for location attributes, to be sent from=20
> the NAS to=20
> the RADIUS server.=20
>=20
> However, I don't see a need for "Capabilities Announcement"=20
> by the NAS.=20
> > this was the approach that was suggested to us in previous=20
> discussions.=20
> > sounds good to me.=20
>=20
> The Access-Challenge approach is ok only if it is made clear=20
> that a NAS=20
> that is not expecting an Access-Challenge MUST treat it as a=20
> Reject, as=20
> mandated in RFC 2865.  And of course, a RADIUS Server MAY=20
> send a Reject if=20
> the Challenge isn't answered correctly, so you need to=20
> support that case=20
> or the NAS/RADIUS server exchange could go on indefinitely.=20
>=20
> > i guess you would suggest to return an access reject if the nas is=20
> > unable to understand the returned location information format.=20
>=20
> The NAS can't send an Access-Reject.  It can only treat the=20
> Challenge as=20
> an Access-Reject.=20
>=20
> > this requirement hasn't been presented to me yet.=20
>=20
> Given that it's the RADIUS server that is determining what is needed,=20
> there needs to be a way for the server to actually request=20
> what it needs.  A=20
> given RADIUS server may require user location (there are=20
> installations=20
> today that do locatoin-based authorization) in geospatial or=20
> civil format.=20
> Or it just may need NAS location. =20
>=20
> > i hope it is simple.=20
>=20
> From the RADEXT WG discussion so far, it does appear to be=20
> quite simple. =20
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sun, 04 Sep 2005 14:26:56 +0000
Content-class: urn:content-classes:message
Subject: AW: AW: Review of draft-ietf-geopriv-radius-lo-04.txt
Date: Sun, 4 Sep 2005 16:26:29 +0200
From: "Tschofenig, Hannes" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>

hi bernard,=20

> > it is not uncommon to treat some topic as out-of-scope if=20
> they touch a
> > different area.=20
>=20
> I'd agree that communication of location between the NAS &=20
> user is out of=20
> scope -- but this specification is about communication=20
> between the NAS and=20
> AAA server, right? =20
true.=20

i understood your request as a 'please describe the mechanisms that are
used to determine the location of an end host'. i think that these
mechanisms do not belong into the document nor do i think we have the
experts in the ietf to provide a proper treatment of these mechanisms.
maybe i misunderstood your idea. =20

> > after reviewing all the mails regarding the review of
> > draft-ietf-geopriv-radius-lo-04.txt it appears that most issues are
> > refer to the capability exchange. i suspect that resolving the
> > capability exchange issue will resolve the main concerns.=20
>=20
> Yes.  The document already allows the "entities" to be specified.  It=20
> supports Civil and Geospatial location.  So much of the basic=20
> functionality is there. =20
>=20
> So all you really need is a way for the RADIUS server to=20
> communicate to=20
> the NAS what it needs (typically in an Access-Challenge). =20
> This is not=20
> difficult. =20
i agree with you.=20

>=20
>=20

ciao
hannes

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sun, 04 Sep 2005 13:12:00 +0000
Content-class: urn:content-classes:message
Subject: AW: Issue 86: Location Identifier in Location-Information Attribute
Date: Sun, 4 Sep 2005 15:11:09 +0200
From: "Tschofenig, Hannes" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>

hi jouni,=20

if i look at the http://www.itu.int/ITU-T/inr/forms/files/mnc_0605e.pdf
document then i get the impression that the=20
country can easy represented using a Location-Information attribute with
the countrycode element and the name of the network using Operator-Name
avp.=20

hence, i share your view about the express the same functionality using
existing mechanisms.=20

maybe there are other reasons to add such a location-id element/avp but
i cannot find anything at the moment.=20

ciao
hannes

> Hi Hannes,=20
>=20
> The proposed Location-Id 'feature' could actually be useful e.g.
> with UMA and 3GPP GAN services -- helping operators to differentiate
> service areas between WLAN hotspots and such. However, I still
> think one can exploit e.g. existing civic location TLVs such as LOC
> for the same purpose. =20
>=20
> Cheers,
> 	Jouni
>=20
>=20
> > -----Original Message-----
> > From: [email-masked]=20
> > [mailto:[email-masked]] On Behalf Of=20
> Tschofenig, Hannes
> > Sent: 3. syyskuuta 2005 23:16
> > To: [email-masked]; [email-masked]
> > Subject: Issue 86: Location Identifier in=20
> > Location-Information Attribute
> >=20
> > hi all,=20
> >=20
> > months ago lionel morand asked whether a 'location ID' (i.e., a
> > reference to location information) should be added to the=20
> > radius-geopriv
> > draft. this issue is described at:=20
> > http://www.drizzle.com/~aboba/RADEXT/#Issue%2086
> >=20
> > we rejected the request since there was no need to include=20
> a reference
> > since we provide the location itself. in his example the=20
> 'location id'
> > value refers to a list of predefined values for some=20
> operators. we can
> > easily provide the same functionality with a few more bits.=20
> > reduction of
> > a few bits was not seen as very important for this=20
> particular use case
> > only. no other person cared for this particular issue and asked for
> > providing this feature.=20
> >=20
> > now, in a private mail i was pointed to the same issue again.=20
> >=20
> > here is a link to a document that shows how the location id=20
> > (or actually
> > numbering plan) looks like=20
> > http://www.itu.int/ITU-T/inr/forms/files/mnc_0605e.pdf
> >=20
> > i still think that we don't need this.
> >=20
> > ciao
> > hannes
> >=20
> > --
> > to unsubscribe send a message to [email-masked] with
> > the word 'unsubscribe' in a single line as the message text body.
> > archive: <http://psg.com/lists/radiusext/>
> >=20
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sun, 04 Sep 2005 08:09:22 +0000
Date: Sun, 4 Sep 2005 01:08:53 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: "Tschofenig, Hannes" <[email-masked]>
cc: [email-masked]
Subject: Re: AW: Review of draft-ietf-geopriv-radius-lo-04.txt

> it is not uncommon to treat some topic as out-of-scope if they touch a
> different area. 

I'd agree that communication of location between the NAS & user is out of 
scope -- but this specification is about communication between the NAS and 
AAA server, right?  

> after reviewing all the mails regarding the review of
> draft-ietf-geopriv-radius-lo-04.txt it appears that most issues are
> refer to the capability exchange. i suspect that resolving the
> capability exchange issue will resolve the main concerns. 

Yes.  The document already allows the "entities" to be specified.  It 
supports Civil and Geospatial location.  So much of the basic 
functionality is there.  

So all you really need is a way for the RADIUS server to communicate to 
the NAS what it needs (typically in an Access-Challenge).  This is not 
difficult.  

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sun, 04 Sep 2005 07:57:19 +0000
Date: Sun, 4 Sep 2005 00:56:48 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: "Tschofenig, Hannes" <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: AW: Review of draft-ietf-geopriv-radius-lo-04.txt 

> i think you do not treat me fair with your statement that this issue has
> not been fixed 9 months later. 

The document does now support the notion of entities, so it is possible 
for the NAS to send user or NAS location.  What is missing is a way for 
the RADIUS server to request a particular type of location (or state that 
it doesn't care).  

Other standards in this area (such as IEEE 802.11k) do explicitly support 
both NAS and user location, and differentiate between the two, so this is 
a well accepted concept. 

Aside from the carrier scenarios described in the document, there are 
other uses for location information.  For example, there are factories 
keeping track of parts; defense facilities that track the location of 
users accessing the network; AAA products that support "location-aware 
access control".  

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sun, 04 Sep 2005 05:25:53 +0000
Date: Sat, 3 Sep 2005 22:25:47 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: "Tschofenig, Hannes" <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Subject: Re: AW: Review of draft-ietf-geopriv-radius-lo-04.txt 

> in a small network (such as a wlan hotspot) it might not really matter
> whether you provide the location of the end host or the nas since it
> might be almost the same (depending on the granularity of the location
> information). a lot depends on the deployment scenario. 

Sure.  There are some RADIUS servers that might not care.  They can 
indicate that in their Access-Challenge.  But there are other situations 
where it *definitely* matters.  For example, there are military 
installations that most definitely care if the user is on the military 
base near the AP, or outside the base attempting to break in using a high 
gain antenna.  

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sun, 04 Sep 2005 05:22:47 +0000
Date: Sat, 3 Sep 2005 22:22:38 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: "Tschofenig, Hannes" <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Subject: Re: AW: [Geopriv] RE: Review of draft-ietf-geopriv-radius-lo-04.txt

> we tried to respect the fact that people indicated that there might be a
> scenario where the nas does not know the location of the end host. if
> this is the case then the nas can only send its own location
> information. if it can include the location information of the end host
> (in case it is known) then the more precise info is sent. 

Right, but if the RADIUS server *requires* user location, that is what it 
will ask for in the Access-Challenge, and if the NAS doesn't supply it, it 
will send an Access-Reject eventually.   If the RADIUS server only wants 
NAS location, it can ask for that, or I suppose it could say "send me 
either one".  But the point is that it is the RADIUS server that is 
driving this conversation. 

> you seem to suggest that we add functionality to allow the radius server
> to request what information (end host vs. nas) it would like to see. we
> haven't yet heard this requirement and hence we haven't added it. 

Several of the high end 802.11 switches support location today, and there 
are location-based authorization servers on the market that are being 
deployed.   Typically, the APs utilize ToA processing to estimate location 
within a few feet.  So this is a real need and probably will garner at 
least as much (if not more) deployment than NAS location.  

In any case, since the document already supports an "Entity" field it is 
already possible for a NAS to send user location using the existing 
attributes.  What is missing is the ability of the RADIUS server to 
request the "entity" that it is interested in. 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sun, 04 Sep 2005 05:14:29 +0000
Date: Sat, 3 Sep 2005 22:13:57 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: "Tschofenig, Hannes" <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: AW: Review of draft-ietf-geopriv-radius-lo-04.txt

> The radius server might also understand either civic, geospatial or  both. 

We need to distinguish between the RADIUS Accounting Server and the RADIUS 
Authentication Server.  The RADIUS Accounting Server can be assumed to 
"understand" anything (e.g. it just writes AVPs to stable storage).  The 
RADIUS Server should be thought of as either REQUIRING or NOT REQUIRING an 
attribute.  If an attribute is REQUIRED the RADIUS Server will request it 
in an Access-Challenge.  

> whether the desire to support this functionality justifies the introduction of an avp is subject for discussion. 

I think there is a need for an attribute to be sent from the RADIUS Server 
to the NAS to describe what it wants (e.g. Geospatial, Civil), what 
location is to be sent (user or NAS)),  and how it 
wants it.  Presumably this attribute can be sent in an Access-Challenge. 

There is also a need for location attributes, to be sent from the NAS to 
the RADIUS server. 

However, I don't see a need for "Capabilities Announcement" by the NAS. 

> this was the approach that was suggested to us in previous discussions. 
> sounds good to me. 

The Access-Challenge approach is ok only if it is made clear that a NAS 
that is not expecting an Access-Challenge MUST treat it as a Reject, as 
mandated in RFC 2865.  And of course, a RADIUS Server MAY send a Reject if 
the Challenge isn't answered correctly, so you need to support that case 
or the NAS/RADIUS server exchange could go on indefinitely. 

> i guess you would suggest to return an access reject if the nas is 
> unable to understand the returned location information format. 

The NAS can't send an Access-Reject.  It can only treat the Challenge as 
an Access-Reject. 

> this requirement hasn't been presented to me yet. 

Given that it's the RADIUS server that is determining what is needed, 
there needs to be a way for the server to actually request what it needs.  A 
given RADIUS server may require user location (there are installations 
today that do locatoin-based authorization) in geospatial or civil format. 
Or it just may need NAS location.  

> i hope it is simple. 

>From the RADEXT WG discussion so far, it does appear to be quite simple.  

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sun, 04 Sep 2005 02:00:44 +0000
Date: Sat, 03 Sep 2005 22:00:14 -0400
To: "Tschofenig, Hannes" <[email-masked]>, "Bernard Aboba" <[email-masked]>,<[email-masked]>
From: "Joel M. Halpern" <[email-masked]>
Subject: Re: AW: Review of draft-ietf-geopriv-radius-lo-04.txt 
Cc: <[email-masked]>

I certainly felt (and still feel) that this issue had been resolved in a 
fair and clear fashion.
Yours,
Joel

At 03:36 PM 9/3/2005, Tschofenig, Hannes wrote:
>hi bernard,
>
>i guess there is a misunderstand here with regard to the functionality
>of the radius-geopriv draft.
>joel raised this issue and we discussed it.
>
>we always supported the idea of providing location for the end host. we
>had a very, very long discussion about this topic when we merged the two
>radius-geopriv drafts.
>
>what has been changed as part of joel's issue was
>- the name of the avp (since it was misleading) and
>- the description to address joel's comments
>
>this issue has been resolved on the mailing list and i also had further
>off-list discussions with joel.
>
>i think you do not treat me fair with your statement that this issue has
>not been fixed 9 months later.
>
>ciao
>hannes
>
> > > > > Am I missing something, or is the problem really this simple?
> > > >
> > > >   It would appear so.
> >
> > The "server-driven" approach also provides a mechanism to
> > address RADEXT
> > Issue 27 (Who's Location).
> >
> > One of the major problems with the RADIUS-GEOPRIV document is that it
> > does not support user location determination, only  NAS location.
> >
> > This is a problem for vendors who are shipping APs with built-in
> > location support that enables APs to pinpint the location of
> > associated
> > stations.  At least one RADIUS server implementation now supports
> > "location-based access control".  Why can't the RADIUS-GEOPRIV
> > specification be used to send user as well as NAS location?
> >
> > This basic problem with the document was pointed out in
> > November 2004, but
> > has still not been fixed in August 2005, 9 months later.
> >
> > However, using the "server-driven" approach, the problem would
> > not be hard to address.  In the "send location" attribute
> > included by the
> > server, the server can specify what type of location data it
> > is looking
> > for - user or NAS.
> >
> > Note that layer 2 standards such as IEEE 802.11k already enable this
> > distinction.  In IEEE 802.11k a station can ask either for its own
> > location or the location of the AP.
> >
> > --
> > to unsubscribe send a message to [email-masked] with
> > the word 'unsubscribe' in a single line as the message text body.
> > archive: <http://psg.com/lists/radiusext/>
> >
>
>--
>to unsubscribe send a message to [email-masked] with
>the word 'unsubscribe' in a single line as the message text body.
>archive: <http://psg.com/lists/radiusext/>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sun, 04 Sep 2005 00:49:03 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue 86: Location Identifier in Location-Information Attribute
Date: Sun, 4 Sep 2005 03:48:16 +0300
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>

Hi Hannes,=20

The proposed Location-Id 'feature' could actually be useful e.g.
with UMA and 3GPP GAN services -- helping operators to differentiate
service areas between WLAN hotspots and such. However, I still
think one can exploit e.g. existing civic location TLVs such as LOC
for the same purpose. =20

Cheers,
	Jouni

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Tschofenig, Hannes
> Sent: 3. syyskuuta 2005 23:16
> To: [email-masked]; [email-masked]
> Subject: Issue 86: Location Identifier in=20
> Location-Information Attribute
>=20
> hi all,=20
>=20
> months ago lionel morand asked whether a 'location ID' (i.e., a
> reference to location information) should be added to the=20
> radius-geopriv
> draft. this issue is described at:=20
> http://www.drizzle.com/~aboba/RADEXT/#Issue%2086
>=20
> we rejected the request since there was no need to include a reference
> since we provide the location itself. in his example the 'location id'
> value refers to a list of predefined values for some operators. we can
> easily provide the same functionality with a few more bits.=20
> reduction of
> a few bits was not seen as very important for this particular use case
> only. no other person cared for this particular issue and asked for
> providing this feature.=20
>=20
> now, in a private mail i was pointed to the same issue again.=20
>=20
> here is a link to a document that shows how the location id=20
> (or actually
> numbering plan) looks like=20
> http://www.itu.int/ITU-T/inr/forms/files/mnc_0605e.pdf
>=20
> i still think that we don't need this.
>=20
> ciao
> hannes
>=20
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sat, 03 Sep 2005 20:55:29 +0000
Date: Sat, 3 Sep 2005 16:47:27 -0400
From: Barney Wolff <[email-masked]>
To: Bernard Aboba <[email-masked]>
Cc: [email-masked]
Subject: Review of draft-lior-radext-end-to-end-caps-01.txt

Some comments on draft-lior-radext-end-to-end-caps-01.txt :

1.1  s/different then/different than/
     s/ensure whether/discover whether/ or /ensure that/

2  The section should specify the ordering of bit-pairs in bytes,
that bit-pair numbering begins with zero, and that bit-pair value
01 is reserved and MUST NOT be sent.  Some statement should specify
the suggested action by the receiver of an invalid attribute value.

6  As each capability takes 2 bits, the correct max value is 1011,
not 2023.

7  Only the action of a proxy of different administrative domain
than that of the NAS or server should be restricted, imho.

9  s/helpfull/helpful/  s/Wolf/Wolff/

Regards,
Barney

-- 
Barney Wolff         http://www.databus.com/bwresume.pdf
I never met a computer I didn't like.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sat, 03 Sep 2005 20:15:55 +0000
Content-class: urn:content-classes:message
Subject: Issue 86: Location Identifier in Location-Information Attribute
Date: Sat, 3 Sep 2005 22:15:30 +0200
From: "Tschofenig, Hannes" <[email-masked]>
To: <[email-masked]>, <[email-masked]>

hi all,=20

months ago lionel morand asked whether a 'location ID' (i.e., a
reference to location information) should be added to the radius-geopriv
draft. this issue is described at:=20
http://www.drizzle.com/~aboba/RADEXT/#Issue%2086

we rejected the request since there was no need to include a reference
since we provide the location itself. in his example the 'location id'
value refers to a list of predefined values for some operators. we can
easily provide the same functionality with a few more bits. reduction of
a few bits was not seen as very important for this particular use case
only. no other person cared for this particular issue and asked for
providing this feature.=20

now, in a private mail i was pointed to the same issue again.=20

here is a link to a document that shows how the location id (or actually
numbering plan) looks like=20
http://www.itu.int/ITU-T/inr/forms/files/mnc_0605e.pdf

i still think that we don't need this.

ciao
hannes

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sat, 03 Sep 2005 19:49:56 +0000
Content-class: urn:content-classes:message
Subject: AW: Review of draft-ietf-geopriv-radius-lo-04.txt
Date: Sat, 3 Sep 2005 21:42:03 +0200
From: "Tschofenig, Hannes" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>

hi bernard,=20

please find my comments below:=20

> Review of draft-ietf-geopriv-radius-lo-04.txt
>=20
> The RADEXT WG Issues page discloses that 13 issues remain open against
> this document:
> http://www.drizzle.com/~aboba/RADEXT/
>=20
> Based on a preliminary review of the -04 version, it appears that some
> of these open issues still have not been addressed.  Some=20
> notes below:=20
>=20
> Section 2
>=20
> "  Furthermore, the authors believe that there is a relationship
>    between the location of the network and the location of the entity
>    that triggered the network access authentication.  Knowing the
>    location of a network (where the user or end host is attached to)
>    might in many networks also reveal the location of the user or end
>    host.  In some networks it is even possible to provide a accurate
>    location of the user or end host.  A similar assumption is=20
> also made
>    with regard to the location information obtained via DHCP (see for
>    example [4]).  This information might be used by applications in
>    other protocols (such as SIP [12] with extensions [13]) to indicate
>    the location of a particular user even though the location "only"
>    refers to the location of the network or equipment within the
>    network.  The assumption here is also that the location of the
>    network has some relationship to the location of the end host (and
>    subsequently to a user).  This assumption might not hold in all
>    scenarios.  Nevertheless, it seems to be reasonable."
>=20
> RADEXT Issue 27 points out that this assumption is
> not correct -- the location of the peer and the location of the
> NAS are not the same thing.  There are APs today that are capable
> of providing the location of the user with a high degree of accuracy.=20
> Can those APs use this specification to provide the NAS and peer
> location information independently?=20

i guess this is an issue that we could potentially discuss forever.=20
in fact we discussed this issue for a long time and this particular
paragraph was added based on joel's comments.=20

technology exists to determine the location of the end host. the draft
allows to add this location information for transmission to the radius
server. if the location of the end host cannot be determined then all
you can do is to provide information about the nas (since you don't have
anything else).=20

>=20
> Section 3.2
>=20
> RADEXT Issue 74 points out problems with the way this document uses
> RFC 3576. =20
>=20
>    The COA message may instruct the
>    access network to generate an Authorize-Only=20
> Access-Request (Access-
>    Request with Service-Type set to "Authorize-Only") in=20
> which case the
>    NAS MUST include the location infromation in this Access-Request.
>=20
> This paragraph appears to retroactively update RFC 3576. =20
>=20
>    Upon receiving the Authorize-Only message from the access network,
>    the AAA server MUST respond with either an Access-Accept message or
>    an Access-Reject message.
>=20
> This also sounds like an update of RFC 3576.  Why should RFC 3576=20
> behavior be different when location attributes are included?=20
>=20
> More fundamentally, why does RFC 3576 need to be used to=20
> obtain location=20
> information in mid-session when the same info is available in=20
> Accounting=20
> packets?  Or is the issue that location data may not be included in=20
> Interim accounting information? I didn't notice a way that the RADIUS
> server can configure the way the NAS sends location info=20
> (e.g. don't send=20
> in interims, send at a given interval different from the=20
> interim interval,=20
> etc.)

i need to forward this issue to avi since he wrote this paragraph.=20

>=20
> Section 4
>=20
>    How the network obtains the user's
>    location information is out of the scope of this document.=20
>=20
> See RADEXT Issue 27.  Obtaining the peer location is one of the
> fundamental usage scenarios for RADIUS-based location information.
> If this is out of scope for this specification, a different=20
> specification will be needed to address that issue.  Why not handle
> both issues within the same document?=20

the technology for location determination of the end hosts location
information depends on factors that are outside the scope of this
document. manual configuration, triangulation, usage of location
protocols developed in other standardization organization, etc. are
examples.=20

it is not uncommon to treat some topic as out-of-scope if they touch a
different area.=20

>=20
> Section 8
>=20
>    The capability attribute allows the RADIUS client to=20
> indicate whether
>    civic and/or geospatial location information can be provided to the
>    RADIUS server.  This is useful to avoid sending location=20
> information
>    with every request if no further out-of-band arrangements are made
>    with regard to the transport of location information.  The=20
> AAA server
>    uses the capability attribute to indicate that the AAA=20
> client has to
>    provide civic and/or geospatial location information as=20
> part of this
>    particular protocol exchange.  If the AAA server does not send a
>    capability attribute then the AAA client MUST NOT return location
>    information.  The user's authorization policies MUST be=20
> consulted by
>    the AAA server before requesting location information delivery from
>    the AAA client.  If the AAA server encounters that the AAA client
>    does not support the desired location information it might respond
>    with an Access-Reject with the corresponding error cause attribute
>    (with the Location-Info-Required error code).
>=20
> The above paragraph seems vague about the nature of the capability
> negotiation.  Terms like "might respond" imply a range of
> acceptable behaviors, which could result in interoperability=20
> problems.=20
>=20
> Since Access-Requests are initiated by the NAS, there is no way
> for the NAS to know beforehand whether a given RADIUS server requires
> location information or not.  However, a NAS might default to not
> sending location information and then if the AAA server sends back
> an Access-Reject with a Location-Info-Required error code, then it
> could enable it.  This seems to handle the case where the RADIUS
> server requires location (e.g. won't grant access without it).=20
>=20
> Based on the rest of Section 8, it appears that there are other
> scenarios in which the RADIUS server might like location information=20
> if available, but does not require it.   In these cases, the=20
> RADIUS server could send back an Access-Accept with a request for
> location information, specifying what kind of location it is
> asking for (NAS or peer). If the NAS does not understand
> the attribute it will ignore it.
>=20
> Overall, it is not clear to me why the Capability attribute=20
> is needed, or=20
> if so, what the goal is. =20

i have read your other mails about this subject as well and i appreciate
to receive feedback about it.
it is good to hear opinion from other people.=20

if people in general think that the capability exchange is not need and
other mechanisms provide similar characteristics (as discussed in other
mails) than i am happy to change it.=20

>=20
> Section 11
>=20
> Why is a capability attribute needed in an Access-Challenge?  Why
> is "Location-Info-Required" a new attribute rather than a value
> of Error-Cause?  Why are Basic-Policy-Rules, Extended-Policy-Rules,
> Capability and Location-Info-Required attributes allowed in an=20
> Access-Reject?

i incorporated this proposal based on the feedback i got. now, i get the
feedback i want and that's good.=20
unfortunately it turns out to be quite complicated to have two working
groups working on a single document. i wasn't even able to attend the
ietf#62 meeting where this particular issue was discussed (since it was
ironically conflicting with the geopriv meeting, if i remember it
correctly).=20

after reviewing all the mails regarding the review of
draft-ietf-geopriv-radius-lo-04.txt it appears that most issues are
refer to the capability exchange. i suspect that resolving the
capability exchange issue will resolve the main concerns.=20

ciao
hannes
=20
>=20
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sat, 03 Sep 2005 19:46:15 +0000
Content-class: urn:content-classes:message
Subject: AW: Review of draft-ietf-geopriv-radius-lo-04.txt 
Date: Sat, 3 Sep 2005 21:36:40 +0200
From: "Tschofenig, Hannes" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

hi bernard,=20

i guess there is a misunderstand here with regard to the functionality
of the radius-geopriv draft.=20
joel raised this issue and we discussed it.=20

we always supported the idea of providing location for the end host. we
had a very, very long discussion about this topic when we merged the two
radius-geopriv drafts.

what has been changed as part of joel's issue was
- the name of the avp (since it was misleading) and
- the description to address joel's comments

this issue has been resolved on the mailing list and i also had further
off-list discussions with joel.

i think you do not treat me fair with your statement that this issue has
not been fixed 9 months later.=20

ciao
hannes

> > > > Am I missing something, or is the problem really this simple?=20
> > >=20
> > >   It would appear so.
>=20
> The "server-driven" approach also provides a mechanism to=20
> address RADEXT=20
> Issue 27 (Who's Location).=20
>=20
> One of the major problems with the RADIUS-GEOPRIV document is that it=20
> does not support user location determination, only  NAS location.=20
>=20
> This is a problem for vendors who are shipping APs with built-in=20
> location support that enables APs to pinpint the location of=20
> associated=20
> stations.  At least one RADIUS server implementation now supports=20
> "location-based access control".  Why can't the RADIUS-GEOPRIV=20
> specification be used to send user as well as NAS location?=20
>=20
> This basic problem with the document was pointed out in=20
> November 2004, but=20
> has still not been fixed in August 2005, 9 months later. =20
>=20
> However, using the "server-driven" approach, the problem would =20
> not be hard to address.  In the "send location" attribute=20
> included by the=20
> server, the server can specify what type of location data it=20
> is looking=20
> for - user or NAS. =20
>=20
> Note that layer 2 standards such as IEEE 802.11k already enable this=20
> distinction.  In IEEE 802.11k a station can ask either for its own=20
> location or the location of the AP. =20
>=20
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sat, 03 Sep 2005 19:43:19 +0000
Content-class: urn:content-classes:message
Subject: AW: [Geopriv] RE: Review of draft-ietf-geopriv-radius-lo-04.txt 
Date: Sat, 3 Sep 2005 21:41:15 +0200
From: "Tschofenig, Hannes" <[email-masked]>
To: "John Schnizlein" <[email-masked]>, "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>

hi john,=20

> The inclusion of the "entity" field reintroduces the problem we had=20
> with the initial draft, which is that no practical mechanism has been=20
> identified through which the NAS would know the location of the host=20
> attempting attachment.

i wonder why you believe that these mechanisms are not available today.
a number of other people have already provided you with references to
existing products.=20
let me add two links that explain how location determination works in a
wlan environment:=20
http://www.tkn.tu-berlin.de/publications/papers/hoene_paper2.pdf=20
http://www.tkn.tu-berlin.de/publications/papers/tkn_04_16_paper3.pdf
(there are certainly more papers about this subject available and i
guess i do not again need to mention 3g networks.)=20

i have a question for you: you are the co-author of rfc 3825. now,
consider the discussions we have in the emergency context (in geopriv &
ecrit) and the idea to provide location information using dhcp to the
end host for inclusion into an emergency call. do you think that there
is a relationship between the location of the dhcp server/dhcp relay and
the location of the end host?

>=20
> Rather than prolong the illusion, it would be better to=20
> eliminate this=20
> field and let the location attribute refer to the location of the NAS.

ciao
hannes

>=20
> John
>=20
> On Aug 30, 2005, at 9:11 AM, Bernard Aboba wrote:
>=20
> >> Are you sure? The Location-Information attribute includes a field
> >> called "Entity", described as follows
> >>
> >>    Entity (8 bits):
> >>      Describes which location this attribute refers to:
> >>      (0) describes the location of the user's client device
> >>      (1) describes the location of the AAA client
> >>
> >> It looks like NAS could use this field to describe which location
> >> it's sending, or send two Location-Information attributes if it
> >> knows both.
> >
> > But the NAS isn't sending location by default.  So how does=20
> the RADIUS
> > server that requires a given kind of location indicate what=20
> it needs?=20
> > Keep
> > in mind that if the RADIUS server REQUIRES location then it=20
> may need to
> > send an Access-Reject.
> >
>=20
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sat, 03 Sep 2005 19:42:39 +0000
Content-class: urn:content-classes:message
Subject: AW: Review of draft-ietf-geopriv-radius-lo-04.txt 
Date: Sat, 3 Sep 2005 21:41:46 +0200
From: "Tschofenig, Hannes" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

hi bernard,=20

> > A simple solution would be that a NAS that knows both the NAS and=20
> > user location always sends both (when sending location information).
> >=20
> > (I don't think we need more fine-grained capability negotiation=20
> > for this.)
>=20
> I agree that this would work and also agree that capability=20
> negotiation is=20
> not needed.  However, I thought that the idea was not to send=20
> any location=20
> data by default.=20

location is not sent by default.=20

the aspect is similar to the civic vs. geospatial discussion. you could
send both, if you have it. sometimes you just don't have civic and
geospatial location information (depending on the deployment).=20

ciao
hannes

>=20
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sat, 03 Sep 2005 19:40:49 +0000
Content-class: urn:content-classes:message
Subject: AW: Review of draft-ietf-geopriv-radius-lo-04.txt
Date: Sat, 3 Sep 2005 21:35:10 +0200
From: "Tschofenig, Hannes" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, "Nelson, David" <[email-masked]>
Cc: <[email-masked]>

hi bernard,=20

thanks for keeping track of the issues at your radext webpage. i had the
impression that we discussed all of these issues already on the radext
and the geopriv mailing list (around march this year).=20

based on the fact that two working groups were involved when working on
this document i wasn't quite aware of how the open issues should be
tackled (mailing list and/or issue tracker), which format is used to
submit or resolve individual issues and how is actually in charge to
add, remove or modify something on the issue tracker.=20
this might actually something to discuss next time whenever two working
groups work on a single document to avoid confusion.=20

ciao
hannes

> > Please post comments to the RADEXT WG in the format defined on the
> > RADEXT WG Issue list:
> >=20
> > http://www.drizzle.com/~aboba/RADEXT/
>=20
> It would also be helpful if the authors of the RADIUS=20
> Location document=20
> would post the resolution of the 13 issues that have already=20
> been filed,=20
> so we can figure out which ones are now closed. =20
>=20
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sat, 03 Sep 2005 19:39:57 +0000
Content-class: urn:content-classes:message
Subject: AW: Review of draft-ietf-geopriv-radius-lo-04.txt 
Date: Sat, 3 Sep 2005 21:38:46 +0200
From: "Tschofenig, Hannes" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

hi pasi,=20

>=20
> Bernard Aboba wrote:
>=20
> > > It looks like NAS could use this field to describe which location
> > > it's sending, or send two Location-Information attributes if it=20
> > > knows both.
> >=20
> > But the NAS isn't sending location by default.  So how does=20
> > the RADIUS server that requires a given kind of location indicate=20
> > what it needs? Keep in mind that if the RADIUS server REQUIRES=20
> > location then it may need to send an Access-Reject.=20
>=20
> A simple solution would be that a NAS that knows both the NAS and=20
> user location always sends both (when sending location information).
that's also possible and the document allows to include both information
elements.=20
in a small network (such as a wlan hotspot) it might not really matter
whether you provide the location of the end host or the nas since it
might be almost the same (depending on the granularity of the location
information). a lot depends on the deployment scenario.=20

>=20
> (I don't think we need more fine-grained capability negotiation=20
> for this.)
i am not sure either.=20

ciao
hannes

>=20
> Best regards,
> Pasi
>=20
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sat, 03 Sep 2005 19:38:33 +0000
Content-class: urn:content-classes:message
Subject: AW: [Geopriv] RE: Review of draft-ietf-geopriv-radius-lo-04.txt 
Date: Sat, 3 Sep 2005 21:37:49 +0200
From: "Tschofenig, Hannes" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

hi bernard,=20

please find a comment below:=20

> > Are you sure? The Location-Information attribute includes a field
> > called "Entity", described as follows
> >=20
> >    Entity (8 bits):
> >      Describes which location this attribute refers to:
> >      (0) describes the location of the user's client device
> >      (1) describes the location of the AAA client
> >=20
> > It looks like NAS could use this field to describe which location
> > it's sending, or send two Location-Information attributes if it=20
> > knows both.
>=20
> But the NAS isn't sending location by default.  So how does=20
> the RADIUS=20
> server that requires a given kind of location indicate what=20
> it needs? Keep=20
> in mind that if the RADIUS server REQUIRES location then it=20
> may need to=20
> send an Access-Reject.=20
we tried to respect the fact that people indicated that there might be a
scenario where the nas does not know the location of the end host. if
this is the case then the nas can only send its own location
information. if it can include the location information of the end host
(in case it is known) then the more precise info is sent.=20

you seem to suggest that we add functionality to allow the radius server
to request what information (end host vs. nas) it would like to see. we
haven't yet heard this requirement and hence we haven't added it.=20

ciao
hannes

>=20
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/geopriv
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sat, 03 Sep 2005 19:37:44 +0000
Content-class: urn:content-classes:message
Subject: AW: Review of draft-ietf-geopriv-radius-lo-04.txt
Date: Sat, 3 Sep 2005 21:36:11 +0200
From: "Tschofenig, Hannes" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>, <[email-masked]>

hi bernard,=20

thanks for summarizing the potential options regarding this particular =
issue.=20

please find my feedback inline:=20

> -----Urspr=FCngliche Nachricht-----
> Von: [email-masked]=20
> [mailto:[email-masked]] Im Auftrag von Bernard Aboba
> Gesendet: Samstag, 27. August 2005 02:43
> An: [email-masked]; [email-masked]
> Betreff: Re: Review of draft-ietf-geopriv-radius-lo-04.txt
>=20
>=20
> In thinking about the problem of capabilities negotiation within the=20
> RADIUS-GEOPRIV document, it is not clear to me that it is=20
> necessary for a=20
> NAS to advertise location support.=20

the problem was the following. the nas might support=20
- civic location
- geospatial location
- both=20
(or nothing)=20

the radius server might also understand either civic, geospatial or =
both.=20
when we tried to mandate civic location as the default that has to be =
understood i was told that this is not possible in all environments. =
geospatial is not possible as a default either.=20

now, the idea was include something in the first exchange from the nas =
to the aaa server to allow the aaa server to determine whether he =
actually understands the format that can be provided by the nas.=20

whether the desire to support this functionality justifies the =
introduction of an avp is subject for discussion.=20
based on the feedback from the current mailing list thread at least you =
do not seem to be in favor of it.=20

>=20
> Instead, the NAS can be set by default not to send location=20
> attributes=20
> unless the server asks for them.  The problem then reduces to how the=20
> server communicates its needs to the NAS.=20
>=20
> There are several cases of interest:=20
>=20
> 1) The RADIUS server REQUIRES the NAS to provide location
> in the Access-Request (e.g. it implements location-based=20
> access control).
> In this case the RADIUS server can send an Access-Reject with an=20
> Error-Cause attribute with a value of "Location Required".

from previous discussions i remember that this was not the best approach =
particularly if many radius server want to obtain location information =
from the nas.=20
=20
> Alternatively if the authentication mechanism (e.g. EAP) supports=20
> Access-Challenges, the RADIUS server can place a "Send=20
> location" attribute in the Challenge.

this was the approach that was suggested to us in previous discussions.=20
sounds good to me.=20

>  On receiving either of these=20
> indications, the NAS includes location attributes in the=20
> Access-Request.=20
> Note that the server's decision is not influenced by whether=20
> the client=20
> has advertised location support, only by the inclusion of location=20
> attributes in the Access-Request.

i guess you would suggest to return an access reject if the the nas is =
unable to understand the returned location information format.=20

>=20
> 2) The RADIUS server does not require location in the Access-Request,
> but would like location attributes to be included in=20
> Accounting packets,=20
> if available.  In this case, the RADIUS server sends an Access-Accept
> including a "Send location" attribute,

sounds good to me.=20

> perhaps specifying=20
> more details on
> how location should be provided (e.g. Accounting-Stop only, interim
> records, civil/geographic, etc.).

this requirement hasn't be presented to me yet.=20

>=20
> Since the RADIUS server does not require location attributes,=20
> a legacy NAS=20
> can ignore the "send location" attribute with no ill effects.=20
>  This is how=20
> legacy NAS implementations behave, and the "Issues and
> Fixes" document indicates that this is in fact the correct behavior.
> If the NAS does understand the "send location" attribute then it will
> send location in the Accounting packets as requested.
>=20
> Am I missing something, or is the problem really this simple?=20
i hope it is simple.=20

ciao
hannes

>=20
>=20
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sat, 03 Sep 2005 11:28:12 +0000
Date: Sat, 3 Sep 2005 04:28:07 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Re: RFC 3576bis Comments

Some additional comments on references.  These documents do not include a 
normative reference to RFC 4001, but probably should:

   [RFC4001]  Daniele, M., Haberman, B., Routhier, S., and J.
              Schoenwaelder, "Textual Conventions for Internet Network
              Addresses", RFC 4001, February 2005.

On Sat, 3 Sep 2005, Bernard Aboba wrote:

> Some comments on draft-ietf-radext-dynauth-client-mib-01.txt. Most of 
> these comments also apply to the dynauth-server-mib document. 
> 
> The initial sections could use some re-organization.  My suggestion is to 
> start the document with Section 2 - Introduction.  Section 1 
> (Requirements) would become Section 1.1, and Terminology would become 
> Section 1.2.
> 
> Section 2 (Introduction) refers to RFC 2619 and 2621.  It should also 
> probably refer to the RFC 2619bis and RFC 2621bis documents. 
> 
> To address some of the terminology confusion, my suggestion is that the 
> Terminology section be rewritten as follows:
> 
> "1.2  Terminology
> 
>    Dynamic Authorization Server (DAS)
> 
>    The component that resides on the NAS which processes the 
>    Disconnect and Change-of-Authorization (CoA) Request packets 
>    [RFC3576] sent by the Dynamic Authorization Client. 
> 
>    Dynamic Authorization Client (DAC)
> 
>    The component which sends Disconnect and CoA-Request packets 
>    to the Dynamic Authorization Server.  While often residing on the 
>    RADIUS server,  it is also possible for this component to
>    be located on a separate host, such as a Rating Engine.  
> 
>    Dynamic Authorization Server Port
> 
>    The UDP port on which the Dynamic Authorization server listens for
>    the Disconnect and CoA requests sent by the Dynamic Authorization
>    Client."
> 
> Section 5
> 
> Rewrite the first paragraph:
> 
> "5.  Overview
> 
>    "Dynamic Authorization Extensions to RADIUS" [RFC3576] defines
>    the operation of Disconnect-Request, Disconnect-ACK, Disconnect-NAK,
>    CoA-Request, CoA-ACK and CoA-NAK packets.  [DYNSERV] defines the
>    Dynamic Authorization Server MIB and the relationship with other
>    MIB modules.  This MIB module for the Dynamic Authorization
>    Client contains the following:"
> 
> 
> Capitalization
> 
> The term "authenticator" is inconsistently capitalized.  
> 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sat, 03 Sep 2005 11:25:21 +0000
Date: Sat, 3 Sep 2005 04:25:05 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Call for review of RFC 2618bis-2621bis

The revised RADIUS MIB documents are now available on the IETF archive:

http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2618bis-00.txt
http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2619bis-00.txt
http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2620bis-00.txt
http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2621bis-00.txt

Please send review comments to the RADEXT mailing list by September 17, 
2005, using the format described on the RADEXT WG Issues list:
http://www.drizzle.com/~aboba/RADEXT/

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sat, 03 Sep 2005 10:33:04 +0000
Date: Sat, 3 Sep 2005 03:32:03 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: RFC 3576bis Comments

Some comments on draft-ietf-radext-dynauth-client-mib-01.txt. Most of 
these comments also apply to the dynauth-server-mib document. 

The initial sections could use some re-organization.  My suggestion is to 
start the document with Section 2 - Introduction.  Section 1 
(Requirements) would become Section 1.1, and Terminology would become 
Section 1.2.

Section 2 (Introduction) refers to RFC 2619 and 2621.  It should also 
probably refer to the RFC 2619bis and RFC 2621bis documents. 

To address some of the terminology confusion, my suggestion is that the 
Terminology section be rewritten as follows:

"1.2  Terminology

   Dynamic Authorization Server (DAS)

   The component that resides on the NAS which processes the 
   Disconnect and Change-of-Authorization (CoA) Request packets 
   [RFC3576] sent by the Dynamic Authorization Client. 

   Dynamic Authorization Client (DAC)

   The component which sends Disconnect and CoA-Request packets 
   to the Dynamic Authorization Server.  While often residing on the 
   RADIUS server,  it is also possible for this component to
   be located on a separate host, such as a Rating Engine.  

   Dynamic Authorization Server Port

   The UDP port on which the Dynamic Authorization server listens for
   the Disconnect and CoA requests sent by the Dynamic Authorization
   Client."

Section 5

Rewrite the first paragraph:

"5.  Overview

   "Dynamic Authorization Extensions to RADIUS" [RFC3576] defines
   the operation of Disconnect-Request, Disconnect-ACK, Disconnect-NAK,
   CoA-Request, CoA-ACK and CoA-NAK packets.  [DYNSERV] defines the
   Dynamic Authorization Server MIB and the relationship with other
   MIB modules.  This MIB module for the Dynamic Authorization
   Client contains the following:"

Capitalization

The term "authenticator" is inconsistently capitalized.  

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 02 Sep 2005 02:32:09 +0000
Date: Thu, 1 Sep 2005 19:31:22 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Issue 127: Diameter Compatibility

Issue 127: Diameter Compatibility
Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: August 29, 2005
Reference: 
Document: DIGEST-04
Comment type: E
Priority: S
Section: Various
Rationale/Explanation of issue:

The Diameter Compatibility section has vanished completely.  Yet the WG 
charter requires that every RADEXT WG document include *some* discussion 
of this issue. 

My recommendation is that a short Section be added along the 
following lines:

"5. Diameter Compatibility

This document defines support for Digest Authentication in RADIUS.  A 
companion document "Diameter Session Initiation Protocol (SIP) 
Application" [I-D.ietf-aaa-diameter-sip-app] defines support 
for Digest Authentication in Diameter, and addresses compatibility issues 
between RADIUS and Diameter."

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Envelope-to: [email-masked]
Delivery-date: Thu, 01 Sep 2005 21:40:23 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Cc: 
Subject: draft-lior-radext-end-to-end-caps-01.txt
Message-Id: <[email-masked]>
Date: Thu,  1 Sep 2005 17:41:27 -0400 (EDT)

  Based on my review of the document, I do not believe it is currently
ready for acceptance as a WG document.

  Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 01 Sep 2005 19:56:13 +0000
Date: Thu, 1 Sep 2005 12:55:54 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Request from GEOPRIV WG

From: Andrew Newton <[email-masked]>
Subject: Re: [Geopriv] Re: Review of draft-ietf-geopriv-radius-lo-04.txt 
Date: Thu, 1 Sep 2005 15:39:14 -0400
To: GEOPRIV WG <[email-masked]>, [email-masked]

All,

I've asked Hannes to open an issue tracker for this document.

If you have a particular issue with this document, please summarize  
it and send it to the list so that he may enter it into the issue  
tracker.  When sending the issues, please send them in separate  
messages using subjects that denote the nature of the issue.

-andy

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Envelope-to: [email-masked]
Delivery-date: Thu, 01 Sep 2005 00:46:30 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Cc: 
Subject: Review of draft-lior-radext-end-to-end-caps-01.txt
Message-Id: <[email-masked]>
Date: Wed, 31 Aug 2005 20:47:03 -0400 (EDT)

Submitter name: Alan DeKok
Submitter email address: [email-masked]
Date first submitted: August 31, 2005
Reference: 
Document: draft-lior-radext-end-to-end-caps-01.txt
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:

In section 1.1, there are multiple references to "the network", and
what "the network" knows or wants.  It would be better (if possible)
to refer to specific entities or devices in the network.  This would
allow the document to define what devices it's talking about, and what
the requirements are for those devices.

The text in Section 2 makes it difficult to determine who has SHOULD
versus MAY versus MUST for the capabilities.  Suggestions are offered
below.

Section 2 paragraph 3 says:
   "A NAS that requires certain capabilities from the
   RADIUS server SHOULD include the End-to-End-Capability attribute
   indicating which capabilities MUST be delivered by the RADIUS server."

  There appears to be a conflict between "SHOULD" and "MUST".  If the
RADIUS server MUST deliver certain capabilities, it MUST know that
it's supposed to do that.  Barring local configuration changes by an
administrator, the only way for it to know it MUST provide
capabilities is for the NAS to inform it.

  I suggest changing the SHOULD to a MUST.

Section 2 paragraph 3 says:

   "the NAS MAY reject subsequent replies from the RADIUS server"

  I'm not sure what this means, as there is no such concept in
RADIUS.  Perhaps "the NAS MAY ignore subsequent replies", or "the NAS
MAY stop talking to the RADIUS server"?  I don't understand the
failure modes here.  It looks like the NAS will just stop talking to
the RADIUS server, with possibly no recourse to another server.OB

  But I don't see why it would be necessary for a NAS to ignore a
RADIUS server.  The NAS may require certain information for some
sessions and not others, in which case it should keep talking to the
RADIUS server.  If the NAS requires certain information for all
sessions, and the RADIUS server doesn't supply it, that would appear
to be a protocol incompatibilty, and the devices will never
communicate.  So text in the draft to deal with this case don't appear
to help implementations or deployments.

Section 2 paragraph 5 says:

   "the RADIUS server MAY
   specifiy which capabilities that it requires from the NAS."

  If the capabilities are required, then I suggest that the MAY be
changed to a MUST

Section 2 paragraph 5 say:

   "If the capabilities are not delivered to the RADIUS
   server, the RADIUS server MAY reject the session."

  If the capabilities are required (as indicated above), then the MAY
above should be changed to a MUST.

The text from Section 2 is awkward, and it's difficult to figure out
who has what MAY, SHOULD, or MUST.  I suggest using the following
table.  It is a 2-dimensional matrix, where the RADIUS server and NAS
can look up their respective values for a capability, and determine
how to proceed with the request.

		            RADIUS Server
		   unsupported  Supported      Required
     unsupported   pass-1	pass-1	       fail
NAS  Supported     pass-1	pass-2	       pass-2
     Required      fail         pass-2         pass-2

  Results: fail   = incompatible capabilities, access is rejected
           pass-1 = backwards compatibily, capability is unused
           pass-2 = both parties implement the capability

Section 2 describes the format for capabilities.  The string of bit
pairs is unusual.  It may be difficult to extend to future
capabilities, and isn't amenable to compact representation.  e.g. "I
support capabilities 5, 100, and 200).  I hesitate to suggest
run-length encoding as a solution, however.

There's an errant "SHALL" in the "String" description at the top of
page 5.  It should probably be a "MUST".

The table on page 6 seems to say that the NASes can't indicate
UNSUPPORTED.  i.e. It says "The NAS MAY indicate SUPPORTED only".  The
MAY's here should be MUST's, i.e. "MUST indicate one of SUPPORTED or
UNSUPPORTED only".

  Similarly, saying "MAY indicate SUPPORTED and REQUIRED" is
imprecise.  I suggest "MUST indicate one of UNSUPPORTED, SUPPORTED, or
REQUIRED".

  Going through the table on page 6 in detail, my comments on the
capabilities are:

 1: this is superfluous.  Implementations signal this by using RADIUS.

 2: this is mostly superfluous.  If the NAS doesn't support
 accounting, it will never send accounting packets, and the RADIUS
 server should figure it out.  There is no use-case shown as to how
 this capability would benefit RADIUS.

 3: I'm not sure what the error conditions are here.  It's nice for a
 NAS to signal to a RADIUS server that it supports tunnel attributes,
 but again no use-case or benefit is shown.  What problem does this
 feature solve?

 4: If a NAS doesn't support Disconnect-Message, it won't ACK or NAK
 the Disconnect-Request, and the server will figure it out.

 5: Same comment as above.

 6: Why would the NAS require chargeable user ID?  Can a RADIUS server
 require CUI?

 7-17, no comments.

  Summary
  -------

  The capabilities exchange may be useful, but I would like to see an
analysis of it's impact on RADIUS exchanges, as discussed on the list.

  i.e. If the NAS requires a capability, it has to advertise it in an
Access-Request packet, so the RADIUS server will see that capability.

  There appears to be no provision in the document for an ACK of a
REQUIRED capability.  I'm not sure how both ends can then agree on
what services are required and offered.

  I would expect that anything other than an explicit ACK of any
REQUIRED capabilities MUST be treated as an Access-Reject.

  If the RADIUS server can send capabilities to the client, then the
use of Access-Challenge would seem to be required.  i.e. Even for
requests containing User-Password, capability exchange and agreement
may require at least one Access-Request/Access-Challenge cycle.  If
the NAS does not support a capability, it will treat the
Access-Challenge as a Reject.  Otherwise, it will have to continue the
capability exchange.

  Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>