Subject: Re: Issue: Vendor Specifc Attribute Values
From: Emile van Bergen <[email-masked]>
To: Alan DeKok <[email-masked]>
Cc: Bernard Aboba <[email-masked]>, "Nelson, David" <[email-masked]>, [email-masked]
Date: Fri, 29 Jul 2005 19:42:39 +0200

Hi,

On Fri, Jul 29, 2005 at 01:38:55PM -0400, Alan DeKok wrote:

> Bernard Aboba <[email-masked]> wrote:
> > I think there is a basic issue with tackling this in the Issues &
> > Fixes document.  Self-allocation of VSVs is a revision of RFC 3575
> > (RADIUS IANA Allocations Policy) and therefore would need to be a
> > standards track document, which the Issues & Fixes document is not.
> 
>   Hmm... good point.
> 
> > RFC 3575 defines that attribute values can be allocated via
> > designated expert, with the exception of Service-Type, which
> > requires IETF Consensus.  All allocations require a specification.
> > The allocation of Service-Type values was tightened because when it
> > was FCFS it had been used (by IEEE 802.11F) to define new RADIUS
> > commands outside the IETF process.
> 
>   I would say that vendor-specific extensions to the protocol are
> explicitely outside of the scope of the protocol, and things like "new
> RADIUS commands" are a misnomer.  The vendor-extensions to RADIUS
> produce a protocol which is like RADIUS, but may not be interoperable
> with standard RADIUS solutions.  Since this will happen no matter what
> we decide, I'd prefer to standardize the way to produce non-standard
> solutions.

Seconded!

>   I don't have strong opinions about where the text goes, so long it
> goes somewhere, so we can avoid future discussions like the recent
> Authorize-Only issues.

Was it so bad? I think it may have been part of the input that made you
come up with the good idea above.

I don't regard a bit of protocol design philosophy now and then as a bad
thing, as long as it doesn't happen too often.

Cheers,

Emile.

-- 
E-Advies - Emile van Bergen           [email-masked]      
tel. +31 (0)70 3906153           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, 29 Jul 2005 17:39:13 +0000
From: "Alan DeKok" <[email-masked]>
To: Bernard Aboba <[email-masked]>
Subject: Re: Issue: Vendor Specifc Attribute Values 
Cc: "Nelson, David" <[email-masked]>, [email-masked]
Date: Fri, 29 Jul 2005 13:38:55 -0400
Message-Id: <[email-masked]>

Bernard Aboba <[email-masked]> wrote:
> I think there is a basic issue with tackling this in the Issues &
> Fixes document.  Self-allocation of VSVs is a revision of RFC 3575
> (RADIUS IANA Allocations Policy) and therefore would need to be a
> standards track document, which the Issues & Fixes document is not.

  Hmm... good point.

> RFC 3575 defines that attribute values can be allocated via
> designated expert, with the exception of Service-Type, which
> requires IETF Consensus.  All allocations require a specification.
> The allocation of Service-Type values was tightened because when it
> was FCFS it had been used (by IEEE 802.11F) to define new RADIUS
> commands outside the IETF process.

  I would say that vendor-specific extensions to the protocol are
explicitely outside of the scope of the protocol, and things like "new
RADIUS commands" are a misnomer.  The vendor-extensions to RADIUS
produce a protocol which is like RADIUS, but may not be interoperable
with standard RADIUS solutions.  Since this will happen no matter what
we decide, I'd prefer to standardize the way to produce non-standard
solutions.

  I don't have strong opinions about where the text goes, so long it
goes somewhere, so we can avoid future discussions like the recent
Authorize-Only 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, 29 Jul 2005 03:17:33 +0000
Date: Thu, 28 Jul 2005 20:16:47 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Alan DeKok <[email-masked]>
cc: "Nelson, David" <[email-masked]>, [email-masked]
Subject: Re: Issue: Vendor Specifc Attribute Values 

I think there is a basic issue with tackling this in the Issues &
Fixes document.  Self-allocation of VSVs is a revision of RFC 3575
(RADIUS IANA Allocations Policy) and therefore would need to be a
standards track document, which the Issues & Fixes document is not.

RFC 3575 defines that attribute values can be allocated via designated expert,
with the exception of Service-Type, which requires IETF Consensus.
All allocations require a specification.  The allocation of
Service-Type values was tightened because when it was FCFS it had been used
(by IEEE 802.11F) to define new RADIUS commands outside the IETF process.

--
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, 28 Jul 2005 18:03:05 +0000
From: "Alan DeKok" <[email-masked]>
To: "Nelson, David" <[email-masked]>
Subject: Re: Attribute Design Guidelines and RADIUS layering (was:[RADIUS FIXES] Authorize Only / RADIUS layering criteria) 
Cc: "Emile van Bergen" <[email-masked]>, [email-masked]
Date: Thu, 28 Jul 2005 14:02:50 -0400
Message-Id: <[email-masked]>

"Nelson, David" <[email-masked]> wrote:
> I would like to reiterate that I think re-definition, over-loading or
> private agreements to modify the semantics of any IETF standard RADIUS
> attribute is harmful to the integrity and multi-vendor interoperability
> of the protocol.

  Let's add that text to the "issues & fixes" draft.

> It *is* important that vendors be able to use VSAs for proprietary
> features that do not have wider applicability.  It is also important
> that vendors, other WGs, or other SDOs be able to create and properly
> document fully interoperable IETF standard attributes, when appropriate.

  Agreed.  Let's re-iteratite again in the draft.

  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, 28 Jul 2005 14:40:51 +0000
Content-class: urn:content-classes:message
Subject: Attribute Design Guidelines and RADIUS layering (was:[RADIUS FIXES] Authorize Only / RADIUS layering criteria)
Date: Thu, 28 Jul 2005 10:40:18 -0400
From: "Nelson, David" <[email-masked]>
To: "Emile van Bergen" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Emile van Bergen writes...

> Some standards violations are much more serious than others. If a
proxy
> does not properly forward certain characters, characters which clients
> and servers are allowed to use according to the standard, then that's
> extremely serious.
>=20
> If a service provider and a proxy operator agree to attach meaning to
an
> attribute that the standard says must not be interpreted, then that
has
> no consequence for any code or anyone else in the chain.

I think this thread has wound it way onto the turf on another WG charter
item, the RADIUS Design Guidelines document.  There are also
implications for RFC 3575 "IANA Considerations for RADIUS".

The problem with a particular vendor and particular customer privately
agreeing to over-load the semantics of a standard RADIUS attribute (or
command, for that matter) is that it becomes a proprietary protocol,
based on a standard one.  I'm sure there are lots of customers that are
perfectly happy to deploy proprietary protocols, and goodness knows that
vendors have reason to be happy about that.

When I use the words "multi-vendor interoperability" I mean that my
implementation of the protocol is fully interchangeable with your
implementation of the protocol, enabling me to respond to an RFP from
your customer base.  When all we have is a base level of "transport"
standardization, but much of the detailed protocol element semantics and
the system level behavior is divergent from one implementation to
another, its only a "vanity" standard, or in fact a collection of
partially interoperable proprietary protocols.

Before you cry foul, and point out that vendors need to be able to
differentiate their products to compete, let me say that I fully agree.
Where my opinion may differ is in where the product differentiation
exists.  If there are complete feature sets, use cases and solutions
that rely on private agreements over the *meaning* of the protocol
elements, then that's my definition of a proprietary protocol.

We've had some discussions in this thread about the RADIUS architecture
and it's lack of separation of "transport", i.e. PDU framing and
formats, from the abstract concept of its service-provisioning service,
and from the interface to other protocols that provide the services
being provisioned.  Back when RADIUS was first developed, its scope of
applicability was fairly narrow -- those services provided by
asynchronous dial-up access servers (terminal servers). I've been
involved since the second RADIUS BOF, so I have first hand knowledge of
much of the history.  It was excusable, I think, for RADIUS to take this
"simplified", non-layered approach based on the problem it was
attempting to solve.

All of the original RADIUS attributes needed very little in the way of
formal definition. They all represented very well-known and
unambiguously defined data objects, protocols and services, understood
by almost anyone with a reasonable exposure to the Internet.  Host
names, IP addresses, Telnet, Rlogin, SLIP, PPP, and such are all well
defined services.  Their inclusion in attributes was pretty much
self-describing.  No one ever thought to re-use the IP-Address attribute
to contain an IPX address (at least to my knowledge).

I would like to reiterate that I think re-definition, over-loading or
private agreements to modify the semantics of any IETF standard RADIUS
attribute is harmful to the integrity and multi-vendor interoperability
of the protocol.  RADIUS can easily be [mis]used as an application
agnostic transport protocol.  Because RADIUS *has* defined the transport
issues so inextricably with the protocol semantics issues, it is not
reasonable to attempt to retrofit RADIUS with that level of "layering"
today, and to turn it into an application agnostic transport, no matter
how convenient that might be for vendors attempting to innovate rapidly
outside of the standards arena.

It *is* important that vendors be able to use VSAs for proprietary
features that do not have wider applicability.  It is also important
that vendors, other WGs, or other SDOs be able to create and properly
document fully interoperable IETF standard attributes, when appropriate.
That is why we have RFC 3575 "IANA Considerations for RADIUS" and why
the RADIUS Design Guidelines document is a RADEXT WG charter item.

--
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, 28 Jul 2005 12:53:32 +0000
Date: Thu, 28 Jul 2005 14:46:43 +0200
From: Emile van Bergen <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [RADIUS FIXES] Authorize Only / RADIUS layering criteria
Mail-Followup-To: [email-masked], [email-masked]

Hi,

On Thu, Jul 28, 2005 at 02:47:41PM +0300, [email-masked] wrote:

> Emile van Bergen wrote
> >
> > Of course, if two parties (eg. a service provider and a
> > roaming broker) contractually agree that the service provider
> > sets class to a particular value in particular cases so that
> > the roaming broker can perform some form of special accounting
> > based on it, then that's a contractual issue between two
> > parties that already need to have a contractual relationship
> > (because they need a shared secret, and the service provider
> > needs to pay the roaming broker, and so on).
> > 
> > But I'd say that that is entirely within the freedom granted
> > by the standard that defines Class.
> 
> I'm not sure it is; RFC 2865 explicitly says that "The client
> MUST NOT interpret the attribute locally."
> 
> Of course, IETF is not a protocol police, and two parties can
> agree to do whatever they want. They could, for instance, agree
> to send User-Name in EBCDIC character set instead of
> ASCII/UTF-8.  But IMHO that would not be RADIUS as specified in
> RFC 2865 anymore.

Ok, agreed.

But if you let go of the concept of all equal clients and all equal
servers for a moment, but see a client undergoing rapid upgrade cycles
(every time new AAA functionality is added, with the exception of EAP),
followed by a chain of very static proxies, followed by servers with
backends of varied complexity and wildly different policies and
applications, then you get a different picture, with varying shades of
gray.

Some standards violations are much more serious than others. If a proxy
does not properly forward certain characters, characters which clients
and servers are allowed to use according to the standard, then that's
extremely serious.

If a service provider and a proxy operator agree to attach meaning to an
attribute that the standard says must not be interpreted, then that has
no consequence for any code or anyone else in the chain.

Cheers,

Emile.

-- 
E-Advies - Emile van Bergen           [email-masked]      
tel. +31 (0)70 3906153           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: Thu, 28 Jul 2005 12:06:16 +0000
content-class: urn:content-classes:message
Subject: RE: RADEXT WG Last Call on draft-ietf-radext-dynauth-client-mib-01.txt
Date: Thu, 28 Jul 2005 15:06:02 +0300
From: "Romascanu, Dan \(Dan\)" <[email-masked]>
To: "Nagi Reddy Jonnala \(njonnala\)" <[email-masked]>, "Bernard Aboba" <[email-masked]>, <[email-masked]>
Cc: "Wijnen, Bert \(Bert\)" <[email-masked]>

Now that you mention it, I think I remember this discussion. In any
case, assuming the warning can be ignored, I believe it's better to
define radiusDynamicAuthorization in one of the documents and IMPORT it
in the other.=20

Regards,

Dan

> -----Original Message-----
> From: Nagi Reddy Jonnala (njonnala) [mailto:[email-masked]]=20
> Sent: Thursday, July 28, 2005 3:00 PM
> To: Romascanu, Dan (Dan); Bernard Aboba; [email-masked]
> Cc: Wijnen, Bert (Bert)
> Subject: RE: RADEXT WG Last Call on=20
> draft-ietf-radext-dynauth-client-mib-01.txt
>=20
> Dan,
>=20
> Thanks for your review. Please see below a bit of history and=20
> answers to your questions.
>=20
> History:
>=20
> Initially when we designed, we wanted to have conceptual=20
> grouping i.e., radiusDynamicAuthorization stemmed from=20
> radiusMIB (radiusMIB stems from from mib-2 and the DAC & DAS=20
> MIBs under this root.=20
>=20
> After first MIB doctor's review:
>=20
> As I understand, MIB doctor suggested to change the MIBs to=20
> directly originate from mib-2(instead from radiusMIB). That's=20
> how radiusDynamicAuthorization took origin from mib-2.
>=20
> I'm not sure how the warning was not noticed. As I mentioned,=20
> the reason to keep like this way is to have a conceptual=20
> grouping. Though DAC & DAS MIBs could be directly orginated=20
> from mib-2 if it is mandatory.
>=20
> regards
> Nagi.
>=20
>=20
>=20
> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]]
> On Behalf Of Romascanu, Dan (Dan)
> Sent: Thursday, July 28, 2005 4:38 PM
> To: Bernard Aboba; [email-masked]
> Cc: Wijnen, Bert (Bert)
> Subject: RE: RADEXT WG Last Call on
> draft-ietf-radext-dynauth-client-mib-01.txt
>=20
> Both draft-ietf-radext-dynauth-client-mib-01.txt and=20
> draft-ietf-radext-dynauth-server-mib-01.txt define=20
> radiusDynamicAuthorization as=20
>=20
> radiusDynamicAuthorization    OBJECT IDENTIFIER ::=3D { mib-2 xxx }=20
>=20
> And then define the respective MODULE-IDENTITY under=20
> radiusDynamicAuthorization.=20
>=20
> Defining the same node in two separate documents seems odd,=20
> although it is IANA who is in charge with the xxx allocation.=20
> Also, this results in smilint protesting with a level 4 warning:
>=20
> Warning:     module-identity-registration (level 4)
> Message:     uncontrolled MODULE-IDENTITY registration
> Description: The identities of IETF MIB modules should be=20
> registered below
>              mib-2, transmission, or snmpModules so that the=20
> registration
>              space can be controlled by IANA.
>=20
> I wonder what are the good reasons to break this 'should'
> recommendation.=20
>=20
> Regards,
>=20
> Dan
>=20
>=20
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Bernard Aboba
> > Sent: Thursday, July 07, 2005 5:02 PM
> > To: [email-masked]
> > Subject: RADEXT WG Last Call on
> > draft-ietf-radext-dynauth-client-mib-01.txt
> >=20
> > This is an announcement of RADEXT WG last call on the "Dynamic=20
> > Authorization Client MIB", prior to sending this document=20
> to the IESG=20
> > for publication as an Informational RFC.
> >  The document will be available on the IETF archive at the following
> > location:
> > http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-
> > client-mib-01.txt
> >=20
> > Until then, it is available for inspection at:
> > http://www.drizzle.com/~aboba/RADEXT/draft-ietf-radext-dynauth
> > -client-mib-01.txt
> >=20
> > RADEXT WG Last Call will last until July 28, 2005.  Please=20
> send your=20
> > comments to the RADEXT WG mailing list
> > ([email-masked]) in the format described in the=20
> RADEXT Issues=20
> > List, located at:
> >=20
> > http://www.drizzle.com/~aboba/RADEXT/
> >=20
> > --
> > to unsubscribe send a message to
> > [email-masked] with the word 'unsubscribe'=20
> in a single
>=20
> > line as the message text body.
> > archive: <http://psg.com/lists/radiusext/>
> >=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, 28 Jul 2005 12:00:19 +0000
Content-class: urn:content-classes:message
Subject: RE: RADEXT WG Last Call on draft-ietf-radext-dynauth-client-mib-01.txt
Date: Thu, 28 Jul 2005 17:29:47 +0530
From: "Nagi Reddy Jonnala \(njonnala\)" <[email-masked]>
To: "Romascanu, Dan \(Dan\)" <[email-masked]>, "Bernard Aboba" <[email-masked]>, <[email-masked]>
Cc: "Wijnen, Bert \(Bert\)" <[email-masked]>

Dan,

Thanks for your review. Please see below a bit of history and answers to
your questions.

History:

Initially when we designed, we wanted to have conceptual grouping i.e.,
radiusDynamicAuthorization stemmed from radiusMIB (radiusMIB stems from
from mib-2 and the DAC & DAS MIBs under this root.=20

After first MIB doctor's review:

As I understand, MIB doctor suggested to change the MIBs to directly
originate from mib-2(instead from radiusMIB). That's how
radiusDynamicAuthorization took origin from mib-2.

I'm not sure how the warning was not noticed. As I mentioned, the reason
to keep like this way is to have a conceptual grouping. Though DAC & DAS
MIBs could be directly orginated from mib-2 if it is mandatory.

regards
Nagi.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Romascanu, Dan (Dan)
Sent: Thursday, July 28, 2005 4:38 PM
To: Bernard Aboba; [email-masked]
Cc: Wijnen, Bert (Bert)
Subject: RE: RADEXT WG Last Call on
draft-ietf-radext-dynauth-client-mib-01.txt

Both draft-ietf-radext-dynauth-client-mib-01.txt and
draft-ietf-radext-dynauth-server-mib-01.txt define
radiusDynamicAuthorization as=20

radiusDynamicAuthorization    OBJECT IDENTIFIER ::=3D { mib-2 xxx }=20

And then define the respective MODULE-IDENTITY under
radiusDynamicAuthorization.=20

Defining the same node in two separate documents seems odd, although it
is IANA who is in charge with the xxx allocation. Also, this results in
smilint protesting with a level 4 warning:

Warning:     module-identity-registration (level 4)
Message:     uncontrolled MODULE-IDENTITY registration
Description: The identities of IETF MIB modules should be registered
below
             mib-2, transmission, or snmpModules so that the
registration
             space can be controlled by IANA.

I wonder what are the good reasons to break this 'should'
recommendation.=20

Regards,

Dan

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Thursday, July 07, 2005 5:02 PM
> To: [email-masked]
> Subject: RADEXT WG Last Call on
> draft-ietf-radext-dynauth-client-mib-01.txt
>=20
> This is an announcement of RADEXT WG last call on the "Dynamic=20
> Authorization Client MIB", prior to sending this document to the IESG=20
> for publication as an Informational RFC.
>  The document will be available on the IETF archive at the following=20
> location:
> http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-
> client-mib-01.txt
>=20
> Until then, it is available for inspection at:
> http://www.drizzle.com/~aboba/RADEXT/draft-ietf-radext-dynauth
> -client-mib-01.txt
>=20
> RADEXT WG Last Call will last until July 28, 2005.  Please send your=20
> comments to the RADEXT WG mailing list
> ([email-masked]) in the format described in the RADEXT Issues=20
> List, located at:
>=20
> http://www.drizzle.com/~aboba/RADEXT/
>=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/>

--
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, 28 Jul 2005 11:47:51 +0000
Content-class: urn:content-classes:message
Subject: RE: [RADIUS FIXES] Authorize Only / RADIUS layering criteria
Date: Thu, 28 Jul 2005 14:47:41 +0300
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Emile van Bergen wrote
>
> Of course, if two parties (eg. a service provider and a
> roaming broker) contractually agree that the service provider
> sets class to a particular value in particular cases so that
> the roaming broker can perform some form of special accounting
> based on it, then that's a contractual issue between two
> parties that already need to have a contractual relationship
> (because they need a shared secret, and the service provider
> needs to pay the roaming broker, and so on).
>=20
> But I'd say that that is entirely within the freedom granted
> by the standard that defines Class.

I'm not sure it is; RFC 2865 explicitly says that "The client
MUST NOT interpret the attribute locally."

Of course, IETF is not a protocol police, and two parties can
agree to do whatever they want. They could, for instance, agree
to send User-Name in EBCDIC character set instead of
ASCII/UTF-8.  But IMHO that would not be RADIUS as specified in
RFC 2865 anymore.

Although that example doesn't really make sense, it's not that
extreme. People are calling all sorts of things "RADIUS" just
because the packet format resembles something in RFC 2865.

Here an explicit layering model, saying that "these things are
part of the RADIUS transport layer" and "these other things you
must define in a RADIUS application layer" would help. (And most
of the attributes would probably belong in the "application
layer".)

Unfortunately, RFC 2865 mixes both the transport parts and
"network access authentication" application parts in the same
document, creating endless confusion when people would like to
use RADIUS transport parts for something like "PE-Based VPN
Discovery" (honest, I'm not making this up :-)

I'm not saying there's nothing wrong in using RADIUS for VPN
discovery; just that it would IMHO be more accurate to say that
they've developed a new protocol for VPN discovery that just
happens to run over RADIUS transport. After all, if they had
decided to use SOAP-over-HTTP for transport instead, we probably
wouldn't call the document "Using HTTP for PE-based VPN
Discovery" or "Using SOAP for PE-based VPN discovery", but
something like "PE-based VPN discovery protocol".

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, 28 Jul 2005 11:22:02 +0000
Date: Thu, 28 Jul 2005 13:15:35 +0200
From: Emile van Bergen <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [RADIUS FIXES] Authorize Only / RADIUS layering criteria
Mail-Followup-To: [email-masked], [email-masked]

Hi,

On Thu, Jul 28, 2005 at 01:50:32PM +0300, [email-masked] wrote:

> Emile van Bergen wrote:
> > 
> > Let's take the example of Class for simplicity, supposing for a
> > moment that it isn't already defined. The generic opaque
> > attribute that SHOULD be echoed by the NAS would be defined by
> > a RADIUS extension RFC, and be available for use in any
> > application that requires an attribute with those external
> > semantics. The upgrade from SHOULD to MUST would require an
> > upgrade to the core RADIUS RFC.
> > 
> > The RADIUS extension RFC defining Class could suggest its use
> > as a billing item reference or similar uses. However, it should
> > not enumerate or limit future applications, or put constraints
> > on its value, when not required for its basic definition ('an
> > attribute whose contents are copied from access accept to
> > subsequent accounting request').
> 
> I disagree about this, to some degree at least. If we have two
> different "applications" that use an attribute for two quite
> distinct purposes, IMHO they should define two separate
> attributes.
> 
> The current approach of reusing the same attribute number for
> different purposes is there basically only because getting a new
> attribute number has been difficult (and using a "vendor-specific" 
> number has a stigma attached to it, although many attributes with 
> "vendor-specific" numbers are not really specific to any vendor 
> but instead widely used...)

True. So you see in practice that RADIUS can very well be extended
on a level just above the core protocol. If VSAs have a stigma, then
perhaps my earlier suggestion of creating a VSA space with IETF as the
vendor may be a solution. EAP also has this in its EAP-Type space.

> Class is actually a good example here: It is defined as an
> attribute that MUST NOT be interpreted by the client (implying
> that the server can put anything it wants there). But people are
> anyway using it to carry things that the client _does_ somehow
> interprete (e.g., some semi-permanent identifier for the
> subscriber in roaming cases). Thus, the server can't anymore
> follow the original "put whatever I want there"; the contents 
> has to be in line with what the client's expectations. 
> 
> (And in this case, there is progress towards defining a separate
> attribute, Chargeable-User-Identity...)

Agreed, and in this case CUI is the proper solution, and the whole issue
of clients misusing the Class should not affect the definition of Class
from a standards perspective. Server vendors or service providers should
not feel limited in their choice of what to set Class to.

Of course, if two parties (eg. a service provider and a roaming broker)
contractually agree that the service provider sets class to a particular
value in particular cases so that the roaming broker can perform some
form of special accounting based on it, then that's a contractual issue
between two parties that already need to have a contractual relationship
(because they need a shared secret, and the service provider needs to
pay the roaming broker, and so on). 

But I'd say that that is entirely within the freedom granted by the
standard that defines Class.

Cheers,

Emile.

-- 
E-Advies - Emile van Bergen           [email-masked]      
tel. +31 (0)70 3906153           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: Thu, 28 Jul 2005 11:09:05 +0000
content-class: urn:content-classes:message
Subject: RE: RADEXT WG Last Call on draft-ietf-radext-dynauth-client-mib-01.txt
Date: Thu, 28 Jul 2005 14:07:35 +0300
From: "Romascanu, Dan \(Dan\)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>
Cc: "Wijnen, Bert \(Bert\)" <[email-masked]>

Both draft-ietf-radext-dynauth-client-mib-01.txt and
draft-ietf-radext-dynauth-server-mib-01.txt define
radiusDynamicAuthorization as=20

radiusDynamicAuthorization    OBJECT IDENTIFIER ::=3D { mib-2 xxx }=20

And then define the respective MODULE-IDENTITY under
radiusDynamicAuthorization.=20

Defining the same node in two separate documents seems odd, although it
is IANA who is in charge with the xxx allocation. Also, this results in
smilint protesting with a level 4 warning:

Warning:     module-identity-registration (level 4)
Message:     uncontrolled MODULE-IDENTITY registration
Description: The identities of IETF MIB modules should be registered
below
             mib-2, transmission, or snmpModules so that the
registration
             space can be controlled by IANA.

I wonder what are the good reasons to break this 'should'
recommendation.=20

Regards,

Dan

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Thursday, July 07, 2005 5:02 PM
> To: [email-masked]
> Subject: RADEXT WG Last Call on=20
> draft-ietf-radext-dynauth-client-mib-01.txt
>=20
> This is an announcement of RADEXT WG last call on the=20
> "Dynamic Authorization Client MIB", prior to sending this=20
> document to the IESG for publication as an Informational RFC.=20
>  The document will be available on the IETF archive at the=20
> following location:
> http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-
> client-mib-01.txt
>=20
> Until then, it is available for inspection at:
> http://www.drizzle.com/~aboba/RADEXT/draft-ietf-radext-dynauth
> -client-mib-01.txt
>=20
> RADEXT WG Last Call will last until July 28, 2005.  Please=20
> send your comments to the RADEXT WG mailing list=20
> ([email-masked]) in the format described in the=20
> RADEXT Issues List, located at:
>=20
> http://www.drizzle.com/~aboba/RADEXT/
>=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, 28 Jul 2005 11:03:59 +0000
Date: Thu, 28 Jul 2005 12:57:29 +0200
From: Emile van Bergen <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: [RADIUS FIXES] Authorize Only / RADIUS layering
Mail-Followup-To: [email-masked], [email-masked], [email-masked]

Hi,

On Thu, Jul 28, 2005 at 11:38:37AM +0300, [email-masked] wrote:

> David Nelson wrote:
> > 
> > So, let me take a moment to address RADIUS layering in a
> > pro-active fashion.
> > 
> > It is certainly appropriate to have layering of one
> > application upon the services provided by another.  We need to
> > address this general architectural concept within the
> > constraints of RADIUS as it exists, and the charter of the
> > RADEXT WG.
> > 
> > RADEXT is not chartered to make major or substantial
> > architectural changes to RADIUS.  For example, introducing
> > layering akin to the base / application layering in Diameter
> > is certainly out of scope.
> > 
> > It would, generally speaking, be appropriate for RADEXT to
> > consider standardization of new attributes for the
> > provisioning of existing, well-defined services that exist on
> > the NAS.  Traditionally, these attributes have used the data
> > types defined in RFC 2865 and have been transparent to the
> > RADIUS protocol engines, in both clients and servers.  The
> > vast majority of existing RADIUS attributes is acted upon by
> > application layer software outside the scope of the RADIUS
> > protocol engine, and its associated support and management
> > components. So layering does already exist, to this extent.
> 
> This is an interesting and pretty accurate observation. Current
> RADIUS documents are mostly concerned with how attributes are
> transported from one place to another (and how multiple
> attribute packed to a single message are separated). How the
> attributes are acted upon (what they mean, or what their
> semantics are) is largely unspecified in IETF RADIUS documents.

And I would say that that is a good thing. I'm not saying that the lack
of standardization of the application layer is a good thing, but I don't
think that each application should be standardized in IETF RADIUS
protocol documents.

> > The specific practice that I'm suggesting is undesirable is
> > the definition of new RADIUS attributes, and their basic
> > semantic descriptions, in RFCs defining the applications,
> > rather than in [companion] RADIUS extensions RFCs.  That does
> > not mean that the I-Ds for such RADIUS extensions need to be
> > work items for the RADEXT WG.  They could be work items for
> > other IETF WGs (or conceptually even other SDOs), with
> > concurrent review and WG Last Calls in RADEXT and the other
> > WG(s).  In any event, the collection of IETF standard
> > attributes (anything other than VSAs) should be treated as a
> > consistent body of work, and be considered as elements of the
> > RADIUS protocol.
> > 
> > RADIUS does not have a formal language that would allow the
> > independent publication of data objects, much as we have MIBs
> > for SNMP and PIBs for COPS.
> 
> This is where I disagree to some extent. I think the current
> practice of defining only the syntax of RADIUS attributes, but
> not the semantics, is very undesirable. One possible way to
> avoid this is to define the syntax and the semantics in the 
> same document...

Generally, if the functioning of a lower layer does not depend on the
functioning of an upper layer (eg. IP can work without TCP being
implemented), then the upper layer should not be documented in the lower
layer's standard, other than as an example.

I think that that this also often goes for the separation of syntax of
an attribute (32-bit unsigned, optional in access accepts), and the
semantics of each possible value.

> And IMHO we don't need a formal language, since all it could
> do is describing the syntactic parts (e.g., this attribute can
> be included only in Access-Accept messages, and contains a
> 32-bit integer). I don't currently see big problems in this 
> area; the problem is that documentation doesn't describe
> how the attributes are acted upon.

If an attribute is and will only useful in one situation, I would not
object to adding more detail about the attribute's possible contents in
the document that defines the attribute's existence.

However, if the attribute and the rules governing its existence are
useful in other situations as well, then I would strongly suggest to
leave any constraints on contents to application level documents.

> If we are concerned with interoperability of whole RADIUS
> clients and servers, rather than just "RADIUS protocol engines",
> the endpoints need to agree on those semantics, too. Currently
> that is pretty much left to implementation folklore (in the
> worst case) or documents by other SDOs (in the best case).
> 
> I think Avi's example of using "Authorize Only" for replenishing
> prepaid quota is a good example of this. The syntax of the
> attributes is defined in IETF specs, but actual interoperability
> requires some agreement of how the messages are acted upon that
> not's specified in any IETF document. (I'm not sure if it's
> specified in any document, in fact...)

I have often implemented prepaid schemes using only existing RADIUS
attributes (Session-Timeout, Acct-Session-Time, Acct-Terminate-Cause,
Idle-Timeout). This implementation requires only bog standard behaviour
from NASes, proxies, and the protocol engine on the server; only some
custom logic and database is required on top of the server. (And in
OpenRADIUS, that custom logic is purely a run time issue, not a code
thing).

Because prepaid is often an unilateral process as far as data on the
wire is concerned (it only affects logic and state at the service
provider), it may not even require IETF standardization. It's just an
issue of completeness, robustness and price between the logic/database
vendor and the service provider.

But because there are quite a number of subtleties involved in the use
of those standard attributes for this purpose, it would perhaps be a
good candidate for an informational application level RFC showing best
practice in the use of RADIUS and certain existing RADIUS attributes to
build a prepaid service.

And to address Authorize-Only: if replenishing of quota during a session
must be able extend the end of a session without any interruption of
service, then the required NAS behaviour and server logic at
reauthentication time can still be detailed in an application level
document, especially because the issue of fast reauthentications can
very well be solved above the RADIUS protocol level.

(A NAS can eg. perform reauthentication 5 seconds before the end of
the session, and/or use more lightweight credentials that securely refer
to the earlier authentication, and so on. See eg. TLS, and the EAP types
that use it in some way).

If Authorize-Only would be the only available flag to trigger the
applicable logic above the RADIUS protocol level, ie. the EAP type has
no way to determine whether an authentication is actually about an
existing session for caching purposes, then perhaps Authorize-Only is
needed. Otherwise, I see no point in it, and I'm a bit nervous about a
RADIUS server returning a users' authorization profile in response to a
request that does not contain that full redentials (or at least a secure
reference to an earlier authentication).

Let's keep in mind that an 'authentication' in RADIUS speak is only a
simple request/response transaction. A database lookup through a bit of
logic. If a lightweight subsequent RADIUS 'authentication' is done to
verify whether an existing session that's about to end may be continued,
then at the protocol level, that's a normal RADIUS authentication. Only
the database and an EAP type need be concerned. And those are
application level issues as far as I'm concerned.

RADIUS per se has no concept of sessions, only of authentications with
authorizations as responses. That the logic behind RADIUS may keep
session state by combining authentications with accounting or earlier
authentications in lots of funky ways is not a RADIUS issue, but a
RADIUS application issue.

Session state is not required in the core of a RADIUS server now, and it
should not be required later.

Cheers,

Emile.

-- 
E-Advies - Emile van Bergen           [email-masked]      
tel. +31 (0)70 3906153           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: Thu, 28 Jul 2005 10:50:48 +0000
Content-class: urn:content-classes:message
Subject: RE: [RADIUS FIXES] Authorize Only / RADIUS layering criteria
Date: Thu, 28 Jul 2005 13:50:32 +0300
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Emile van Bergen wrote:
>=20
> Let's take the example of Class for simplicity, supposing for a
> moment that it isn't already defined. The generic opaque
> attribute that SHOULD be echoed by the NAS would be defined by
> a RADIUS extension RFC, and be available for use in any
> application that requires an attribute with those external
> semantics. The upgrade from SHOULD to MUST would require an
> upgrade to the core RADIUS RFC.
>=20
> The RADIUS extension RFC defining Class could suggest its use
> as a billing item reference or similar uses. However, it should
> not enumerate or limit future applications, or put constraints
> on its value, when not required for its basic definition ('an
> attribute whose contents are copied from access accept to
> subsequent accounting request').

I disagree about this, to some degree at least. If we have two
different "applications" that use an attribute for two quite
distinct purposes, IMHO they should define two separate
attributes.

The current approach of reusing the same attribute number for
different purposes is there basically only because getting a new
attribute number has been difficult (and using a "vendor-specific"=20
number has a stigma attached to it, although many attributes with=20
"vendor-specific" numbers are not really specific to any vendor=20
but instead widely used...)

Class is actually a good example here: It is defined as an
attribute that MUST NOT be interpreted by the client (implying
that the server can put anything it wants there). But people are
anyway using it to carry things that the client _does_ somehow
interprete (e.g., some semi-permanent identifier for the
subscriber in roaming cases). Thus, the server can't anymore
follow the original "put whatever I want there"; the contents=20
has to be in line with what the client's expectations.=20

(And in this case, there is progress towards defining a separate
attribute, Chargeable-User-Identity...)

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, 28 Jul 2005 10:04:42 +0000
Date: Thu, 28 Jul 2005 11:57:57 +0200
From: Emile van Bergen <[email-masked]>
To: [email-masked]
Cc: Alan DeKok <[email-masked]>, "Nelson, David" <[email-masked]>
Subject: Re: [RADIUS FIXES] Authorize Only / RADIUS layering criteria
Mail-Followup-To: [email-masked], Alan DeKok <[email-masked]>, "Nelson, David" <[email-masked]>

Hi,

On Wed, Jul 27, 2005 at 04:19:23PM -0400, Alan DeKok wrote:

> "Nelson, David" <[email-masked]> wrote:
> > The specific practice that I'm suggesting is undesirable is the
> > definition of new RADIUS attributes, and their basic semantic
> > descriptions, in RFCs defining the applications, rather than in
> > [companion] RADIUS extensions RFCs.  That does not mean that the I-Ds
> > for such RADIUS extensions need to be work items for the RADEXT WG.
> 
>   That makes sense.
> 
>   To address Emile's view, let's take PEAP as an example.  The RADIUS
> server gets these layers:
> 
>   ethernet
>   IPv4
>   UDP
>   RADIUS
>   EAP
>   EAP-PEAP
>   TLS'
>   EAP'
>   EAP-MSCHAPv2
> 
>   Those layers don't map 1-1 to the OSI 7 layer stack.  I think what
> Emile is saying is is that if you pick a layer, everything "below" you
> is transport, and everything "above" you is application.

Exactly. Well said. 

I also agree with David above to some extent, but would suggest the
following criteria on that.

Let's take the example of Class for simplicity, supposing for a moment
that it isn't already defined. The generic opaque attribute that SHOULD
be echoed by the NAS would be defined by a RADIUS extension RFC, and be
available for use in any application that requires an attribute with
those external semantics. The upgrade from SHOULD to MUST would
require an upgrade to the core RADIUS RFC.

The RADIUS extension RFC defining Class could suggest its use as a
billing item reference or similar uses. However, it should not enumerate
or limit future applications, or put constraints on its value, when not
required for its basic definition ('an attribute whose contents are
copied from access accept to subsequent accounting request').

If our 'new' Class attribute can be defined without reference to or
(partial) implementation of the applications that use it, or without
mentioning application specific constraints on its value (eg. must be a
valid domain name, or in UTF-8, or whatnot) that are not required for
the NAS to perform the essential task of echoing the value from access
accepts in accounting requests, no such reference or constraint should
be given in the definition of Class in our fictional RADIUS extension
RFC.

However, the use of Class to implement secure roaming to non-trusted
upstream providers would be subject of an application level RFC for
secure roaming, including the requirement that a cryptographically
strong RNG must be used to generate part of its contents, and so on.

I do agree with David that it would be a shame if both the body defining
secure roaming and the body thinking about billing items would each
reinvent some form of Class. I agree that our hypothetical Class should
be defined as a RADIUS extension and not on the application level,
especially if its semantics are likely to have more than one application
(even disregarding for a moment the fact that it requires a change at
the NAS at the code level for most NASes).

However, I think that if an application standardized by the IETF needs a
new non-vendor specific attribute number, but the attribute doesn't
require any special handling by clients, proxies or servers, no RADIUS
standards work should be required. 

A good example would be Acct-Input-Gigawords. It's external semantics
(when and where it's sent) is identical to Acct-Input-Octets and it does
not change anything that already exists.

A good counterexample would be Message-Authenticator; the implementation
of that needs code changes to the core of a RADIUS server and client,
because you need access to the whole packet to calculate or verify the
signature contained in it. Others would be User-Password and
Tunnel-Password because they need decrypting and re-encrypting at each
proxy.

To address the MIB etc. point made elsewhere in this discussion: I do
think that the number space is orthogonal to standardization. If you do
standards work for a new application that already requires a specific
type of endpoint and the application does not affect the proxies in any
way, you should be allowed to request a number for a new attribute from
the main attribute space via IANA, without full fledged RADIUS standards
work. This is also very well laid down in RFC 2865 section 6.2.

If the allocation of new attributes from the non-VSA space without
RADIUS standards work would go against current IETF policy, then I'd
rather see a new VSA space with IETF as the vendor and the IANA as the
entity governing the number space to hold such simple new attributes,
than a fully fledged process to update RADIUS each time a new RADIUS
application is standardized by the IETF.

But as said, and I think I agree with David here: as soon as an
application requires new attributes that may have wider use, or
attributes with special external semantics that may be useful for other
applications as well, they should be defined in a RADIUS extension RFC
(but as generically as possible!), not solely in a RADIUS application
RFC, so as to protect RADIUS applications from reinventing their wheels
as much as possible.

Cheers,

Emile.

-- 
E-Advies - Emile van Bergen           [email-masked]      
tel. +31 (0)70 3906153           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: Thu, 28 Jul 2005 08:39:05 +0000
Content-class: urn:content-classes:message
Subject: RE: [RADIUS FIXES] Authorize Only / RADIUS layering
Date: Thu, 28 Jul 2005 11:38:37 +0300
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>

David Nelson wrote:
>=20
> So, let me take a moment to address RADIUS layering in a
> pro-active fashion.
>=20
> It is certainly appropriate to have layering of one
> application upon the services provided by another.  We need to
> address this general architectural concept within the
> constraints of RADIUS as it exists, and the charter of the
> RADEXT WG.
>=20
> RADEXT is not chartered to make major or substantial
> architectural changes to RADIUS.  For example, introducing
> layering akin to the base / application layering in Diameter
> is certainly out of scope.
>=20
> It would, generally speaking, be appropriate for RADEXT to
> consider standardization of new attributes for the
> provisioning of existing, well-defined services that exist on
> the NAS.  Traditionally, these attributes have used the data
> types defined in RFC 2865 and have been transparent to the
> RADIUS protocol engines, in both clients and servers.  The
> vast majority of existing RADIUS attributes is acted upon by
> application layer software outside the scope of the RADIUS
> protocol engine, and its associated support and management
> components. So layering does already exist, to this extent.

This is an interesting and pretty accurate observation. Current
RADIUS documents are mostly concerned with how attributes are
transported from one place to another (and how multiple
attribute packed to a single message are separated). How the
attributes are acted upon (what they mean, or what their
semantics are) is largely unspecified in IETF RADIUS documents.

> The specific practice that I'm suggesting is undesirable is
> the definition of new RADIUS attributes, and their basic
> semantic descriptions, in RFCs defining the applications,
> rather than in [companion] RADIUS extensions RFCs.  That does
> not mean that the I-Ds for such RADIUS extensions need to be
> work items for the RADEXT WG.  They could be work items for
> other IETF WGs (or conceptually even other SDOs), with
> concurrent review and WG Last Calls in RADEXT and the other
> WG(s).  In any event, the collection of IETF standard
> attributes (anything other than VSAs) should be treated as a
> consistent body of work, and be considered as elements of the
> RADIUS protocol.
>=20
> RADIUS does not have a formal language that would allow the
> independent publication of data objects, much as we have MIBs
> for SNMP and PIBs for COPS.

This is where I disagree to some extent. I think the current
practice of defining only the syntax of RADIUS attributes, but
not the semantics, is very undesirable. One possible way to
avoid this is to define the syntax and the semantics in the=20
same document...

And IMHO we don't need a formal language, since all it could
do is describing the syntactic parts (e.g., this attribute can
be included only in Access-Accept messages, and contains a
32-bit integer). I don't currently see big problems in this=20
area; the problem is that documentation doesn't describe
how the attributes are acted upon.

If we are concerned with interoperability of whole RADIUS
clients and servers, rather than just "RADIUS protocol engines",
the endpoints need to agree on those semantics, too. Currently
that is pretty much left to implementation folklore (in the
worst case) or documents by other SDOs (in the best case).

I think Avi's example of using "Authorize Only" for replenishing
prepaid quota is a good example of this. The syntax of the
attributes is defined in IETF specs, but actual interoperability
requires some agreement of how the messages are acted upon that
not's specified in any IETF document. (I'm not sure if it's
specified in any document, in fact...)

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: Wed, 27 Jul 2005 20:53:02 +0000
Content-class: urn:content-classes:message
Subject: RE: [RADIUS FIXES] Authorize Only / RADIUS layering 
Date: Wed, 27 Jul 2005 16:52:43 -0400
From: "Nelson, David" <[email-masked]>
To: "Alan DeKok" <[email-masked]>
Cc: "Emile van Bergen" <[email-masked]>, <[email-masked]>

Alan DeKok writes...
=20
>   To address Emile's view, let's take PEAP as an example.  The RADIUS
> server gets these layers:
>=20
>   ethernet
>   IPv4
>   UDP
>   RADIUS
>   EAP
>   EAP-PEAP
>   TLS'
>   EAP'
>   EAP-MSCHAPv2
>=20
>   Those layers don't map 1-1 to the OSI 7 layer stack.  I think what
> Emile is saying is is that if you pick a layer, everything "below" you
> is transport, and everything "above" you is application.

Yes, I understand.  Except that in your diagram "above" is toward the
bottom of the list.  :-)  :-)

EAP-Message is one example where RADIUS truly acts as a
transport-application, in this case for EAP.  I think the question is
whether there are any other applications that should qualify for this
treatment?=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: Wed, 27 Jul 2005 20:19:33 +0000
From: "Alan DeKok" <[email-masked]>
To: "Nelson, David" <[email-masked]>
Subject: Re: [RADIUS FIXES] Authorize Only / RADIUS layering 
Cc: "Emile van Bergen" <[email-masked]>, [email-masked]
Date: Wed, 27 Jul 2005 16:19:23 -0400
Message-Id: <[email-masked]>

"Nelson, David" <[email-masked]> wrote:
> The specific practice that I'm suggesting is undesirable is the
> definition of new RADIUS attributes, and their basic semantic
> descriptions, in RFCs defining the applications, rather than in
> [companion] RADIUS extensions RFCs.  That does not mean that the I-Ds
> for such RADIUS extensions need to be work items for the RADEXT WG.

  That makes sense.

  To address Emile's view, let's take PEAP as an example.  The RADIUS
server gets these layers:

  ethernet
  IPv4
  UDP
  RADIUS
  EAP
  EAP-PEAP
  TLS'
  EAP'
  EAP-MSCHAPv2

  Those layers don't map 1-1 to the OSI 7 layer stack.  I think what
Emile is saying is is that if you pick a layer, everything "below" you
is transport, and everything "above" you is application.

  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: Wed, 27 Jul 2005 17:56:34 +0000
Content-class: urn:content-classes:message
Subject: RE: [RADIUS FIXES] Authorize Only / RADIUS layering
Date: Wed, 27 Jul 2005 13:55:14 -0400
From: "Nelson, David" <[email-masked]>
To: "Emile van Bergen" <[email-masked]>, <[email-masked]>

So, let me take a moment to address RADIUS layering in a pro-active
fashion.

It is certainly appropriate to have layering of one application upon the
services provided by another.  We need to address this general
architectural concept within the constraints of RADIUS as it exists, and
the charter of the RADEXT WG.

RADEXT is not chartered to make major or substantial architectural
changes to RADIUS.  For example, introducing layering akin to the base /
application layering in Diameter is certainly out of scope.

It would, generally speaking, be appropriate for RADEXT to consider
standardization of new attributes for the provisioning of existing,
well-defined services that exist on the NAS.  Traditionally, these
attributes have used the data types defined in RFC 2865 and have been
transparent to the RADIUS protocol engines, in both clients and servers.
The vast majority of existing RADIUS attributes is acted upon by
application layer software outside the scope of the RADIUS protocol
engine, and its associated support and management components. So
layering does already exist, to this extent.

The specific practice that I'm suggesting is undesirable is the
definition of new RADIUS attributes, and their basic semantic
descriptions, in RFCs defining the applications, rather than in
[companion] RADIUS extensions RFCs.  That does not mean that the I-Ds
for such RADIUS extensions need to be work items for the RADEXT WG.
They could be work items for other IETF WGs (or conceptually even other
SDOs), with concurrent review and WG Last Calls in RADEXT and the other
WG(s).   In any event, the collection of IETF standard attributes
(anything other than VSAs) should be treated as a consistent body of
work, and be considered as elements of the RADIUS protocol.

RADIUS does not have a formal language that would allow the independent
publication of data objects, much as we have MIBs for SNMP and PIBs for
COPS.

--
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, 27 Jul 2005 17:24:15 +0000
Content-class: urn:content-classes:message
Subject: RE: [RADIUS FIXES] Authorize Only / RADIUS layering
Date: Wed, 27 Jul 2005 13:23:36 -0400
From: "Nelson, David" <[email-masked]>
To: "Emile van Bergen" <[email-masked]>, <[email-masked]>

Emile van Bergen writes...

> > The problem I see with the use of RADIUS as a transport mechanism
for
> > other applications is that it leads to poor multi-vendor
> > interoperability.
>=20
> Why? That depends entirely on how well those other applications are
> standardized.
>=20
> The fact that TCP doesn't talk about web browsing isn't the cause of
> browser vendor incompatibilities.

I suppose that's an apt analogy if you consider RADIUS to *be* a
transport layer protocol.  I have always considered it to be an
application layer protocol.

--
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, 27 Jul 2005 15:51:09 +0000
Date: Wed, 27 Jul 2005 17:44:40 +0200
From: Emile van Bergen <[email-masked]>
To: [email-masked]
Cc: "Nelson, David" <[email-masked]>
Subject: Re: [RADIUS FIXES] Authorize Only / RADIUS layering
Mail-Followup-To: [email-masked], "Nelson, David" <[email-masked]>

Hi,

On Wed, Jul 27, 2005 at 10:21:26AM -0400, Nelson, David wrote:

> 
> Emile van Bergen writes...
> 
> > The way I have come to think about RADIUS is that an Access-Request /
> > Access-Response transaction is just a way for a client to ask a
> > questions to server that it trusts.
> > 
> > The question may actually be 'verify identity and return profile X',
> the
> > question may be 'return profile X', the question may be 'proceed with
> > another step in a lengthy EAP discussion'; but in all cases the
> meaning
> > of such a question may only be obvious to a particularly configured
> > instance of a RADIUS server, playing a role in a particular
> application.
> > 
> > To put it differently: I think that it helps to distinguish two layers
> > in RADIUS, with RFC2865 at the bottom, and an *user defined*
> application
> > at the top.
> 
> I think that your suggestion for layering RADIUS and related
> applications sounds appealing, but has some serious drawbacks.  Diameter
> was designed to have a base protocol and a suite of Diameter
> applications.  RADIUS has no such provisions.  There seems to be some
> confusion in the Diameter community as to the guidelines for extending
> Diameter applications, so even in that case the problem may not be fully
> specified.

Exactly. It lacks much of the clarity and simplicity of RADIUS.

> RADIUS was originally conceived as a "service description language" and
> a "service provisioning service".  

Perhaps, I wasn't there when it happened, but if you consider the fact
that the base RFC only specifies the PDU and the basic request/response
transactions, certainly not the way you define services, only the way in
which you convey certain sorts of data with certain required semantics
and suggested usage to a certain device, I personally feel it was more
conceived as a simple way to remove a database from a network device for
authentication and service definition purposes.

It doesn't really deal with provisioning in my view; there's no request
you can send to a RADIUS server to tell it to create user X.

> RADIUS Servers were "smart" and
> RADIUS Clients were "dumb".  Over time, some folks have come to think of
> RADIUS as a convenient transport for all sorts of applications.  I think
> this leads to problems.  If we're looking for a generic application
> transport, perhaps BEEP might be a more appropriate choice.

Perhaps, unless RADIUS fits the bill as it is. Don't forget how /simple/
the original RADIUS protocol is. The only cruft over a simple TLA
transport is the bad home grown MAC scheme, but that's been fixed since
Message-Authenticator.

(Not that that solves all its security problems, but then I think it was
never intended to provide RADIUS as a general service to the world.  It
makes no sense to allow the world to query your user databases. It's
always either your own devices or proxies of parties you have a
(contractual) relationship with. The very least you need is a shared
secret).

> > So if in a particular scheme a NAS has a question to ask that happens
> to
> > pertain to an existing session, that is between the NAS and the EAP
> type
> > or other backend logic to figure out, and should not have an influence
> > on the RADIUS protocol.
> 
> The problem I see with the use of RADIUS as a transport mechanism for
> other applications is that it leads to poor multi-vendor
> interoperability.  

Why? That depends entirely on how well those other applications are
standardized.

The fact that TCP doesn't talk about web browsing isn't the cause of
browser vendor incompatibilities.

> I understand that individual vendors or consortia
> might not be so concerned with interoperability for a specialized
> application, but the IETF is concerned.  If we continue to add opaque
> "blobs" of data in RADIUS attributes, and rely on non-RADIUS
> documentation to define the semantics of that data, I think we run the
> risk of fragmenting RADIUS into several distinct dialects.  IMHO, this
> would be a Bad Thing (tm).

I agree with your last sentence. But opaque blobs are not a problem, if
the semantics of when they are sent and when they are required are well
defined.

See for example Class; conceived to have a 1:1 relationship with a
certain billing article, but what was standardised was the attribute's
semantics on the NAS' side: the fact that the NAS SHOULD echo it in its
accounting (too bad 2866 didn't make it a MUST, but that's another
matter).  This property allows the logic behind a RADIUS server to tie
accounting to authentication in whatever way required by the service
provider.

And this freedom has no adverse effect whatsoever on interoperability;
as far as the contents of the attribute go, the service provider is
talking to himself, not to anyone else. The proxies forward, the NASes
echo, and that's it.

> > Sorry for the long rant, but I see an explosion of complexity here in
> > the last months, without the clear layering that would keep RADIUS the
> > simple, elegant protocol it's always been.
> 
> I happen to personally agree that there is a lot of complexity in some
> of the current and recent proposals to extend RADIUS.  I also believe
> that some of the complexity is desired but not needed.  By that, I mean
> that the problem could be solved in a simpler way without much loss of
> generality.  

I have personally never seen a form of complexity that's desired but not
needed, unless we're talking about wine instead of software.

I would agree that a slightly more complex base layer may sometimes
produce a more elegant and less complex overall system than a forced
simple base layer would do, but that's a different issue.

If RADIUS needs certain attributes with certain generic semantics that
we don't already have (Cf. CUI, slightly different from Class in that
you talk to the intermediates, not to yourself), then those attributes
and their semantics should be defined, without requiring any particular
application.

> OTOH, I think that simply hiding that complexity "under the rug" of
> another, non-RADIUS, protocol does substantial damage to RADIUS as a
> highly interoperable protocol.  

Generally, yes, but this is also a bit of a blanket statement. We should
not hide complexity, because it will bite you twice as hard elsewhere.
Complexity should be divided and conquered.

> So, yes, by all means, let's attempt to keep the extensions as simple
> as they reasonably can be, but let's not decide to "punt" on the hard
> issue of global interoperability by simply declaring the details as
> out of scope for RADIUS.

Not outside the scope RADIUS-based AAA, but perhaps still out of scope
for RADIUS, unless RADIUS needs to deliver extra basic infrastructure.
'Needs' as in 'whenever it makes the application more elegant and is
demonstrably useful to more than one application'.

I think that the current complexity would definitely benefit from
a better effort at layering.

Cheers,

Emile.

-- 
E-Advies - Emile van Bergen           [email-masked]      
tel. +31 (0)70 3906153           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, 27 Jul 2005 14:22:11 +0000
Content-class: urn:content-classes:message
Subject: RE: [RADIUS FIXES] Authorize Only
Date: Wed, 27 Jul 2005 10:21:26 -0400
From: "Nelson, David" <[email-masked]>
To: "Emile van Bergen" <[email-masked]>, <[email-masked]>

Emile van Bergen writes...

> The way I have come to think about RADIUS is that an Access-Request /
> Access-Response transaction is just a way for a client to ask a
> questions to server that it trusts.
>=20
> The question may actually be 'verify identity and return profile X',
the
> question may be 'return profile X', the question may be 'proceed with
> another step in a lengthy EAP discussion'; but in all cases the
meaning
> of such a question may only be obvious to a particularly configured
> instance of a RADIUS server, playing a role in a particular
application.
>=20
> To put it differently: I think that it helps to distinguish two layers
> in RADIUS, with RFC2865 at the bottom, and an *user defined*
application
> at the top.

I think that your suggestion for layering RADIUS and related
applications sounds appealing, but has some serious drawbacks.  Diameter
was designed to have a base protocol and a suite of Diameter
applications.  RADIUS has no such provisions.  There seems to be some
confusion in the Diameter community as to the guidelines for extending
Diameter applications, so even in that case the problem may not be fully
specified.

RADIUS was originally conceived as a "service description language" and
a "service provisioning service".  RADIUS Servers were "smart" and
RADIUS Clients were "dumb".  Over time, some folks have come to think of
RADIUS as a convenient transport for all sorts of applications.  I think
this leads to problems.  If we're looking for a generic application
transport, perhaps BEEP might be a more appropriate choice.
=20
> So if in a particular scheme a NAS has a question to ask that happens
to
> pertain to an existing session, that is between the NAS and the EAP
type
> or other backend logic to figure out, and should not have an influence
> on the RADIUS protocol.

The problem I see with the use of RADIUS as a transport mechanism for
other applications is that it leads to poor multi-vendor
interoperability.  I understand that individual vendors or consortia
might not be so concerned with interoperability for a specialized
application, but the IETF is concerned.  If we continue to add opaque
"blobs" of data in RADIUS attributes, and rely on non-RADIUS
documentation to define the semantics of that data, I think we run the
risk of fragmenting RADIUS into several distinct dialects.  IMHO, this
would be a Bad Thing (tm).
=20
> Sorry for the long rant, but I see an explosion of complexity here in
> the last months, without the clear layering that would keep RADIUS the
> simple, elegant protocol it's always been.

I happen to personally agree that there is a lot of complexity in some
of the current and recent proposals to extend RADIUS.  I also believe
that some of the complexity is desired but not needed.  By that, I mean
that the problem could be solved in a simpler way without much loss of
generality.  OTOH, I think that simply hiding that complexity "under the
rug" of another, non-RADIUS, protocol does substantial damage to RADIUS
as a highly interoperable protocol.  So, yes, by all means, let's
attempt to keep the extensions as simple as they reasonably can be, but
let's not decide to "punt" on the hard issue of global interoperability
by simply declaring the details as out of scope for 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: Wed, 27 Jul 2005 12:14:05 +0000
Date: Wed, 27 Jul 2005 14:07:24 +0200
From: Emile van Bergen <[email-masked]>
To: [email-masked]
Subject: Re: [RADIUS FIXES] Authorize Only
Mail-Followup-To: [email-masked]

Hi,

On Tue, Jul 26, 2005 at 10:51:35AM -0400, Avi Lior wrote:

> Thanx for the support.  I don't agree that the use of Authorize-Only
> should be discouraged though.  It has tremendous use for allowing the
> NAS and Server to manage an already established session without the need
> for re-authentication.
> 
> This is important since AAA (Diameter and RADIUS) are being used to
> manage sessions that are much more complex today.

This is of course true, but why is it required for the RADIUS client to
use the Service-Type attribute to flag that the
authentication/authorization request is actually an extension of an
earlier one?

The way I have come to think about RADIUS is that an Access-Request /
Access-Response transaction is just a way for a client to ask a
questions to server that it trusts.

The question may actually be 'verify identity and return profile X', the
question may be 'return profile X', the question may be 'proceed with
another step in a lengthy EAP discussion'; but in all cases the meaning
of such a question may only be obvious to a particularly configured
instance of a RADIUS server, playing a role in a particular application.

To put it differently: I think that it helps to distinguish two layers
in RADIUS, with RFC2865 at the bottom, and an *user defined* application
at the top.

So if in a particular scheme a NAS has a question to ask that happens to
pertain to an existing session, that is between the NAS and the EAP type
or other backend logic to figure out, and should not have an influence
on the RADIUS protocol.

Even the separation of authentication and authorization is problematic
because the client needs to supply a ticket to refer to an earlier,
succesful authentication, and the server needs to keep state about that.
The combination of attributes that would define a ticket, and how its
lifetime would be governed, is definitely a question for the future
application, and not for RADIUS.

I am afraid that if we try to separate authentication from authorization
in RADIUS, we're making RADIUS into something that it fundamentally
isn't (a protocol that requires the server to keep state after an
authentication *as part of the basic protocol*).

So in short, I would suggest to have the application define the
attribute(s) to be used as the session ticket and the attributes to
distinguish updates in whatever direction from new sessions in such
cases, but to keep all that jazz on a layer well above the simple,
fundamentally stateless Access-Request / Access-Accept transaction.

Authorize-Only should not affect a RADIUS server core in any way. User
defined logic, yes. SQL, yes. Internal state, no. The RADIUS server
itself should not care whether you're starting a new session, continuing
an existing session, reauthorize because someone's worried about
something. 

A RADIUS server should answer the access request using whatever rules
the administrator gives, possibly updating whatever state in a database,
but should then be allowed to forget about it all. It should not be
required to hold some abstract 'session' for which subsequent
Authorize-Only requests may be received -- at least not outside the
external, high level database.

Such a database or the logic (lifetimes, timeouts, session state
transitions) should not be required for scenarios that don't
need them, ie. authorizations that don't care about reauthentications. 

If a NAS or application can avoid the un-RADIUS-like separation of
authentication and authorization, it should.

If reauthentication is a problem, supply a different set of credentials
that have a different meaning to the upper layers, and use them to
refer to an existing session. Cf. EAP.

Sorry for the long rant, but I see an explosion of complexity here in
the last months, without the clear layering that would keep RADIUS the
simple, elegant protocol it's always been.

Cheers,

Emile.

-- 
E-Advies - Emile van Bergen           [email-masked]      
tel. +31 (0)70 3906153           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: Tue, 26 Jul 2005 20:51:35 +0000
From: "Alan DeKok" <[email-masked]>
To: "Nelson, David" <[email-masked]>
Subject: Re: Issue: Vendor Specifc Attribute Values 
Cc: [email-masked]
Date: Tue, 26 Jul 2005 16:51:30 -0400
Message-Id: <[email-masked]>

"Nelson, David" <[email-masked]> wrote:
> OTOH, the fact that one or more vendors chose to implement a needed
> (or desired) function in a particular fashion should not set a
> binding precedent on the RADEXT WG.  These extensions, in all
> likelihood, received no IETF review, or even third party review,
> prior to their implementation and deployment.  We should look at
> these "ad hoc" extensions with a critical eye.

  Absolutely.  I have no objections to the use of VSE's, but I do have
conditions on their use.  Use and design of VSE's SHOULD follow from a
standards process.  Otherwise, existing standards are re-used in
situations where they may not be appropriate.

  I view VSE's as a minor shortcoming in the original RADIUS spec.  We
have VSA's, so it isn't a large leap to standardize *some* form of
VSE's.

  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: Tue, 26 Jul 2005 19:58:11 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue: Vendor Specifc Attribute Values 
Date: Tue, 26 Jul 2005 15:57:27 -0400
From: "Nelson, David" <[email-masked]>
To: "Alan DeKok" <[email-masked]>, <[email-masked]>

Alan DeKok writes...

>   2882 uses Vendor-Specific Enumerations (VSE's).  We should use that
> here.

RFC 2882 is certainly a fact-based document.  It reports existing
deployment behaviors.  Its abstract reads:

Abstract

   This document describes current practices implemented in NAS products
   that go beyond the scope of the RADIUS RFCs 2138, 2139 [1,2]. The
   purpose of this effort is to give examples that show the need for
   addressing and standardizing these types of ad-hoc functions.  Since
   many of these features require a matching server support component,
   the ability to deploy and manage interoperable NAS and AAA server
   products is severely hindered.

   These practices are documented here to show functions that are
   obviously desired in developing future AAA protocols for NAS
   deployment.

IMHO, we should be careful about inferring any desired or implied level
of standardization of any of the practices reported in 2882.  If there
is no good reason to the contrary, then following existing convention
may be a good thing.  OTOH, the fact that one or more vendors chose to
implement a needed (or desired) function in a particular fashion should
not set a binding precedent on the RADEXT WG.  These extensions, in all
likelihood, received no IETF review, or even third party review, prior
to their implementation and deployment.  We should look at these "ad
hoc" extensions with a critical eye.

--
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: Tue, 26 Jul 2005 19:44:26 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Subject: Re: Issue: Vendor Specifc Attribute Values 
Date: Tue, 26 Jul 2005 15:44:35 -0400
Message-Id: <[email-masked]>

"Alan DeKok" <[email-masked]> wrote:
> These values may be called Vendor-Specific Values (VSV's).

  2882 uses Vendor-Specific Enumerations (VSE's).  We should use that
here.

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

Envelope-to: [email-masked]
Delivery-date: Tue, 26 Jul 2005 19:17:38 +0000
From: "Alan DeKok" <[email-masked]>
To: "Nelson, David" <[email-masked]>
Subject: Re: Issue: Vendor Specifc Attribute Values 
Cc: [email-masked]
Date: Tue, 26 Jul 2005 15:17:33 -0400
Message-Id: <[email-masked]>

"Nelson, David" <[email-masked]> wrote:
> Requested change:
> 
> Describe the practice.  Include recommendations for or against the
> practice, and standardize the recommend method of encoding, if the
> practice is encouraged.

  After a bit of searching, RFC 2882, section 2.2.1 documents this.

  I would recommend using the practice, and documenting the encoding
as defined above.

Proposed text:

  In addition to Vendor-Specific Attributes (VSA's), it is useful for
vendors to define custom values for previously defined attributes.
These values may be called Vendor-Specific Values (VSV's).  This
practice is encouraged, as it avoids overloading of existing values.
Given a choice between re-using an existing value in a context where
it may not be directly applicable, or defining a VSV, vendors SHOULD
define a new VSV.

   A summary of the Vendor-Specific Value format is shown below.  The
   fields are transmitted from left to right.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Vendor-Id           |          Vendor-Value         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Vendor-Id

      2 octets of the SMI Network Management Private Enterprise Code
      of the Vendor in network byte order, as defined in the "Assigned
      Numbers" RFC [6].

  Vendor-Value

      2 octets defining the vendor-specific value.

  VSV's MUST be defined only for attributes of type "integer", and
then only where the existing standards define one or more values for
the attribute.

  Note that the Vendor-Id is defined here as a 16-bit number, where it
is defined as a 32-bit number in the Vendor-Specific attribute.  This
choice may not be the best one, and is driven by the limitations of
the 32-bit integer field.

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

Envelope-to: [email-masked]
Delivery-date: Tue, 26 Jul 2005 18:45:41 +0000
From: "Alan DeKok" <[email-masked]>
To: "Avi Lior" <[email-masked]>
Subject: Re: [RADIUS FIXES] Authorize Only 
Cc: "Bernard Aboba" <[email-masked]>, "Nelson, David" <[email-masked]>, [email-masked]
Date: Tue, 26 Jul 2005 14:45:49 -0400
Message-Id: <[email-masked]>

"Avi Lior" <[email-masked]> wrote:
> I am not seeking a vendor specific solution.  So vendor specific value
> for Service Type is not a starter.

  That's fine.

> How about these two values:
> 
> Service-Reauthorization: a reauthorization of a service associated with
> the session.
> 
> Service-Authorization: an initial authorization of a service associated
> with the session.

  I'm OK with that.  I would be carefully to define what the terms
mean, though, to avoid having similar discussions in the future.  

  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: Tue, 26 Jul 2005 18:30:50 +0000
Content-class: urn:content-classes:message
Subject: RE: [RADIUS FIXES] Authorize Only
Date: Tue, 26 Jul 2005 14:30:06 -0400
From: "Nelson, David" <[email-masked]>
To: "Avi Lior" <[email-masked]>, "Alan DeKok" <[email-masked]>
Cc: "Bernard Aboba" <[email-masked]>, <[email-masked]>

Avi Lior writes...

> Is there work to be done? yes.
>=20
> From my perspective, the work is being driven by 3GPP, 3GPP2 and now
> WiMAX.

If we all agree that there is some conceptual framework work (on
multiple services) that needs to be done as a prerequisite to some of
the new SDO requirements, then we're OK, I think.

It would not be good for each application to handle this in a different
fashion.

--
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, 26 Jul 2005 18:28:41 +0000
Content-class: urn:content-classes:message
Subject: RE: [RADIUS FIXES] Authorize Only
Date: Tue, 26 Jul 2005 14:28:41 -0400
From: "Avi Lior" <[email-masked]>
To: "Alan DeKok" <[email-masked]>, "Nelson, David" <[email-masked]>
Cc: "Bernard Aboba" <[email-masked]>, <[email-masked]>

See Inline.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf=20
> Of Alan DeKok
> Sent: Tuesday, July 26, 2005 2:13 PM
> To: Nelson, David
> Cc: Avi Lior; Bernard Aboba; [email-masked]
> Subject: Re: [RADIUS FIXES] Authorize Only
>=20
>=20
> "Nelson, David" <[email-masked]> wrote:
> > Yes, but are multiple services within a single session=20
> currently well=20
> > defined in RADIUS RFCs?  We had quite a dialogue about the issue of=20
> > multiple services on the RADEXT list about a year ago.  I=20
> don't recall=20
> > whether any consensus emerged out of that discussion.
>=20
>   My $0.02 is Issue #68, which became section 2.6.2 of the=20
> issues & fixes document.  There was at least one post to=20
> issue 68 indicating agreement, but no more discussion.
>=20
>   In summary, where services can be offered independently,=20
> they should be AAA'd independently.  The NAS *may* offer=20
> information indicating that they are related, but this often=20
> isn't done today.

See that is not the trend - at least in wireless.  It may be okay for
enterprises.  In wireless you don't want to authenticate the subscriber
for each service.  It takes too long. Operators are looking for mobile
nodes to come up quickly.  Therefore the opposite is true.

In fact in many cases we pre-authorize services that the user is likely
to use in order to get the upper hand on time.

>   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: Tue, 26 Jul 2005 18:26:43 +0000
Content-class: urn:content-classes:message
Subject: RE: [RADIUS FIXES] Authorize Only 
Date: Tue, 26 Jul 2005 14:25:32 -0400
From: "Nelson, David" <[email-masked]>
To: "Alan DeKok" <[email-masked]>
Cc: "Avi Lior" <[email-masked]>, "Bernard Aboba" <[email-masked]>, <[email-masked]>

Alan DeKok writes...

>   My $0.02 is Issue #68, which became section 2.6.2 of the issues &
> fixes document.  There was at least one post to issue 68 indicating
> agreement, but no more discussion.

Issue 68 speaks about non layer 2 services, and interpreting them in
context.  It does not elaborate on the issue of multiple, overlapping,
concurrent services within a session (i.e. nested sub-sessions).

>   In summary, where services can be offered independently, they should
> be AAA'd independently.  The NAS *may* offer information indicating
> that they are related, but this often isn't done today.

It's that structured relationship that I'm attempting to nail down in
this particular sub-thread.

--
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, 26 Jul 2005 18:17:20 +0000
Content-class: urn:content-classes:message
Subject: RE: [RADIUS FIXES] Authorize Only
Date: Tue, 26 Jul 2005 14:17:22 -0400
From: "Avi Lior" <[email-masked]>
To: "Nelson, David" <[email-masked]>, "Alan DeKok" <[email-masked]>
Cc: "Bernard Aboba" <[email-masked]>, <[email-masked]>

Hi David,

Multiple services and multiple service instances are absolutely a
reality that RADIUS has to address.

The new RADIUS RFCs are starting to emerge now to address these issue:
Prepaid, QoS, are two that come to mind.

The Congdon draft supports these concepts as well but at the IP layer.

Is there work to be done? yes.

>From my perspective, the work is being driven by 3GPP, 3GPP2 and now
WiMAX.

3GPP and 3GPP2 have already expressed interest in this.  I would expect
some liaison from WiMAX for some of this work.

> -----Original Message-----
> From: Nelson, David [mailto:[email-masked]]=20
> Sent: Tuesday, July 26, 2005 2:03 PM
> To: Avi Lior; Alan DeKok
> Cc: Bernard Aboba; [email-masked]
> Subject: RE: [RADIUS FIXES] Authorize Only
>=20
>=20
> Avi Lior writes...
>=20
> > Service-Reauthorization: a reauthorization of a service associated
> with
> > the session.
> >=20
> > Service-Authorization: an initial authorization of a service
> associated
> > with the session.
>=20
> Yes, but are multiple services within a single session=20
> currently well defined in RADIUS RFCs?  We had quite a=20
> dialogue about the issue of multiple services on the RADEXT=20
> list about a year ago.  I don't recall whether any consensus=20
> emerged out of that discussion.
>=20
> RFC 3576 certainly opens the door to multiple services.  But=20
> does it treat them in a complete fashion?
>=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: Tue, 26 Jul 2005 18:15:33 +0000
Content-class: urn:content-classes:message
Subject: Issue: Vendor Specifc Attribute Values
Date: Tue, 26 Jul 2005 14:15:26 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Submitter name: Dave Nelson
Submitter email address: [email-masked]
Date first submitted: July 26, 2005
Reference: t.b.s.
Document: RADIUS Design Guidelines
Comment type: 'T'echnical=20
Priority: '1' Should fix
Section: (new)
Rationale/Explanation of issue: Discuss the use of Vendor Specific
Atibute Values

Length description of problem

In addition to the well-documented Vendor Specific Attributes (VSA),
implementation practice has extended to Vendor Specific Values (VSV) of
IETF Standard RADIUS Attributes.

A snippet from a RADEXT list thread:

See:

http://www.freeradius.org/cgi-bin/cvsweb.cgi/radiusd/share/dictionary.ba
y?rev=3D1.5&content-type=3Dtext/x-cvsweb-markup

Look for "Service-Type".  Vendor-specific values are of the form
((vendor-id << 16) | num), One of the RFC's refers to this practice, but
I can't recall which right now.=20

Requested change:

Describe the practice.  Include recommendations for or against the
practice, and standardize the recommend method of encoding, if the
practice is encouraged.

--
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: Tue, 26 Jul 2005 18:12:57 +0000
From: "Alan DeKok" <[email-masked]>
To: "Nelson, David" <[email-masked]>
Subject: Re: [RADIUS FIXES] Authorize Only 
Cc: "Avi Lior" <[email-masked]>, "Bernard Aboba" <[email-masked]>, [email-masked]
Date: Tue, 26 Jul 2005 14:13:02 -0400
Message-Id: <[email-masked]>

"Nelson, David" <[email-masked]> wrote:
> Yes, but are multiple services within a single session currently well
> defined in RADIUS RFCs?  We had quite a dialogue about the issue of
> multiple services on the RADEXT list about a year ago.  I don't recall
> whether any consensus emerged out of that discussion.

  My $0.02 is Issue #68, which became section 2.6.2 of the issues &
fixes document.  There was at least one post to issue 68 indicating
agreement, but no more discussion.

  In summary, where services can be offered independently, they should
be AAA'd independently.  The NAS *may* offer information indicating
that they are related, but this often isn't done today.

  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: Tue, 26 Jul 2005 18:03:49 +0000
Content-class: urn:content-classes:message
Subject: RE: [RADIUS FIXES] Authorize Only
Date: Tue, 26 Jul 2005 14:02:35 -0400
From: "Nelson, David" <[email-masked]>
To: "Avi Lior" <[email-masked]>, "Alan DeKok" <[email-masked]>
Cc: "Bernard Aboba" <[email-masked]>, <[email-masked]>

Avi Lior writes...

> Service-Reauthorization: a reauthorization of a service associated
with
> the session.
>=20
> Service-Authorization: an initial authorization of a service
associated
> with the session.

Yes, but are multiple services within a single session currently well
defined in RADIUS RFCs?  We had quite a dialogue about the issue of
multiple services on the RADEXT list about a year ago.  I don't recall
whether any consensus emerged out of that discussion.

RFC 3576 certainly opens the door to multiple services.  But does it
treat them in a complete fashion?

--
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, 26 Jul 2005 17:56:20 +0000
Content-class: urn:content-classes:message
Subject: RE: [RADIUS FIXES] Authorize Only
Date: Tue, 26 Jul 2005 13:55:59 -0400
From: "Avi Lior" <[email-masked]>
To: "Alan DeKok" <[email-masked]>
Cc: "Bernard Aboba" <[email-masked]>, "Nelson, David" <[email-masked]>, <[email-masked]>

Alan,

I am not seeking a vendor specific solution.  So vendor specific value
for Service Type is not a starter.

I am not seeking a change to 3576 either.  So how about the following:

Authorize-Only:  complete reauthorization of the session as defined by
3576.

How about these two values:

Service-Reauthorization: a reauthorization of a service associated with
the session.

Service-Authorization: an initial authorization of a service associated
with the session.

I would be very happy with this and in one case where we use
Authorize-Only we could make the change to Service-Reauthorization.

(If we could only have one of the above the Service-Authorization would
work for me).

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf=20
> Of Alan DeKok
> Sent: Tuesday, July 26, 2005 12:54 PM
> To: Avi Lior
> Cc: Bernard Aboba; Nelson, David; [email-masked]
> Subject: Re: [RADIUS FIXES] Authorize Only
>=20
>=20
> "Avi Lior" <[email-masked]> wrote:
> > I don't understand why you would say it's a vendor-specific=20
> value of=20
> > Service-Type.
>=20
>   See:
>=20
> http://www.freeradius.org/cgi-bin/cvsweb.cgi/radiusd/share/dic
> tionary.bay?rev=3D1.5&content-type=3Dtext/x-cvsweb-markup
>=20
>   Look for "Service-Type".  Vendor-specific values are of the=20
> form ((vendor-id << 16) | num), One of the RFC's refers to=20
> this practice, but I can't recall which right now.
>=20
> > Thanx for the support.  I don't agree that the use of=20
> Authorize-Only=20
> > should be discouraged though.  It has tremendous use for=20
> allowing the=20
> > NAS and Server to manage an already established session without the=20
> > need for re-authentication.
>=20
>   I agree.  My only point of discussion is what should the=20
> name be, and should we re-use an existing value.
>=20
> > I would perfer that RADIUS issues and fixes provide=20
> guidelines on how=20
> > to use Authorize-Only.
>=20
>   I agree.
>=20
> > I would have rather had the following Service-Type:
> >=20
> > Re-Authorize:  this is what 3576 should be using.  It completely=20
> > re-triggers the re-authorization of the session.
>=20
>   That's reasonable, but I don't think you're proposing to=20
> change RFC 3576.
>=20
> > Authorize-Only: is used the way I describe.  We do not completely=20
> > reauthorize the session but rather the context of what is being=20
> > reauthorized is determined from the contents of the packet.=20
>  It still=20
> > must be bound to an Authenticated Session or entity. The=20
> binding being=20
> > the same or similar to 3576.
>=20
>   Then I have few problems with re-using the name.
>=20
> > Note:  if someone can propose a new Service-Type value to=20
> achieve the=20
> > same then I would be for that.  Although I belive there is=20
> already an=20
> > specification for Authorize-Only outside the IETF.
>=20
>   All the more reason to use vendor-specific values, so=20
> vendor-specific practices don't re-use existing definitions.
>=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/>

Envelope-to: [email-masked]
Delivery-date: Tue, 26 Jul 2005 16:53:53 +0000
From: "Alan DeKok" <[email-masked]>
To: "Avi Lior" <[email-masked]>
Subject: Re: [RADIUS FIXES] Authorize Only 
Cc: "Bernard Aboba" <[email-masked]>, "Nelson, David" <[email-masked]>, [email-masked]
Date: Tue, 26 Jul 2005 12:53:38 -0400
Message-Id: <[email-masked]>

"Avi Lior" <[email-masked]> wrote:
> I don't understand why you would say it's a vendor-specific value of
> Service-Type.

  See:

http://www.freeradius.org/cgi-bin/cvsweb.cgi/radiusd/share/dictionary.bay?rev=1.5&content-type=text/x-cvsweb-markup

  Look for "Service-Type".  Vendor-specific values are of the form
((vendor-id << 16) | num), One of the RFC's refers to this practice,
but I can't recall which right now.

> Thanx for the support.  I don't agree that the use of Authorize-Only
> should be discouraged though.  It has tremendous use for allowing the
> NAS and Server to manage an already established session without the need
> for re-authentication.

  I agree.  My only point of discussion is what should the name be,
and should we re-use an existing value.

> I would perfer that RADIUS issues and fixes provide guidelines on how to
> use Authorize-Only.

  I agree.

> I would have rather had the following Service-Type:
> 
> Re-Authorize:  this is what 3576 should be using.  It completely
> re-triggers the re-authorization of the session.

  That's reasonable, but I don't think you're proposing to change RFC
3576.

> Authorize-Only: is used the way I describe.  We do not completely
> reauthorize the session but rather the context of what is being
> reauthorized is determined from the contents of the packet.  It still
> must be bound to an Authenticated Session or entity.
> The binding being the same or similar to 3576.

  Then I have few problems with re-using the name.

> Note:  if someone can propose a new Service-Type value to achieve the
> same then I would be for that.  Although I belive there is already an
> specification for Authorize-Only outside the IETF.

  All the more reason to use vendor-specific values, so
vendor-specific practices don't re-use existing definitions.

  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: Tue, 26 Jul 2005 15:26:45 +0000
Content-class: urn:content-classes:message
Subject: RE: [RADIUS FIXES] Authorize Only
Date: Tue, 26 Jul 2005 11:25:51 -0400
From: "Nelson, David" <[email-masked]>
To: "Avi Lior" <[email-masked]>, "Alan DeKok" <[email-masked]>
Cc: "Bernard Aboba" <[email-masked]>, <[email-masked]>

I think it's important for all IETF RADIUS documents to define the
semantics and usage rules of its protocol elements, in this instance the
values taken on by Attributes, in a complete and unambiguous fashion.
That is absolutely required to achieve multi-vendor interoperability,
using only the documents themselves as source material.  Leaving the
usage and semantics of protocol elements loosely defined, so as to
enable future product feature innovation, using RADIUS, is a good thing
for developers and product introduction schedules.  It is generally a
bad thing for standardization and interoperability.  Since the only
reason to expend the collective efforts of an IETF WG is to publish
clear, well-defined and highly interoperable protocol standards (or
informational status protocols), it seems that the interests of
interoperability should take precedence over the interests of expedient
product development.

I also understand that lots of things are defined as "RADIUS" outside of
the IETF.  Some are good and useful and some (IMHO) bend the protocol to
the point of being unrecognizable.  I would not like to use some of the
more "liberal" reinterpretations of RADIUS that have occurred outside of
the IETF over the years as the basis for RADEXT WG work.

If we can come to a reasonable consensus on the semantics and usage
rules for Authorize-Only, citing specific applications, and not violate
any normative requirements of the base RADIUS documents, that would be a
good thing.  I think, however, we should be careful to avoid defining
Authorize-Only, or any other attribute besides a VSA, as a general
"catch-all" for yet unspecified feature innovation.

--
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, 26 Jul 2005 14:51:43 +0000
Content-class: urn:content-classes:message
Subject: RE: [RADIUS FIXES] Authorize Only
Date: Tue, 26 Jul 2005 10:51:35 -0400
From: "Avi Lior" <[email-masked]>
To: "Alan DeKok" <[email-masked]>
Cc: "Bernard Aboba" <[email-masked]>, "Nelson, David" <[email-masked]>, <[email-masked]>

Hi Alan,

Please see inline.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf=20
> Of Alan DeKok
> Sent: Monday, July 25, 2005 8:01 PM
> To: Avi Lior
> Cc: Bernard Aboba; Nelson, David; [email-masked]
> Subject: Re: [RADIUS FIXES] Authorize Only
>=20
>=20
> "Avi Lior" <[email-masked]> wrote:
> > I think perhaps we should explore the danger of having such=20
> a facility=20
> > and perhaps describe how it is to be used.
>=20
>   Your application seems to be well-scoped, at least.
>=20
> > This is a good question.  I think the "application" should=20
> define the=20
> > semantics.  So if the Application is Base RADIUS (2865 etc) then we=20
> > follow the rules specified by 3576 that new attribute replace=20
> > previously received attributes.  In the case of Prepaid the=20
> > application deals with this explicitly so that there is no=20
> confusion.
>=20
>   It is then a "vendor-specific" value for Service-Type.

I don't understand why you would say it's a vendor-specific value of
Service-Type.

>=20
> > Does this answer your questions?
>=20
>   Yes.  My suggestion is to call your scenario=20
> "pre-paid-re-authorization".

I don't agree.  There are other uses of authorize only.
=20
>   I would prefer to define a new application-specific value=20
> for Service-Type.  That value can then take on whatever=20
> meaning is required for your needs.  The re-use of=20
> Authorize-Only is awkward, and could be deprecated.  (Barring=20
> re-deployment costs.)

I do have a wish .... See below.
=20
>   That being said, I have no serious objections to permitting=20
> this use of Authorize-Only.  I would still prefer to have the=20
> "issues and fixes" strongly discourage further use of the=20
> value, though.

Thanx for the support.  I don't agree that the use of Authorize-Only
should be discouraged though.  It has tremendous use for allowing the
NAS and Server to manage an already established session without the need
for re-authentication.

This is important since AAA (Diameter and RADIUS) are being used to
manage sessions that are much more complex today.

I would perfer that RADIUS issues and fixes provide guidelines on how to
use Authorize-Only.

Finally here is my wish:

I would have rather had the following Service-Type:

Re-Authorize:  this is what 3576 should be using.  It completely
re-triggers the re-authorization of the session.

Authorize-Only: is used the way I describe.  We do not completely
reauthorize the session but rather the context of what is being
reauthorized is determined from the contents of the packet.  It still
must be bound to an Authenticated Session or entity.
The binding being the same or similar to 3576.

Note:  if someone can propose a new Service-Type value to achieve the
same then I would be for that.  Although I belive there is already an
specification for Authorize-Only outside the IETF.

>   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: Tue, 26 Jul 2005 14:41:04 +0000
Content-class: urn:content-classes:message
Subject: RE: [RADIUS FIXES] Authorize Only
Date: Tue, 26 Jul 2005 10:40:31 -0400
From: "Avi Lior" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, "Alan DeKok" <[email-masked]>
Cc: "Nelson, David" <[email-masked]>, <[email-masked]>

I think in my last email I covered Bernard's concern.

So far, authorize only is bound to an existing session using the same
mechanism in Dynamic Auth.

In prepaid -- which relies on Auth-Only we even go further a also tie
the quotas appearing in the access request Authorize Only to quotas
delivered in a previous access-accept by using a QID that changes for
every exchange of Accept/Request.

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]]=20
> Sent: Monday, July 25, 2005 10:16 PM
> To: Alan DeKok
> Cc: Avi Lior; Nelson, David; [email-masked]
> Subject: Re: [RADIUS FIXES] Authorize Only
>=20
>=20
> >   I agree.
> >
> >   Before I offer suggestions, I have a question.  How do=20
> you tie the=20
> > VOIP call into the existing session?  How do you deal with security=20
> > issues such as spoofing, etc?  How does the RADIUS server associate=20
> > the two requests?
> >
> >   The answers to those questions will influence any=20
> suggestion I might=20
> > have for a solution.
>=20
> Yes, I think these questions are the important ones.  RFC=20
> 2865 and subsequent RADIUS RFCs have required authentication=20
> of every RADIUS session.  My understanding is that "Authorize=20
> Only" was discussed in the original RADIUS WG, but the=20
> decision was made to prohibit it.
>=20
> The prohibition was loosened in RFC 3576 because in dynamic=20
> authorization authentication had already occurred.  An=20
> "Authorize Only" Access-Request can only occur as the result=20
> of a Disconnect or CoA-Request relating to a session that had=20
> previously been authenticated.  Although RFC 3576 does not=20
> say so, it would be wise for a RADIUS server receiving an=20
> "Authorize Only" request to check whether the request was=20
> legitimate before answering
> -- such a request cannot, for example, be for a user that had=20
> not previously established a session, or be for an=20
> established user on a different NAS than the one which=20
> received the Disconnect or CoA-Request.
>=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: Tue, 26 Jul 2005 02:17:09 +0000
Date: Mon, 25 Jul 2005 19:16:19 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Alan DeKok <[email-masked]>
cc: Avi Lior <[email-masked]>, "Nelson, David" <[email-masked]>, [email-masked]
Subject: Re: [RADIUS FIXES] Authorize Only 

>   I agree.
>
>   Before I offer suggestions, I have a question.  How do you tie the
> VOIP call into the existing session?  How do you deal with security
> issues such as spoofing, etc?  How does the RADIUS server associate
> the two requests?
>
>   The answers to those questions will influence any suggestion I might
> have for a solution.

Yes, I think these questions are the important ones.  RFC 2865 and
subsequent RADIUS RFCs have required authentication of every RADIUS
session.  My understanding is that "Authorize Only" was discussed in
the original RADIUS WG, but the decision was made to prohibit it.

The prohibition was loosened in RFC 3576 because in dynamic authorization
authentication had already occurred.  An "Authorize Only" Access-Request
can only occur as the result of a Disconnect or CoA-Request relating to a
session that had previously been authenticated.  Although RFC 3576 does
not say so, it would be wise for a RADIUS server receiving an "Authorize
Only" request to check whether the request was legitimate before answering
-- such a request cannot, for example, be for a user that had not
previously established a session, or be for an established user on a
different NAS than the one which received the Disconnect or CoA-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/>

Envelope-to: [email-masked]
Delivery-date: Tue, 26 Jul 2005 00:00:34 +0000
From: "Alan DeKok" <[email-masked]>
To: "Avi Lior" <[email-masked]>
Subject: Re: [RADIUS FIXES] Authorize Only 
Cc: "Bernard Aboba" <[email-masked]>, "Nelson, David" <[email-masked]>, [email-masked]
Date: Mon, 25 Jul 2005 20:00:32 -0400
Message-Id: <[email-masked]>

"Avi Lior" <[email-masked]> wrote:
> I think perhaps we should explore the danger of having such a
> facility and perhaps describe how it is to be used.

  Your application seems to be well-scoped, at least.

> This is a good question.  I think the "application" should define the
> semantics.  So if the Application is Base RADIUS (2865 etc) then we
> follow the rules specified by 3576 that new attribute replace previously
> received attributes.  In the case of Prepaid the application deals with
> this explicitly so that there is no confusion.

  It is then a "vendor-specific" value for Service-Type.

> Sure. But we should not limit something because some use-cases are going
> to be problematic.  In prepaid I would have a real problem if I don't
> have this capability.

  I would not want that. :)

....

> Does this answer your questions?

  Yes.  My suggestion is to call your scenario "pre-paid-re-authorization".

  I would prefer to define a new application-specific value for
Service-Type.  That value can then take on whatever meaning is
required for your needs.  The re-use of Authorize-Only is awkward, and
could be deprecated.  (Barring re-deployment costs.)

  That being said, I have no serious objections to permitting this use
of Authorize-Only.  I would still prefer to have the "issues and
fixes" strongly discourage further use of the value, though.

  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: Mon, 25 Jul 2005 23:41:33 +0000
Content-class: urn:content-classes:message
Subject: RE: [RADIUS FIXES] Authorize Only
Date: Mon, 25 Jul 2005 19:41:14 -0400
From: "Avi Lior" <[email-masked]>
To: "Alan DeKok" <[email-masked]>
Cc: "Bernard Aboba" <[email-masked]>, "Nelson, David" <[email-masked]>, <[email-masked]>

Hi Alan,

Thanx for the quick response -- see inline.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf=20
> Of Alan DeKok
> Sent: Monday, July 25, 2005 5:59 PM
> To: Avi Lior
> Cc: Bernard Aboba; Nelson, David; [email-masked]
> Subject: Re: [RADIUS FIXES] Authorize Only
>=20
>=20
> "Avi Lior" <[email-masked]> wrote:
> > First, I don't think that 3576 prohibited the use of=20
> Authorize-Only --=20
> > some implementation and specification already use Authorize-Only.
>=20
>   Outside the scope of it's definited usage scenario.

I wont argue on this point since it may generate more heat then light if
you know what I mean ;-)

> > Second, I think that having "Authorize-Only" has utility.
>=20
>   I agree.  *What* utility is a qualification that needs to=20
> be defined.

Sure.  But again we may never be able to describe all utilities.  I
think perhaps we should explore the danger of having such a facility and
perhaps describe how it is to be used.

> >  In fact one case is prepaid where the NAS and Server maintain a=20
> > conversation regarding the replenshiment of prepaid quota.  The=20
> > replenishing of the quota is triggered by the NAS (usually)=20
> using an=20
> > Access-Request (Note the NAS is the only entity that knows when the=20
> > quota is used up).  Without the having the ability to use the=20
> > semantics provided by "Authorize-Only" we would have no=20
> option but to=20
> > reauthenticate.
>=20
>   Are the semantics information returned from Authorize-Only:
>=20
>   a) additional to existing authorization
>   b) replacement of existing authorization
>   c) some combination of (a) and (b)

This is a good question.  I think the "application" should define the
semantics.  So if the Application is Base RADIUS (2865 etc) then we
follow the rules specified by 3576 that new attribute replace previously
received attributes.  In the case of Prepaid the application deals with
this explicitly so that there is no confusion.

>   In your scenario, the use is well defined.  The danger in=20
> allowing Authorize-Only is that other use-cases may not be=20
> well defined.

Sure. But we should not limit something because some use-cases are going
to be problematic.  In prepaid I would have a real problem if I don't
have this capability.

> > Support for Authorize-Only is key in supporting many new=20
> functionality=20
> > that allow the NAS to authorize new resources without=20
> authenticating=20
> > the user.  For example, we may want to authorize a Voip call for an=20
> > already existing session.  I feel strongly that we need to support=20
> > this capability in RADIUS.
>=20
>   I agree.
>=20
>   Before I offer suggestions, I have a question.  How do you=20
> tie the VOIP call into the existing session?  How do you deal=20
> with security issues such as spoofing, etc?  How does the=20
> RADIUS server associate the two requests?

Forgetting existing VoIP protocols like SIP etc.

When a terminal wants to make a VoIP call the NAS may send an
Access-Request with Service-Type =3D "Authorize-Only"
It will need to establish a context for what purpose it is sending this
request and for whom.

The for "whom" part would require NAI, Calling Station ID, CUI, IP
address, or even Accounting Session Id, VSA - this is similar to the
requirements in 3576.

The context can be established by the presence of an attribute. In 3576
the context is in essence base RADIUS.  In prepaid, there is an
attribute that is included that tells the RADIUS server the context of
the authorize only and what action is being requested.  In VoIP it could
be the an Attribute that describes the number the device wants to
contact.

Regarding security. =20
The Authorize-Only MUST be protected using Message-Authenticator since
there is no password.  This is as defined by 3576.

Other then that, RADIUS is hop-by-hop protocol and hops are implicitly
trusted. No different then any other RADIUS interaction.
=20
>   The answers to those questions will influence any=20
> suggestion I might have for a solution.

Does this answer your questions?
=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/>

Envelope-to: [email-masked]
Delivery-date: Mon, 25 Jul 2005 21:58:50 +0000
From: "Alan DeKok" <[email-masked]>
To: "Avi Lior" <[email-masked]>
Subject: Re: [RADIUS FIXES] Authorize Only 
Cc: "Bernard Aboba" <[email-masked]>, "Nelson, David" <[email-masked]>, [email-masked]
Date: Mon, 25 Jul 2005 17:58:31 -0400
Message-Id: <[email-masked]>

"Avi Lior" <[email-masked]> wrote:
> First, I don't think that 3576 prohibited the use of Authorize-Only --
> some implementation and specification already use Authorize-Only.

  Outside the scope of it's definited usage scenario.

> Second, I think that having "Authorize-Only" has utility.

  I agree.  *What* utility is a qualification that needs to be defined.

>  In fact one case is prepaid where the NAS and Server maintain a
> conversation regarding the replenshiment of prepaid quota.  The
> replenishing of the quota is triggered by the NAS (usually) using an
> Access-Request (Note the NAS is the only entity that knows when the
> quota is used up).  Without the having the ability to use the
> semantics provided by "Authorize-Only" we would have no option but
> to reauthenticate.

  Are the semantics information returned from Authorize-Only:

  a) additional to existing authorization
  b) replacement of existing authorization
  c) some combination of (a) and (b)

  In your scenario, the use is well defined.  The danger in allowing
Authorize-Only is that other use-cases may not be well defined.

> Support for Authorize-Only is key in supporting many new
> functionality that allow the NAS to authorize new resources without
> authenticating the user.  For example, we may want to authorize a
> Voip call for an already existing session.  I feel strongly that we
> need to support this capability in RADIUS.

  I agree.

  Before I offer suggestions, I have a question.  How do you tie the
VOIP call into the existing session?  How do you deal with security
issues such as spoofing, etc?  How does the RADIUS server associate
the two requests?

  The answers to those questions will influence any suggestion I might
have for a solution.

  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: Mon, 25 Jul 2005 18:16:20 +0000
Content-class: urn:content-classes:message
Subject: [RADIUS FIXES] Authorize Only
Date: Mon, 25 Jul 2005 14:15:38 -0400
From: "Avi Lior" <[email-masked]>
To: "Alan DeKok" <[email-masked]>, "Bernard Aboba" <[email-masked]>, "Nelson, David" <[email-masked]>
Cc: <[email-masked]>

Hi,

Read through radius fixes.  I have one immediate issue:

In RADIUS FIXES you state:

" A Service-Type of "Authorization-Only"
   MUST NOT be included in a RADIUS Challenge or Reject packet and MAY
   only be included in an Access-Request or Accept packet as part of an
   exchange resulting from the sending of a Disconnect-Request or CoA-
   Request containing a Service-Type value of "Authorization-Only"
"

I don't aggree that Service-Type of Authorization-Only should be limited
to operations relating to COA or DM.

First, I don't think that 3576 prohibited the use of Authorize-Only --
some implementation and specification already use Authorize-Only.

Second, I think that having "Authorize-Only" has utility. In fact one
case is prepaid where the NAS and Server maintain a conversation
regarding the replenshiment of prepaid quota.  The replenishing of the
quota is triggered by the NAS (usually) using an Access-Request (Note
the NAS is the only entity that knows when the quota is used up).
Without the having the ability to use the semantics provided by
"Authorize-Only" we would have no option but to reauthenticate.  This
would be unacceptable especially today when multi round EAP methods are
being used.

Support for Authorize-Only is key in supporting many new functionality
that allow the NAS to authorize new resources without authenticating the
user.  For example, we may want to authorize a Voip call for an already
existing session.  I feel strongly that we need to support this
capability in RADIUS.

Finally, note that in Diameter base, the use of Authorize-Only is not
limited to only RAR/RAA transactions.  Therefore we should not limit the
use in RADIUS either since we may run into translation problems later
on.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Avi Lior                                   =20
Bridgewater Systems Corporation=20
Phone :  +1 (613) 591-9104 x6417
Cell    :  +1 (613) 796-4183
E-mail : mailto:[email-masked]
www.bridgewatersystems.com=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, 25 Jul 2005 16:27:03 +0000
Content-class: urn:content-classes:message
Subject: FYI I-D ACTION:draft-lior-radius-prepaid-extensions-08.txt
Date: Mon, 25 Jul 2005 12:27:05 -0400
From: "Avi Lior" <[email-masked]>
To: <[email-masked]>

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Tuesday, July 19, 2005 3:50 PM
To: [email-masked]
Subject: {Blocked Content} I-D
ACTION:draft-lior-radius-prepaid-extensions-08.txt

Warning: This message has had one or more attachments removed
Warning: (not named).
Warning: Please read the "VirusWarning.txt" attachment(s) for more
information.

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: PrePaid Extensions to Remote Authentication=20
                          Dial-In User Service (RADIUS)
	Author(s)	: A. Lior, et al.
	Filename	: draft-lior-radius-prepaid-extensions-08.txt
	Pages		: 54
	Date		: 2005-7-19
=09
This draft presents an extension to the Remote Authentication Dial-
   In User Service (RADIUS) protocol to support charging for prepaid=20
   services. The charging models supported are namely: volume-based=20
   charging, duration-based charging and one-time-based charging.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-lior-radius-prepaid-extensions
-08.txt

To remove yourself from the I-D Announcement list, send a message to=20
[email-masked] with the word unsubscribe in the body of
the message. =20
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the
username "anonymous" and a password of your e-mail address. After
logging in, type "cd internet-drafts" and then
	"get draft-lior-radius-prepaid-extensions-08.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html=20
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE
/internet-drafts/draft-lior-radius-prepaid-extensions-08.txt".
=09
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 "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail
readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
	=09
	=09
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--
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, 25 Jul 2005 16:26:18 +0000
Content-class: urn:content-classes:message
Subject: FYI I-D ACTION:draft-lior-radext-end-to-end-caps-01.txt
Date: Mon, 25 Jul 2005 12:26:11 -0400
From: "Avi Lior" <[email-masked]>
To: <[email-masked]>

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Thursday, July 21, 2005 3:50 PM
To: [email-masked]
Subject: {Blocked Content} I-D
ACTION:draft-lior-radext-end-to-end-caps-01.txt

Warning: This message has had one or more attachments removed
Warning: (not named).
Warning: Please read the "VirusWarning.txt" attachment(s) for more
information.

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: End-to-End Capabilities Support for Remote=20
                          Authentication Dial In User Service (RADIUS)
	Author(s)	: A. Lior, F. Adrangi
	Filename	: draft-lior-radext-end-to-end-caps-01.txt
	Pages		: 12
	Date		: 2005-7-21
=09
This document describes a new RADIUS attribute, End-to-End-Capability
   which can be used by a NAS to indicate its RADIUS capabilities to the
   RADIUS server and also allows the RADIUS server to request certain
   capabilities from the NAS.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-lior-radext-end-to-end-caps-01
.txt

To remove yourself from the I-D Announcement list, send a message to=20
[email-masked] with the word unsubscribe in the body of
the message. =20
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the
username "anonymous" and a password of your e-mail address. After
logging in, type "cd internet-drafts" and then
	"get draft-lior-radext-end-to-end-caps-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html=20
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE
/internet-drafts/draft-lior-radext-end-to-end-caps-01.txt".
=09
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 "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail
readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
	=09
	=09
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--
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, 25 Jul 2005 16:26:10 +0000
Content-class: urn:content-classes:message
Subject: FYI  I-D ACTION:draft-lior-radius-bandwidth-capability-01.txt
Date: Mon, 25 Jul 2005 12:25:48 -0400
From: "Avi Lior" <[email-masked]>
To: <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C59135.84296A5D
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Thursday, July 21, 2005 3:50 PM
To: [email-masked]
Subject: {Blocked Content} I-D
ACTION:draft-lior-radius-bandwidth-capability-01.txt

Warning: This message has had one or more attachments removed
Warning: (not named).
Warning: Please read the "VirusWarning.txt" attachment(s) for more
information.

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: Network Bandwidth Parameters for Remote=20
                          Authentication Dial In User Service (RADIUS).
	Author(s)	: A. Lior, et al.
	Filename	: draft-lior-radius-bandwidth-capability-01.txt
	Pages		: 18
	Date		: 2005-7-21
=09
This document describes bandwidth profile parameters and a protocol
   framework that enables an AAA server to specify the parameters that
   should be allocated by the access network for duration of an
   authorized user session.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-lior-radius-bandwidth-capabili
ty-01.txt

To remove yourself from the I-D Announcement list, send a message to=20
[email-masked] with the word unsubscribe in the body of
the message. =20
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the
username "anonymous" and a password of your e-mail address. After
logging in, type "cd internet-drafts" and then
	"get draft-lior-radius-bandwidth-capability-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html=20
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE
/internet-drafts/draft-lior-radius-bandwidth-capability-01.txt".
=09
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 "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail
readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
	=09
	=09
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

------_=_NextPart_001_01C59135.84296A5D
Content-Type: text/plain;
	name="VirusWarning.txt"
Content-Transfer-Encoding: base64
Content-Description: VirusWarning.txt
Content-Disposition: attachment;
	filename="VirusWarning.txt"

------_=_NextPart_001_01C59135.84296A5D
Content-Type: text/plain;
	name="VirusWarning.txt"
Content-Transfer-Encoding: base64
Content-Description: VirusWarning.txt
Content-Disposition: attachment;
	filename="VirusWarning.txt"

------_=_NextPart_001_01C59135.84296A5D
Content-Type: text/plain;
	name="ATT481195.txt"
Content-Transfer-Encoding: base64
Content-Description: ATT481195.txt
Content-Disposition: attachment;
	filename="ATT481195.txt"

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v
dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cxLmll
dGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlDQo=

------_=_NextPart_001_01C59135.84296A5D--

--
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, 24 Jul 2005 13:26:19 +0000
Content-class: urn:content-classes:message
Subject: IETF-63  RADEXT WG Agenda -- Take Three
Date: Sun, 24 Jul 2005 09:25:11 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, "Bernard Aboba" <[email-masked]>

IETF 63 RADEXT WG Meeting
Wednesday, August 3, 2005
10:30 - 12:30 (Morning Session II)=20

Chairs:
Bernard Aboba <[email-masked]>
David Nelson <[email-masked]>

Preliminaries (5 minutes)
-------------------------------------------------------------------

Blue Sheets
Minutes
Agenda bashing
Document Status
Issue Status (see http://www.drizzle.com/~aboba/RADEXT/)

Completed IETF Last Call
-------------------------------------------------------------------

"RFC 2486bis", Jari Arkko (5 minutes)
http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2486bis-06.txt

Completed WG Last Call (in IESG review)
-------------------------------------------------------------------

"Chargeable User Identity", Avi Lior (5 minutes)
http://www.ietf.org/internet-drafts/draft-ietf-radext-chargeable-user-id
-03.txt

Completed WG Last Call (in issue resolution)
--------------------------------------------------------------------

"RADIUS Digest Authentication", Wolfgang Beck (5 minutes)
http://www.ietf.org/internet-drafts/draft-ietf-radext-digest-auth-03.txt

"Dynamic Authorization Server/Client MIBs", Greg Weber (5 minutes)
http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-server-mib
-01.txt
http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-client-mib
-01.txt

In WG Last Call (until August 10)
--------------------------------------------------------------------

"VLAN, Priority, and Filtering Attributes", Paul Congdon (15 minutes)
http://www.ietf.org/internet-drafts/draft-ietf-radext-ieee802-00.txt

WG Work Item Review
--------------------------------------------------------------------

RADIUS MIB Revisions, David Nelson (5 minutes)=20
http://www.ietf.org/internet-drafts/draft-nelson-rfc2618bis-01.txt
http://www.ietf.org/internet-drafts/draft-nelson-rfc2619bis-01.txt
http://www.ietf.org/internet-drafts/draft-nelson-rfc2620bis-01.txt
http://www.ietf.org/internet-drafts/draft-nelson-rfc2621bis-01.txt

Pre WG Work Item Review
--------------------------------------------------------------------

"Common RADIUS Implementation Issues and Suggested Fixes", David Nelson,
(10 minutes)
http://www.ietf.org/internet-drafts/draft-aboba-radext-fixes-00.txt

"Design Guidelines for RADIUS Attributes", Greg Weber (15 minutes)
http://www.ietf.org/internet-drafts/draft-weber-radius-attr-guidelines-0
0.txt

"RADIUS Attributes for WLAN", David Nelson (10 minutes)
http://www.ietf.org/internet-drafts/draft-aboba-radext-wlan-00.txt

"RADIUS Attributes for Key Delivery", Glen Zorn (5 minutes)
http://www.ietf.org/internet-drafts/draft-zorn-radius-keywrap-07.txt

General WG discussion of key-wrap methods and RADIUS security issues.=20
(10 minutes)

"End-to-End Capabilities Support for Remote Authentication Dial In User
Service (RADIUS)", Avi Lior (5 minutes)
http://www.ietf.org/internet-drafts/draft-lior-radext-end-to-end-caps-01
.txt
             =20
"Prepaid Extensions to Remote Authentication Dial-In User Service
(RADIUS)", Avi Lior (5 minutes)
http://www.ietf.org/internet-drafts/draft-lior-radius-prepaid-extensions
-08.txt

"Network Bandwidth Parameters for Remote Authentication Dial In User
Service (RADIUS)", Avi Lior (5 minutes)
http://www.ietf.org/internet-drafts/draft-lior-radius-bandwidth-capabili
ty-01.txt

"RADIUS Quality of Service Support", Hannes Tschofenig (5 minutes)
http://www.ietf.org/internet-drafts/draft-tschofenig-radext-qos-01.txt

General WG discussion of QoS and Bandwidth authorization issues.
(10 minutes)

Adjourn

--
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, 22 Jul 2005 21:50:12 +0000
Date: Fri, 22 Jul 2005 14:49:40 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Murtaza Chiba <[email-masked]>
cc: "Nelson, David" <[email-masked]>, [email-masked]
Subject: Re: Request for Review of RFC 3576 MIB documents

> The last time I attempted an errata for the RFC, the standards body did
> not respond.  IMO, as Nagi mentioned, its relatively easy to understand
> the difference as we have clearly laid it out in the definition of the
> DAC and DAS as was suggested by Bernard.

The issue was added to the list of potential "RFC 3576bis" issues; it was
not lost.

Some of the "RFC 3576bis" issues are included in the "Issues and Fixes"
document.  However, we have now collected enough of these so that it
may make more sense to do an "RFC3576bis" instead of trying to
handle them all in the "Issues and Fixes" 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: Fri, 22 Jul 2005 20:03:49 +0000
Date: Fri, 22 Jul 2005 13:03:12 -0700
From: Murtaza Chiba <[email-masked]>
To: "Nelson, David" <[email-masked]>
CC: Bernard Aboba <[email-masked]>, [email-masked]
Subject: Re: Request for Review of RFC 3576 MIB documents

Nelson, David wrote:
>>I agree that the original RFC should be rectified as well.  However, I
>>am not sure whether we should carry the confusion into all the related
>>documents and then add erratas to them as well.
> 
> 
> Perhaps not, but you would need to perform the clarification in the
> protocol document (RFC 5776) and the relayed MIB concurrently, IMHO.

The last time I attempted an errata for the RFC, the standards body did 
not respond.  IMO, as Nagi mentioned, its relatively easy to understand 
the difference as we have clearly laid it out in the definition of the 
DAC and DAS as was suggested by Bernard.

Regards,
Murtaza

--
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, 22 Jul 2005 18:40:23 +0000
Content-class: urn:content-classes:message
Subject: RE: Request for Review of RFC 3576 MIB documents
Date: Fri, 22 Jul 2005 14:39:53 -0400
From: "Nelson, David" <[email-masked]>
To: "Murtaza Chiba" <[email-masked]>
Cc: "Bernard Aboba" <[email-masked]>, <[email-masked]>

> I agree that the original RFC should be rectified as well.  However, I
> am not sure whether we should carry the confusion into all the related
> documents and then add erratas to them as well.

Perhaps not, but you would need to perform the clarification in the
protocol document (RFC 5776) and the relayed MIB concurrently, IMHO.

--
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, 22 Jul 2005 18:08:14 +0000
Date: Fri, 22 Jul 2005 11:08:13 -0700
From: Murtaza Chiba <[email-masked]>
To: "Nelson, David" <[email-masked]>
CC: Bernard Aboba <[email-masked]>, [email-masked]
Subject: Re: Request for Review of RFC 3576 MIB documents

Nelson, David wrote:
>>The RFC really changes the traditional concept of what elements behave
>>as a RADIUS server and which as the RADIUS client.  The original
> 
> drafts
> 
>>had that clear and I didnt realize that the final versions actually
>>didnt emphasize it.  So we tried to clarify that with the MIB and
>>mentioned upfront what the new terms actually represented.
> 
> 
> If there are errata in RFC 3576 (or at least the need for substantial
> clarification) then it SHOULD NOT be handled in the related MIBs.  It
> SHOULD be handled in the Issues and Fixes draft, or if required,
> possibly in a separate 3576bis draft.  Note, however that RFC 3576 is an
> Informational RFC, that was published as an individual submission.  Any
> revisions or clarifications thereto handled in the RADEXT WG would be
> subject to WG consensus. 
> 

I agree that the original RFC should be rectified as well.  However, I 
am not sure whether we should carry the confusion into all the related 
documents and then add erratas to them as well.

Murtaza

> 
> 
> --
> 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, 22 Jul 2005 18:04:18 +0000
Content-class: urn:content-classes:message
Subject: RE: Request for Review of RFC 3576 MIB documents
Date: Fri, 22 Jul 2005 23:33:29 +0530
From: "Nagi Reddy Jonnala \(njonnala\)" <[email-masked]>
To: "Nelson, David" <[email-masked]>, "Murtaza Chiba \(mchiba\)" <[email-masked]>
Cc: <[email-masked]>

Initially the Dynamic Authorization Client and Dynamic Authorization
Server terminology was initiated because the "client" and "server"
entities are different here(when compared with
authentication/accounting). For instance, the authentication/accounting
entity that resides on the NAS is described as
"authentication/accounting client" and the same case with
"authentication/accounting server". In the Dynamic Authorization case,
calling the Dynamic Authorization entity that resides on the NAS as
"Dynamic Authorization Client(DAC) actually creates more confusion. So
we had to flip the terminology.

Having said that as mentioned by Murtaza, there could be other entities
like Prepaid Server who are neither Radius authentication nor accounting
servers.=20

Though if the WG suggests good terminology, we see no reason to adopt
that terminology instead of DAC and DAS. IMO, though the existing DAC
and DAS terminology may look confusing initially but once the ice is
broken, it would actually make more sense.

Thanks
Nagi.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Nelson, David
Sent: Friday, July 22, 2005 7:54 PM
To: Murtaza Chiba (mchiba)
Cc: [email-masked]
Subject: RE: Request for Review of RFC 3576 MIB documents

> > Why can't we just state up front that a DynAuthClient =3D RADIUS
Server,
> > DynAuthServer =3D RADIUS Client, and avoid using the DAC and DAS=20
> > abbreviations?
> >
>=20
> One reason is that the client need not be limited to a RADIUS Server.
> Infact it can be any entity that shares a secret and uses the
interfaces
> specified by RFC3576, for e.g. a Rating Engine or a Captive Portal.

Hmmm.  I don't think it's a good idea for RADIUS RFCs (or the RADEXT WG)
to be documenting protocols for applications that are not RADIUS.  While
I understand that one *could* re-use elements of RADIUS protocol
documents to create a new application, I think that the RADIUS documents
themselves need to stick close to home and describe RADIUS.  Period.

> > Section 5
> > "This table contains one row for each DAS that the DAC shares a
secret
> with."
> >
> > RFC 3576 only talks about secrets shared between RADIUS clients and=20
> > servers, not between a DAS and a DAC.
> >
>=20
> Kind of same as above.

I offer the same comment as above, in kind.  :-)

-- Dave

--
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, 22 Jul 2005 17:53:04 +0000
Content-class: urn:content-classes:message
Subject: RE: Request for Review of RFC 3576 MIB documents
Date: Fri, 22 Jul 2005 13:52:51 -0400
From: "Nelson, David" <[email-masked]>
To: "Murtaza Chiba" <[email-masked]>
Cc: "Bernard Aboba" <[email-masked]>, <[email-masked]>

> The RFC really changes the traditional concept of what elements behave
> as a RADIUS server and which as the RADIUS client.  The original
drafts
> had that clear and I didnt realize that the final versions actually
> didnt emphasize it.  So we tried to clarify that with the MIB and
> mentioned upfront what the new terms actually represented.

If there are errata in RFC 3576 (or at least the need for substantial
clarification) then it SHOULD NOT be handled in the related MIBs.  It
SHOULD be handled in the Issues and Fixes draft, or if required,
possibly in a separate 3576bis draft.  Note, however that RFC 3576 is an
Informational RFC, that was published as an individual submission.  Any
revisions or clarifications thereto handled in the RADEXT WG would be
subject to WG consensus.=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, 22 Jul 2005 17:46:31 +0000
Date: Fri, 22 Jul 2005 10:46:06 -0700
From: Murtaza Chiba <[email-masked]>
To: "Nelson, David" <[email-masked]>
CC: Bernard Aboba <[email-masked]>, [email-masked]
Subject: Re: Request for Review of RFC 3576 MIB documents

Nelson, David wrote:
>>I think the document is describing RADIUS.  But Murtaza is saying that
> 
> the
> 
>>entity that sends the Disconnect-Request or CoA-Request may not be the
>>same entity as the RADIUS authentication server.  It could for
> 
> example, be
> 
>>located on the same box as the RADIUS Accounting Server, or on a box
>>different from both the accounting and authentication servers.
> 
> 
> So, one could classify these additional entities as performing the role
> of either a RADIUS [Accounting] Client or RADIUS [Accounting] Server,
> even though they may not be the same entity that participated in the
> initial authentication and authorization.  Is that correct?  If so, then
> we should say it that way.
>  
> 
>>This is all true, but I still think it's confusing for an RFC 3576 MIB
> 
> to
> 
>>use different terminology than RFC 3576.
> 
> 
> I agree.
>

The RFC really changes the traditional concept of what elements behave 
as a RADIUS server and which as the RADIUS client.  The original drafts 
had that clear and I didnt realize that the final versions actually 
didnt emphasize it.  So we tried to clarify that with the MIB and 
mentioned upfront what the new terms actually represented.

If there is a general consensus on that being rather confusing, we can 
switch it around but still maintain some text to clarify the roles!

Thanks,
Murtaza

> 
> --
> 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, 22 Jul 2005 15:29:07 +0000
Content-class: urn:content-classes:message
Subject: Pre-soliciting volunteers for the RADEXT WG session at IETF-63
Date: Fri, 22 Jul 2005 11:28:23 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

WG Members,

This "plea for assistance" is addressed to those WG Members who plan to =
attend the RADEXT WG session at IETF-63.  As you may have noticed, the =
WG agenda is very full, with no "pad" times.  We will need to start the =
meeting promptly and keep to the allotted times.

I'm pre-soliciting two volunteers to act as note takes and one volunteer =
to act as time keeper.  Bernard has a PC application that we typically =
use as a presentation timer that I can provide to you.  Bernard does not =
plan to attend IETF-63, so I won't have a Co-Chair to share the duties.

Please consider volunteering for these positions by contacting me [well] =
in advance of the meeting.  Thanks!!!

Regards,
=A0
Dave
=A0

=A0

--
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, 22 Jul 2005 15:25:26 +0000
Content-class: urn:content-classes:message
Subject: RE: Request for Review of RFC 3576 MIB documents
Date: Fri, 22 Jul 2005 11:25:16 -0400
From: "Nelson, David" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Cc: "Murtaza Chiba" <[email-masked]>, <[email-masked]>

> I think the document is describing RADIUS.  But Murtaza is saying that
the
> entity that sends the Disconnect-Request or CoA-Request may not be the
> same entity as the RADIUS authentication server.  It could for
example, be
> located on the same box as the RADIUS Accounting Server, or on a box
> different from both the accounting and authentication servers.

So, one could classify these additional entities as performing the role
of either a RADIUS [Accounting] Client or RADIUS [Accounting] Server,
even though they may not be the same entity that participated in the
initial authentication and authorization.  Is that correct?  If so, then
we should say it that way.
=20
> This is all true, but I still think it's confusing for an RFC 3576 MIB
to
> use different terminology than RFC 3576.

I agree.

--
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, 22 Jul 2005 15:20:55 +0000
Date: Fri, 22 Jul 2005 08:20:37 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: "Nelson, David" <[email-masked]>
cc: Murtaza Chiba <[email-masked]>, [email-masked]
Subject: RE: Request for Review of RFC 3576 MIB documents

> Hmmm.  I don't think it's a good idea for RADIUS RFCs (or the RADEXT WG)
> to be documenting protocols for applications that are not RADIUS.  While
> I understand that one *could* re-use elements of RADIUS protocol
> documents to create a new application, I think that the RADIUS documents
> themselves need to stick close to home and describe RADIUS.  Period.
>

I think the document is describing RADIUS.  But Murtaza is saying that the
entity that sends the Disconnect-Request or CoA-Request may not be the
same entity as the RADIUS authentication server.  It could for example, be
located on the same box as the RADIUS Accounting Server, or on a box
different from both the accounting and authentication servers.

This is all true, but I still think it's confusing for an RFC 3576 MIB to
use different terminology than RFC 3576.

--
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, 22 Jul 2005 14:25:14 +0000
Content-class: urn:content-classes:message
Subject: RE: Request for Review of RFC 3576 MIB documents
Date: Fri, 22 Jul 2005 10:24:08 -0400
From: "Nelson, David" <[email-masked]>
To: "Murtaza Chiba" <[email-masked]>
Cc: <[email-masked]>

> > Why can't we just state up front that a DynAuthClient =3D RADIUS
Server,
> > DynAuthServer =3D RADIUS Client, and avoid using the DAC and DAS
> > abbreviations?
> >
>=20
> One reason is that the client need not be limited to a RADIUS Server.
> Infact it can be any entity that shares a secret and uses the
interfaces
> specified by RFC3576, for e.g. a Rating Engine or a Captive Portal.

Hmmm.  I don't think it's a good idea for RADIUS RFCs (or the RADEXT WG)
to be documenting protocols for applications that are not RADIUS.  While
I understand that one *could* re-use elements of RADIUS protocol
documents to create a new application, I think that the RADIUS documents
themselves need to stick close to home and describe RADIUS.  Period.

> > Section 5
> > "This table contains one row for each DAS that the DAC shares a
secret
> with."
> >
> > RFC 3576 only talks about secrets shared between RADIUS clients and
> > servers, not between a DAS and a DAC.
> >
>=20
> Kind of same as above.

I offer the same comment as above, in kind.  :-)

-- Dave

--
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, 22 Jul 2005 04:42:25 +0000
Date: Fri, 22 Jul 2005 13:41:56 +0900
From: Hideo "Sir MaNMOS" Morishita <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: new version of draft-ietf-radext-digest-auth
Organization: StellarCraft Inc.Japan.

3.17  Digest-Domain attribute

   Description
       .
       .
       .
         protection space (see [RFC2617], section 3.2.1).  RADIUS
         servers MAY send one or more attributes of this type in Access-
                          ^^^^^^^^^^^
         Challenge messages.  This attribute MUST only be used in
         Access-Challenge messages.
but

5.  Table of Attributes
   +-------------------------+-----+-----+--------+--------+-----------+
   | Attribute               | #   | Req | Accept | Reject | Challenge |
   +-------------------------+-----+-----+--------+--------+-----------+
   .
   .
   .
   | Digest-Domain           | TBD | 0   | 0      | 0      | 0-1       |

---
   ___     わしは、山吹色のかすてーらが大好きでのぅ
 [[o o]]            ふぉっふぉっふぉ
   'J'     森下 お代官様 ＭａＮＭＯＳ 英夫＠ステラクラフト
PGP Finger = CD EA D5 A8 AD B2 FE 7D  02 74 87 52 7C B7 39 37

--
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, 21 Jul 2005 21:41:28 +0000
Content-class: urn:content-classes:message
Subject: Draft IETF-63  RADEXT WG Agenda -- Take Two
Date: Thu, 21 Jul 2005 17:40:33 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>
Cc: "Bernard Aboba" <[email-masked]>

This is the second draft of the RADEXT WG agenda for IETF-63.  WG
agendas
are due into the Secretariat by Monday, July 25, 2005.  Please review
and comment upon the proposed agenda by COB Friday.

IETF 63 RADEXT WG Meeting
Wednesday, August 3, 2005
10:30 - 12:30 (Morning Session II)=20

Chairs:
Bernard Aboba <[email-masked]>
David Nelson <[email-masked]>

Preliminaries (5 minutes)
-------------------------------------------------------------------

Blue Sheets
Minutes
Document Status
Issue Status (see http://www.drizzle.com/~aboba/RADEXT/)

Completed IETF Last Call
-------------------------------------------------------------------

"RFC 2486bis", Jari Arkko (5 minutes)
http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2486bis-06.txt

Completed WG Last Call (in IESG review)
-------------------------------------------------------------------

"Chargeable User Identity", TBD (5 minutes)
http://www.ietf.org/internet-drafts/draft-ietf-radext-chargeable-user-id
-03.txt

Completed WG Last Call (in issue resolution)
--------------------------------------------------------------------

"RADIUS Digest Authentication", Wolfgang Beck (5 minutes)
http://www.ietf.org/internet-drafts/draft-ietf-radext-digest-auth-03.txt

"Dynamic Authorization Server/Client MIBs", TBD (5 minutes)
http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-server-mib
-01.txt
http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-client-mib
-01.txt

In WG Last Call (until August 10)
--------------------------------------------------------------------

"VLAN, Priority, and Filtering Attributes", Paul Congdon (15 minutes)
http://www.ietf.org/internet-drafts/draft-ietf-radext-ieee802-00.txt

WG Work Item Review
--------------------------------------------------------------------

RADIUS MIB Revisions, David Nelson (5 minutes)=20
http://www.ietf.org/internet-drafts/draft-nelson-rfc2618bis-01.txt
http://www.ietf.org/internet-drafts/draft-nelson-rfc2619bis-01.txt
http://www.ietf.org/internet-drafts/draft-nelson-rfc2620bis-01.txt
http://www.ietf.org/internet-drafts/draft-nelson-rfc2621bis-01.txt

Pre WG Work Item Review
--------------------------------------------------------------------

"Common RADIUS Implementation Issues and Suggested Fixes", TBD,
(10 minutes)
http://www.ietf.org/internet-drafts/draft-aboba-radext-fixes-00.txt

"Design Guidelines for RADIUS Attributes", Greg Weber (15 minutes)
http://www.ietf.org/internet-drafts/draft-weber-radius-attr-guidelines-0
0.txt

"RADIUS Attributes for WLAN", TBD (10 minutes)
http://www.ietf.org/internet-drafts/draft-aboba-radext-wlan-00.txt

"RADIUS Attributes for Key Delivery", Glen Zorn (5 minutes)
http://www.ietf.org/internet-drafts/draft-zorn-radius-keywrap-07.txt

General WG discussion of key-wrap methods and RADIUS security issues.=20
(10 minutes)

"End-to-End Capabilities Support for Remote Authentication Dial In User
Service (RADIUS)", Avi Lior (5 minutes)
http://www.ietf.org/internet-drafts/lior-radext-end-to-end-caps-01.txt
             =20
"Prepaid Extensions to Remote Authentication Dial-In User Service
(RADIUS)", Avi Lior (5 minutes)
http://www.ietf.org/internet-drafts/lior-radius-prepaid-extensions-08.tx
t

"Network Bandwidth Parameters for Remote Authentication Dial In User
Service (RADIUS)", Avi Lior (5 minutes)
http://www.ietf.org/internet-drafts/lior-radius-bandwidth-capability-01.
txt

"RADIUS Quality of Service Support", Hannes Tschofenig (5 minutes)
http://www.ietf.org/internet-drafts/draft-tschofenig-radext-qos-01.txt

General WG discussion of QoS and Bandwidth authorization issues.
(10 minutes)

Adjourn

--
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: Wed, 20 Jul 2005 23:41:13 +0000
From: "Alan DeKok" <[email-masked]>
To: Bernard Aboba <[email-masked]>
Subject: Re: Issue: Multi-homed, multi-version IP stacks 
Cc: [email-masked]
Date: Wed, 20 Jul 2005 19:40:40 -0400
Message-Id: <[email-masked]>

Bernard Aboba <[email-masked]> wrote:
> The NAS-Identifier is supposed to identify the originating NAS.  So there
> is no requirement that the proxy re-write it (though some might do that).

  Agreed.

> I'm not clear what the use of a Proxy-Identifier would be.

  If the proxies re-write the NAS-identifier, then the issue discussed
above for the NAS-Identifier apply to proxies.

  If the proxies don't re-write NAS-Identifer, then the multi-homing
issues that apply to NASes still apply to proxies.  Since we indicate
that a request came from the "same" NAS via the NAS-Identifer, it may
be useful to indicate that the request was routed through the "same"
proxy, via a similar, per-proxy idenfifier.

  If we don't care to know about routing, then there's no need to
identify proxies.

  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: Wed, 20 Jul 2005 19:21:33 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue: Multi-homed, multi-version IP stacks 
Date: Wed, 20 Jul 2005 15:21:02 -0400
From: "Nelson, David" <[email-masked]>
To: "Alan DeKok" <[email-masked]>, <[email-masked]>

Alan DeKok writes...

> How does this affect proxies?  Should they re-write the
> NAS-Identifier to be their identifier?

I would think not.

> Should we have a Proxy-Identifier attribute?

If it is important for the RADIUS server (or client, for that matter) to
know the proxy (or proxies) transited, then this may be valuable.  What
would be the use case?

--
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, 20 Jul 2005 19:20:24 +0000
Date: Wed, 20 Jul 2005 12:20:10 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Alan DeKok <[email-masked]>
cc: [email-masked]
Subject: Re: Issue: Multi-homed, multi-version IP stacks 

>   How does this affect proxies?  Should they re-write the
> NAS-Identifier to be their identifier?  Should we have a
> Proxy-Identifier attribute?

The NAS-Identifier is supposed to identify the originating NAS.  So there
is no requirement that the proxy re-write it (though some might do that).

I'm not clear what the use of a Proxy-Identifier would be.

--
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: Wed, 20 Jul 2005 19:12:30 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Subject: Re: Issue: Multi-homed, multi-version IP stacks 
Date: Wed, 20 Jul 2005 15:12:27 -0400
Message-Id: <[email-masked]>

"Nelson, David" <[email-masked]> wrote:
...

  I agree.

  How does this affect proxies?  Should they re-write the
NAS-Identifier to be their identifier?  Should we have a
Proxy-Identifier attribute?

  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: Wed, 20 Jul 2005 18:50:42 +0000
Content-class: urn:content-classes:message
Subject: Issue: Multi-homed, multi-version IP stacks
Date: Wed, 20 Jul 2005 14:36:54 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Description of issue:
Submitter name: Dave Nelson / Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: July 20, 2005
Reference: RADEXT Issue 87
Document: Issues and Fixes draft
Comment type: T
Priority: '1' Should fix
Section: N/A
Rationale/Explanation of issue:

A sub-portion of the Issue 87 discussion is being filed as a new and
separate Issue.  The relevant portion of that discussion, contributed by
Bernard Aboba, follows.

"However, this does bring up another issue, which is how the RADIUS=20
server identifies the  NAS if it is more than one hop away.  NASes can=20
have more than one IPv6 address and this makes it possible for a NAS=20
to put a linkscope address in the NAS-IPv6-Address field.  If the=20
proxy is on the same link as the RADIUS client, the RADIUS server=20
could receive a packet with a  NAS-IPv6-Address as a linklocal=20
address.

The same issue can occur with IPv4 Link Local, and of course a NAS can=20
have more than one IPv4 and IPv6 address.

One potential suggestion might be to use the NAS-Identifier attribute=20
in such a situation so as to avoid having to configure the RADIUS=20
server with all potential NAS addresses."

Length description of problem:

Requested change:
Proposed changes to the document.

"One potential suggestion might be to use the NAS-Identifier attribute=20
in such a situation so as to avoid having to configure the RADIUS=20
server with all potential NAS addresses."

"There are a number of situations in which a NAS may have multiple IP
addresses.  IPv4/IPv6 dual stack operation is one example, but it is
also possible for a NAS to have multiple IPv6 or IPv4 addresses.
A  NAS that is a member of multiple VLANs would have an IPv4 address for
each VLAN.  A NAS also can have multiple IPv6 or IPv4 addresses on a
single interface.

[RFC2865] Section 5.44 states that only a single NAS-IP-Address
attribute may be included in an Access-Request, and that it may not be
included in other messages (Challenge, Reject, Accept).  Similarly,
[RFC3162] Section
3 provides the same restrictions for NAS-IPv6-Address.

Since RADIUS only looks at the packet source address to determine the
appropriate shared secret, if a NAS sends packets from different source
addresses, then the RADIUS server needs to have a shared secret for each
address.

My recommendation is that RADIUS clients with multiple addresses SHOULD
use the NAS-Identifier attribute instead of NAS-IPv4-Address or
NAS-IPv6-Address."

--
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, 20 Jul 2005 18:31:49 +0000
Date: Wed, 20 Jul 2005 11:31:37 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: "Nelson, David" <[email-masked]>
cc: [email-masked]
Subject: NAS Identification (was MIBs)

There are a number of situations in which a NAS may have multiple
IP addresses.  IPv4/IPv6 dual stack operation is one example, but it is
also possible for a NAS to have multiple IPv6 or IPv4 addresses.
A  NAS that is a member of multiple VLANs would have an IPv4
address for each VLAN.  A NAS also can have multiple IPv6 or IPv4
addresses on a single interface.

[RFC2865] Section 5.44 states that only a single NAS-IP-Address attribute
may be included in an Access-Request, and that it may not be included in
other messages (Challenge, Reject, Accept).  Similarly, [RFC3162] Section
3 provides the same restrictions for NAS-IPv6-Address.

Since RADIUS only looks at the packet source address to determine the
appropriate shared secret, if a NAS sends packets from different source
addresses, then the RADIUS server needs to have a shared secret for each
address.

My recommendation is that RADIUS clients with multiple addresses SHOULD
use the NAS-Identifier attribute instead of NAS-IPv4-Address or
NAS-IPv6-Address.

Dave Nelson said:

> However, this does bring up another issue, which is how the RADIUS
> server identifies the  NAS if it is more than one hop away.  NASes can
> have more than one IPv6 address and this makes it possible for a NAS to
> put a linkscope address in the NAS-IPv6-Address field.  If the proxy is
> on the same link as the RADIUS client, the RADIUS server could receive a
> packet with a  NAS-IPv6-Address as a linklocal address.
>
> The same issue can occur with IPv4 Link Local, and of course a NAS can
> have more than one IPv4 and IPv6 address.
>
> One potential suggestion might be to use the NAS-Identifier attribute in
> such a situation so as to avoid having to configure the RADIUS server
> with all potential NAS addresses.

--
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, 20 Jul 2005 18:19:58 +0000
Date: Wed, 20 Jul 2005 11:19:47 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: "Nelson, David" <[email-masked]>
cc: [email-masked]
Subject: RE: Revised RADIUS MIBs I-Ds

> However, this does bring up another issue, which is how the RADIUS
> server
> identifies the  NAS if it is more than one hop away.  NASes can have
> more
> than one IPv6 address and this makes it possible for a NAS to put a
> linkscope address in the NAS-IPv6-Address field.  If the proxy is on the
> same link as the RADIUS client, the RADIUS server could receive a packet
> with a  NAS-IPv6-Address as a linklocal address.
>
> The same issue can occur with IPv4 Link Local, and of course a NAS can
> have more than one IPv4 and IPv6 address.
>
> One potential suggestion might be to use the NAS-Identifier attribute in
> such a situation so as to avoid having to configure the RADIUS server
> with
> all potential NAS addresses."
>
> It is not clear that this is a MIB issue per se.  If the WG decides on a
> solution to the issue of multi-homed, multi-version IP stacks, and the
> global vs. local link scope issue, there might or might not be
> implications to the MIBs.  I think that further discussion, and a WG
> consensus is required.  This would seem to be fodder for the Issues and
> Fixes draft.

I agree that this is not a MIB problem and that it needs to be handled in
Issues and Fixes.  Please file an Issue on 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: Wed, 20 Jul 2005 18:05:31 +0000
Content-class: urn:content-classes:message
Subject: RE: Revised RADIUS MIBs I-Ds
Date: Wed, 20 Jul 2005 14:05:00 -0400
From: "Nelson, David" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>

> Is it correct to assume that the revised submissions address all open
> issues?

The only open RADEXT Issue on the MIBs is 87, but it consists of
multiple parts.  I believe the -01 versions address all the sub-issues
of Issue 87, with the possible exception of this one:
=20
"Certainly there will be two different shared secret entries, one with
the
IPv6 address/shared secret and another with the IPv4 address/shared
secret.  Hopefully the RADIUS client will be a bit more intelligent in
not
doing things like failing over from the IPv4 address to the IPv6 address
when the RADIUS server doesn't answer.

However, this does bring up another issue, which is how the RADIUS
server
identifies the  NAS if it is more than one hop away.  NASes can have
more
than one IPv6 address and this makes it possible for a NAS to put a
linkscope address in the NAS-IPv6-Address field.  If the proxy is on the
same link as the RADIUS client, the RADIUS server could receive a packet
with a  NAS-IPv6-Address as a linklocal address.

The same issue can occur with IPv4 Link Local, and of course a NAS can
have more than one IPv4 and IPv6 address.

One potential suggestion might be to use the NAS-Identifier attribute in
such a situation so as to avoid having to configure the RADIUS server
with
all potential NAS addresses."

It is not clear that this is a MIB issue per se.  If the WG decides on a
solution to the issue of multi-homed, multi-version IP stacks, and the
global vs. local link scope issue, there might or might not be
implications to the MIBs.  I think that further discussion, and a WG
consensus is required.  This would seem to be fodder for the Issues and
Fixes draft.

--
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, 20 Jul 2005 17:37:16 +0000
Date: Wed, 20 Jul 2005 10:36:50 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: "Nelson, David" <[email-masked]>
cc: [email-masked]
Subject: RE: Revised RADIUS MIBs I-Ds

Is it correct to assume that the revised submissions address all open
issues?

On Wed, 20 Jul 2005, Nelson, David wrote:

> Sorry for the incomplete message.  My mail client "got away from me".
> :-)
>
> I would like to call the attention of the RADEXT WG to four revised
> I-Ds:
>
> http://www.ietf.org/internet-drafts/draft-nelson-rfc2618bis-01.txt
> http://www.ietf.org/internet-drafts/draft-nelson-rfc2619bis-01.txt
> http://www.ietf.org/internet-drafts/draft-nelson-rfc2620bis-01.txt
> http://www.ietf.org/internet-drafts/draft-nelson-rfc2621bis-01.txt
>
> The -01 versions incorporate the feedback from MIB Doctor review.  These
> documents update their respective predecessor RFCs, deprecate the table
> in which the IPv4-only address objects appear and add a new table
> containing version neutral IP address objects.  The deprecated tables
> MAY be used for backwards compatibility.
>
> Please review and comment upon these drafts.  There will be a very short
> discussion of them at IETF-63.  Shortly after IETF-63, if there are no
> major issues, I propose to submit these I-Ds as RADEXT WG documents and
> initiate a WG Last Call.
>
>
> --
> 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, 20 Jul 2005 15:27:10 +0000
Content-class: urn:content-classes:message
Subject: RE: Revised RADIUS MIBs I-Ds
Date: Wed, 20 Jul 2005 11:25:45 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Sorry for the incomplete message.  My mail client "got away from me".
:-)

I would like to call the attention of the RADEXT WG to four revised
I-Ds:
=20
http://www.ietf.org/internet-drafts/draft-nelson-rfc2618bis-01.txt
http://www.ietf.org/internet-drafts/draft-nelson-rfc2619bis-01.txt
http://www.ietf.org/internet-drafts/draft-nelson-rfc2620bis-01.txt
http://www.ietf.org/internet-drafts/draft-nelson-rfc2621bis-01.txt

The -01 versions incorporate the feedback from MIB Doctor review.  These
documents update their respective predecessor RFCs, deprecate the table
in which the IPv4-only address objects appear and add a new table
containing version neutral IP address objects.  The deprecated tables
MAY be used for backwards compatibility.

Please review and comment upon these drafts.  There will be a very short
discussion of them at IETF-63.  Shortly after IETF-63, if there are no
major issues, I propose to submit these I-Ds as RADEXT WG documents and
initiate a WG Last Call.

--
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, 20 Jul 2005 15:18:34 +0000
Content-class: urn:content-classes:message
Subject: Revised RADIUS MIBs I-Ds
Date: Wed, 20 Jul 2005 11:18:01 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

I would like to call the attention of the RADEXT WG to four revised =
I-Ds:

http://www.ietf.org/internet-drafts/draft-nelson-rfc2621bis-01.txt
http://www.ietf.org/internet-drafts/draft-nelson-rfc2621bis-01.txt
Regards,
=A0
Dave
=A0
David B. Nelson
Enterasys Networks, Inc.
50 Minuteman Road
Andover, MA 01810-1008
Phone: (978) 684-1330=A0=20
E-mail: [email-masked]
=A0

--
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, 19 Jul 2005 15:30:02 +0000
Content-class: urn:content-classes:message
Subject: Draft IETF-63  RADEXT WG Agenda
Date: Tue, 19 Jul 2005 11:29:19 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>
Cc: "Bernard Aboba" <[email-masked]>

This is the first draft of the RADEXT WG agenda for IETF-63.  WG agendas
are due into the Secretariat by Monday, July 25, 2005.  Please review
and comment upon the proposed agenda this week.  Thanks!

IETF 63 RADEXT WG Meeting
Wednesday, August 3, 2005
10:30 - 12:30 (Morning Session II)=20

Chairs:
Bernard Aboba <[email-masked]>
David Nelson <[email-masked]>

Preliminaries (5 minutes)
 Blue Sheets
 Minutes
 Document Status
 Issue Status (see http://www.drizzle.com/~aboba/RADEXT/)

Completed IETF Last Call

"RFC 2486bis", Jari Arkko (5 minutes)
http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2486bis-06.txt

Completed WG Last Call (in IESG review)

"Chargeable User Identity", Farid Adrangi (5 minutes)
http://www.ietf.org/internet-drafts/draft-ietf-radext-chargeable-user-id
-03.txt

Completed WG Last Call (in issue resolution)

RADIUS Digest Authentication, Wolfgang Beck (10 minutes)
http://www.ietf.org/internet-drafts/draft-ietf-radext-digest-auth-03.txt

"Dynamic Authorization Server MIB", TBD (5 minutes)
http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-server-mib
-01.txt

"Dynamic Authorization Client MIB", TBD (5 minutes)
http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-client-mib
-01.txt

In WG Last Call (until August 10)

"VLAN, Priority, and Filtering Attributes", Paul Congdon (15 minutes)
http://www.ietf.org/internet-drafts/draft-ietf-radext-ieee802-00.txt

WG Work Item Review

RADIUS MIB Revisions, David Nelson (5 minutes)=20
http://www.ietf.org/internet-drafts/draft-nelson-rfc2618bis-01.txt
http://www.ietf.org/internet-drafts/draft-nelson-rfc2619bis-01.txt
http://www.ietf.org/internet-drafts/draft-nelson-rfc2620bis-01.txt
http://www.ietf.org/internet-drafts/draft-nelson-rfc2621bis-01.txt

Pre WG Work Item Review

Common RADIUS Implementation Issues and Suggested Fixes, TBD, (15
minutes)
http://www.ietf.org/internet-drafts/draft-aboba-radext-fixes-00.txt

Design Guidelines for RADIUS Attributes, Greg Weber (15 minutes)
draft-weber-radius-attr-guidelines-00.txt

RADIUS Attributes for WLAN, TBD (10 minutes)
http://www.ietf.org/internet-drafts/draft-aboba-radext-wlan-00.txt

RADIUS Attributes for Key Delivery, Glen Zorn (5 minutes)
http://www.ietf.org/internet-drafts/draft-zorn-radius-keywrap-07.txt

"Network Bandwidth Parameters for Remote Authentication Dial In User
Service  (RADIUS).", Avi Lior (5 minutes)
http://www.ietf.org/internet-drafts/lior-radius-bandwidth-capability-01.
txt

"End-to-End Capabilities Support for Remote Authentication Dial In User
Service (RADIUS)", Avi Lior (5 minutes)
http://www.ietf.org/internet-drafts/lior-radext-end-to-end-caps-01.txt
             =20
"Prepaid Extensions to Remote Authentication Dial-In User Service
(RADIUS)", Avi Lior (5 minutes)
http://www.ietf.org/internet-drafts/lior-radius-prepaid-extensions-08.tx
t
             =20
Wrap-Up (10 minutes)

--
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, 18 Jul 2005 20:14:15 +0000
To: [email-masked]
Subject: new version of draft-ietf-radext-digest-auth
Date: Mon, 18 Jul 2005 21:09:56 +0200
From: [email-masked]

draft-ietf-radext-digest-auth-03

is available under
http://bew.afraid.org/draft-ietf-radext-digest-auth-03.txt
or
http://bew.afraid.org.ipv4.sixxs.org/draft-ietf-radext-digest-auth-03.txt
(in case you don't have IPv6 yet)

It contains some changes related to issues mentioned under Issue 78.
- use of Digest-Entity-Body-Hash in extension is no longer mentioned.
AKA Digest is not affected by this, as it re-uses HTTP-Digest anyway

Wolfgang

--
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, 18 Jul 2005 05:12:13 +0000
Content-class: urn:content-classes:message
Subject: RE: RFC 2486bis issue: "Decorated" NAIs and IDN support
Date: Mon, 18 Jul 2005 08:11:05 +0300
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>

Jari,

I think that this text is good to add.

thanks,
John

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of ext Jari Arkko
> Sent: 17 July, 2005 00:03
> To: Bernard Aboba
> Cc: Eronen Pasi (Nokia-NRC/Helsinki); [email-masked];
> [email-masked]; [email-masked]; [email-masked];=20
> [email-masked]
> Subject: Re: RFC 2486bis issue: "Decorated" NAIs and IDN support
>=20
>=20
> Here are the additional text changes, draft URL in the quoted
> mail has also been updated.
>=20
> Section 2.5, add at the end:
>=20
>    The responsibility for the conversion of international domain names
>    to ASCII is left for the end-systems, such as network=20
> access clients
>    and AAA servers.  Similarly, we expect domain name comparisons,
>    matching, resolution, and AAA routing to be performed on the ASCII
>    versions of the international domain names.  This provides a
>    canonical representation, ensures that intermediate systems such as
>    AAA proxies do not need to perform translations, and can=20
> be expected
>    to work through systems that are unaware of international character
>    sets.
>=20
> Section 2.7, add at the end:
>=20
>    Note that the syntax described in this section is optional, and is
>    not a part of the ABNF.  The '!' character may appear in=20
> the username
>    portion of a NAI for other purposes as well, and in those cases the
>    rules outlined here do not apply; the interpretation of=20
> the username
>    is up to an agreement between the identified user and the=20
> realm given
>    after the '@' character.
>=20
> --Jari
>=20
> Bernard Aboba wrote:
>=20
> >Since this is a RADEXT WG draft, would it be possible to=20
> include the logic
> >below in the document itself?  If we don't, I can imagine=20
> having this same
> >conversation in the future.
> >
> >On Sat, 16 Jul 2005, Jari Arkko wrote:
> >
> > =20
> >
> >>Time is running out, so I'm going ahead with submitting
> >>a revision. Here's what I think we agreed:
> >>
> >>1. It is the responsibility of the peer to provide the NAI in
> >>    the correct (IDN-unaware ASCII) format.
> >>
> >>2. Similarly, it is the responsibility of the RADIUS proxy to
> >>    provide its realm table entries in the same ASCII format.
> >>
> >>3. As a result, the proxy does not need to do any conversions in the
> >>    manipulation of "decorated" NAIs. For example, a proxy can
> >>    convert [email-masked] ->
> >>    [email-masked] without having to "translate"
> >>    microsoft.com (assuming that this contained only appropriately
> >>    formatted ASCII characters).
> >>
> >>4. If a DNS lookup needs to be done (not required in RADIUS but
> >>    potentially needed in Diameter) then the proxy can use the
> >>    realm directly without conversion.
> >>
> >>5. Make the '!' related requirements outside the ABNF, because we
> >>    do not _require_ the '!' syntax to be used, '!' is still legal
> >>    to be used for any purpose between consenting parties.
> >>
> >>Here are the suggested text changes. In Section 2.7:
> >>
> >>OLD:
> >>In this case, the part before the (non-escaped) '!' MUST be a
> >>realm name as defined in the ABNF in Section 2.1. When
> >>receiving such an NAI, ...
> >>
> >>NEW:
> >>In this case, the part before the (non-escaped) '!' MUST be a
> >>realm name as defined in the ABNF in Section 2.1. This realm
> >>name is an "IDN-unaware domain name slot", just like the
> >>realm name after the "@" character; see Section 2.4 for
> >>details. When receiving such an NAI, ...
> >>
> >>And a pointer to a new draft revision:
> >>
> >>  http://www.arkko.com/publications/nai/naibis.txt
> >>  http://www.arkko.com/publications/nai/naibisdiff.html
> >>
> >>I'll submit this by monday, if there are further comments please
> >>make them before that.
> >>
> >>--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/>
> >>
> >>   =20
> >>
> >
> >
> > =20
> >
>=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: Sun, 17 Jul 2005 13:40:00 +0000
Date: Sun, 17 Jul 2005 06:39:02 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Jari Arkko <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: RFC 2486bis issue: "Decorated" NAIs and IDN support

Looks good to me.

On Sun, 17 Jul 2005, Jari Arkko wrote:

> Here are the additional text changes, draft URL in the quoted
> mail has also been updated.
>
> Section 2.5, add at the end:
>
>    The responsibility for the conversion of international domain names
>    to ASCII is left for the end-systems, such as network access clients
>    and AAA servers.  Similarly, we expect domain name comparisons,
>    matching, resolution, and AAA routing to be performed on the ASCII
>    versions of the international domain names.  This provides a
>    canonical representation, ensures that intermediate systems such as
>    AAA proxies do not need to perform translations, and can be expected
>    to work through systems that are unaware of international character
>    sets.
>
> Section 2.7, add at the end:
>
>    Note that the syntax described in this section is optional, and is
>    not a part of the ABNF.  The '!' character may appear in the username
>    portion of a NAI for other purposes as well, and in those cases the
>    rules outlined here do not apply; the interpretation of the username
>    is up to an agreement between the identified user and the realm given
>    after the '@' character.
>
> --Jari
>
> Bernard Aboba wrote:
>
> >Since this is a RADEXT WG draft, would it be possible to include the logic
> >below in the document itself?  If we don't, I can imagine having this same
> >conversation in the future.
> >
> >On Sat, 16 Jul 2005, Jari Arkko wrote:
> >
> >
> >
> >>Time is running out, so I'm going ahead with submitting
> >>a revision. Here's what I think we agreed:
> >>
> >>1. It is the responsibility of the peer to provide the NAI in
> >>    the correct (IDN-unaware ASCII) format.
> >>
> >>2. Similarly, it is the responsibility of the RADIUS proxy to
> >>    provide its realm table entries in the same ASCII format.
> >>
> >>3. As a result, the proxy does not need to do any conversions in the
> >>    manipulation of "decorated" NAIs. For example, a proxy can
> >>    convert [email-masked] ->
> >>    [email-masked] without having to "translate"
> >>    microsoft.com (assuming that this contained only appropriately
> >>    formatted ASCII characters).
> >>
> >>4. If a DNS lookup needs to be done (not required in RADIUS but
> >>    potentially needed in Diameter) then the proxy can use the
> >>    realm directly without conversion.
> >>
> >>5. Make the '!' related requirements outside the ABNF, because we
> >>    do not _require_ the '!' syntax to be used, '!' is still legal
> >>    to be used for any purpose between consenting parties.
> >>
> >>Here are the suggested text changes. In Section 2.7:
> >>
> >>OLD:
> >>In this case, the part before the (non-escaped) '!' MUST be a
> >>realm name as defined in the ABNF in Section 2.1. When
> >>receiving such an NAI, ...
> >>
> >>NEW:
> >>In this case, the part before the (non-escaped) '!' MUST be a
> >>realm name as defined in the ABNF in Section 2.1. This realm
> >>name is an "IDN-unaware domain name slot", just like the
> >>realm name after the "@" character; see Section 2.4 for
> >>details. When receiving such an NAI, ...
> >>
> >>And a pointer to a new draft revision:
> >>
> >>  http://www.arkko.com/publications/nai/naibis.txt
> >>  http://www.arkko.com/publications/nai/naibisdiff.html
> >>
> >>I'll submit this by monday, if there are further comments please
> >>make them before that.
> >>
> >>--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: Sun, 17 Jul 2005 07:16:11 +0000
Date: Sun, 17 Jul 2005 00:03:08 +0300
From: Jari Arkko <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC:  [email-masked],  [email-masked],  [email-masked],  [email-masked],  [email-masked],  [email-masked]
Subject: Re: RFC 2486bis issue: "Decorated" NAIs and IDN support

Here are the additional text changes, draft URL in the quoted
mail has also been updated.

Section 2.5, add at the end:

   The responsibility for the conversion of international domain names
   to ASCII is left for the end-systems, such as network access clients
   and AAA servers.  Similarly, we expect domain name comparisons,
   matching, resolution, and AAA routing to be performed on the ASCII
   versions of the international domain names.  This provides a
   canonical representation, ensures that intermediate systems such as
   AAA proxies do not need to perform translations, and can be expected
   to work through systems that are unaware of international character
   sets.

Section 2.7, add at the end:

   Note that the syntax described in this section is optional, and is
   not a part of the ABNF.  The '!' character may appear in the username
   portion of a NAI for other purposes as well, and in those cases the
   rules outlined here do not apply; the interpretation of the username
   is up to an agreement between the identified user and the realm given
   after the '@' character.

--Jari

Bernard Aboba wrote:

>Since this is a RADEXT WG draft, would it be possible to include the logic
>below in the document itself?  If we don't, I can imagine having this same
>conversation in the future.
>
>On Sat, 16 Jul 2005, Jari Arkko wrote:
>
>  
>
>>Time is running out, so I'm going ahead with submitting
>>a revision. Here's what I think we agreed:
>>
>>1. It is the responsibility of the peer to provide the NAI in
>>    the correct (IDN-unaware ASCII) format.
>>
>>2. Similarly, it is the responsibility of the RADIUS proxy to
>>    provide its realm table entries in the same ASCII format.
>>
>>3. As a result, the proxy does not need to do any conversions in the
>>    manipulation of "decorated" NAIs. For example, a proxy can
>>    convert [email-masked] ->
>>    [email-masked] without having to "translate"
>>    microsoft.com (assuming that this contained only appropriately
>>    formatted ASCII characters).
>>
>>4. If a DNS lookup needs to be done (not required in RADIUS but
>>    potentially needed in Diameter) then the proxy can use the
>>    realm directly without conversion.
>>
>>5. Make the '!' related requirements outside the ABNF, because we
>>    do not _require_ the '!' syntax to be used, '!' is still legal
>>    to be used for any purpose between consenting parties.
>>
>>Here are the suggested text changes. In Section 2.7:
>>
>>OLD:
>>In this case, the part before the (non-escaped) '!' MUST be a
>>realm name as defined in the ABNF in Section 2.1. When
>>receiving such an NAI, ...
>>
>>NEW:
>>In this case, the part before the (non-escaped) '!' MUST be a
>>realm name as defined in the ABNF in Section 2.1. This realm
>>name is an "IDN-unaware domain name slot", just like the
>>realm name after the "@" character; see Section 2.4 for
>>details. When receiving such an NAI, ...
>>
>>And a pointer to a new draft revision:
>>
>>  http://www.arkko.com/publications/nai/naibis.txt
>>  http://www.arkko.com/publications/nai/naibisdiff.html
>>
>>I'll submit this by monday, if there are further comments please
>>make them before that.
>>
>>--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: Sun, 17 Jul 2005 07:16:02 +0000
Date: Sat, 16 Jul 2005 19:29:40 +0300
From: Jari Arkko <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC:  [email-masked],  [email-masked],  [email-masked],  [email-masked],  [email-masked],  [email-masked]
Subject: Re: RFC 2486bis issue: "Decorated" NAIs and IDN support

Yes, I suppose so. I'll get back to you with some text.

--Jari

Bernard Aboba wrote:

>Since this is a RADEXT WG draft, would it be possible to include the logic
>below in the document itself?  If we don't, I can imagine having this same
>conversation in the future.
>
>On Sat, 16 Jul 2005, Jari Arkko wrote:
>
>  
>
>>Time is running out, so I'm going ahead with submitting
>>a revision. Here's what I think we agreed:
>>
>>1. It is the responsibility of the peer to provide the NAI in
>>    the correct (IDN-unaware ASCII) format.
>>
>>2. Similarly, it is the responsibility of the RADIUS proxy to
>>    provide its realm table entries in the same ASCII format.
>>
>>3. As a result, the proxy does not need to do any conversions in the
>>    manipulation of "decorated" NAIs. For example, a proxy can
>>    convert [email-masked] ->
>>    [email-masked] without having to "translate"
>>    microsoft.com (assuming that this contained only appropriately
>>    formatted ASCII characters).
>>
>>4. If a DNS lookup needs to be done (not required in RADIUS but
>>    potentially needed in Diameter) then the proxy can use the
>>    realm directly without conversion.
>>
>>5. Make the '!' related requirements outside the ABNF, because we
>>    do not _require_ the '!' syntax to be used, '!' is still legal
>>    to be used for any purpose between consenting parties.
>>
>>Here are the suggested text changes. In Section 2.7:
>>
>>OLD:
>>In this case, the part before the (non-escaped) '!' MUST be a
>>realm name as defined in the ABNF in Section 2.1. When
>>receiving such an NAI, ...
>>
>>NEW:
>>In this case, the part before the (non-escaped) '!' MUST be a
>>realm name as defined in the ABNF in Section 2.1. This realm
>>name is an "IDN-unaware domain name slot", just like the
>>realm name after the "@" character; see Section 2.4 for
>>details. When receiving such an NAI, ...
>>
>>And a pointer to a new draft revision:
>>
>>  http://www.arkko.com/publications/nai/naibis.txt
>>  http://www.arkko.com/publications/nai/naibisdiff.html
>>
>>I'll submit this by monday, if there are further comments please
>>make them before that.
>>
>>--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: Sat, 16 Jul 2005 14:11:59 +0000
Date: Sat, 16 Jul 2005 07:11:13 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Jari Arkko <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: RFC 2486bis issue: "Decorated" NAIs and IDN support

Since this is a RADEXT WG draft, would it be possible to include the logic
below in the document itself?  If we don't, I can imagine having this same
conversation in the future.

On Sat, 16 Jul 2005, Jari Arkko wrote:

> Time is running out, so I'm going ahead with submitting
> a revision. Here's what I think we agreed:
>
> 1. It is the responsibility of the peer to provide the NAI in
>     the correct (IDN-unaware ASCII) format.
>
> 2. Similarly, it is the responsibility of the RADIUS proxy to
>     provide its realm table entries in the same ASCII format.
>
> 3. As a result, the proxy does not need to do any conversions in the
>     manipulation of "decorated" NAIs. For example, a proxy can
>     convert [email-masked] ->
>     [email-masked] without having to "translate"
>     microsoft.com (assuming that this contained only appropriately
>     formatted ASCII characters).
>
> 4. If a DNS lookup needs to be done (not required in RADIUS but
>     potentially needed in Diameter) then the proxy can use the
>     realm directly without conversion.
>
> 5. Make the '!' related requirements outside the ABNF, because we
>     do not _require_ the '!' syntax to be used, '!' is still legal
>     to be used for any purpose between consenting parties.
>
> Here are the suggested text changes. In Section 2.7:
>
> OLD:
> In this case, the part before the (non-escaped) '!' MUST be a
> realm name as defined in the ABNF in Section 2.1. When
> receiving such an NAI, ...
>
> NEW:
> In this case, the part before the (non-escaped) '!' MUST be a
> realm name as defined in the ABNF in Section 2.1. This realm
> name is an "IDN-unaware domain name slot", just like the
> realm name after the "@" character; see Section 2.4 for
> details. When receiving such an NAI, ...
>
> And a pointer to a new draft revision:
>
>   http://www.arkko.com/publications/nai/naibis.txt
>   http://www.arkko.com/publications/nai/naibisdiff.html
>
> I'll submit this by monday, if there are further comments please
> make them before that.
>
> --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: Sat, 16 Jul 2005 09:49:09 +0000
Date: Sat, 16 Jul 2005 11:21:35 +0300
From: Jari Arkko <[email-masked]>
To: Jari Arkko <[email-masked]>
CC:  [email-masked],  [email-masked],  [email-masked],  [email-masked],  [email-masked],  [email-masked],  [email-masked]
Subject: Re: RFC 2486bis issue: "Decorated" NAIs and IDN support

Time is running out, so I'm going ahead with submitting
a revision. Here's what I think we agreed:

1. It is the responsibility of the peer to provide the NAI in
    the correct (IDN-unaware ASCII) format.

2. Similarly, it is the responsibility of the RADIUS proxy to
    provide its realm table entries in the same ASCII format.

3. As a result, the proxy does not need to do any conversions in the
    manipulation of "decorated" NAIs. For example, a proxy can
    convert [email-masked] ->
    [email-masked] without having to "translate"
    microsoft.com (assuming that this contained only appropriately
    formatted ASCII characters).

4. If a DNS lookup needs to be done (not required in RADIUS but
    potentially needed in Diameter) then the proxy can use the
    realm directly without conversion.

5. Make the '!' related requirements outside the ABNF, because we
    do not _require_ the '!' syntax to be used, '!' is still legal
    to be used for any purpose between consenting parties.

Here are the suggested text changes. In Section 2.7:

OLD:
In this case, the part before the (non-escaped) '!' MUST be a
realm name as defined in the ABNF in Section 2.1. When
receiving such an NAI, ...

NEW:
In this case, the part before the (non-escaped) '!' MUST be a
realm name as defined in the ABNF in Section 2.1. This realm
name is an "IDN-unaware domain name slot", just like the
realm name after the "@" character; see Section 2.4 for
details. When receiving such an NAI, ...

And a pointer to a new draft revision:

  http://www.arkko.com/publications/nai/naibis.txt
  http://www.arkko.com/publications/nai/naibisdiff.html

I'll submit this by monday, if there are further comments please
make them before that.

--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: Fri, 15 Jul 2005 02:07:27 +0000
Content-class: urn:content-classes:message
Subject: RE: Fixes Issue: Interim-Accounting-Interval and Local Configuration
Date: Fri, 15 Jul 2005 07:36:48 +0530
From: "Nagi Reddy Jonnala \(njonnala\)" <[email-masked]>
To: "Murtaza Chiba \(mchiba\)" <[email-masked]>, "Barney Wolff" <[email-masked]>
Cc: "Bernard Aboba" <[email-masked]>, <[email-masked]>

This is really a valid question that one comes across many times and I
also support Bernard's view point here. I would like to add the below as
well.

RFC-2869 text:

"It is also possible to statically configure an interim value on the
   NAS itself. Note that a locally configured value on the NAS MUST
   override the value found in an Access-Accept.

   This scheme does not break backward interoperability since a RADIUS
   server not supporting this extension will simply not add the new
   Attribute. NASes not supporting this extension will ignore the
   Attribute."

I'm not sure if the wording "NAS MUST override the value found in
Access-Accept" exists in the view of not to break backward=20
Compatibility.

I don't think there would be any backward compatibility issues
if the NAS honors the Radius server interim interval request
(assuming that it can honor based on some locally configured
value like minimum Interim interval).

IMO, it is worth documenting it somewhere.

Regards
Nagi.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Murtaza Chiba (mchiba)
Sent: Friday, July 15, 2005 1:53 AM
To: Barney Wolff
Cc: Bernard Aboba; [email-masked]
Subject: Re: Fixes Issue: Interim-Accounting-Interval and Local
Configuration

Barney Wolff wrote:
> On Thu, Jul 14, 2005 at 10:05:32AM -0700, Bernard Aboba wrote:
>=20
>>The Interim Accounting Interval is often set in order to ensure=20
>>against loss of income by billing systems.  So I can understand why=20
>>there is concern if an Interim-Accounting-Interval attribute sent by a

>>RADIUS server would be ignored by the NAS.
>>
>>Although I do not recall the conversations that lead to this paragraph

>>being inserted, I think the concern may relate to inappropriately=20
>>small values being sent by a RADIUS server.  For example, if the=20
>>implementation has a setting for "minimum Interim-Accounting-Interval"

>>then I would say that this should not be overridden by a smaller=20
>>value, but could be overridden by a larger one.
>=20
>=20
> I think the issue is whose policy shall apply, when the RADIUS server=20
> and NAS are under different administrative control.  Setting the value

> in the NAS is the equivalent of overriding whatever value is set by=20
> the server in the proxy that (presumably) should exist between the NAS

> and the server in this case.
>=20

Thats an interesting point.  In wholesale environments sometimes the
wholesaler wants to control specific config bits such as compression,
for instance.  For compression it would be undesireable for a retailer
to turn it on for users as it significantly degrades the performance and
hence would affect subscribers for other retailers as well.

In this case too a smaller interim value would presumably chew up more
resources, so I agree with Bernard that retailers should be able to
change the interval time on a per user basis as long as they are not
increasing the frequency of updates beyond a configured threshold.

Murtaza

>=20
>>However, if the nature of the implementation setting is "use value X=20
>>by default, but allow the RADIUS server to override it" I don't=20
>>understand why that should be prohibited.
>=20
>=20
> One can always speculate on why values would be configured directly in

> the NAS if the proxy is under the same administration.  Perhaps the=20
> thinking was that some NASes may be intelligent enough to pick the=20
> right server based on NAI or other info without an intervening proxy.

> In that case configuration of values on the NAS is the equivalent of=20
> doing so in a virtual proxy, and, since a proxy can always override=20
> attribute values, the NAS settings win.
>=20
> A definite choice, even if "wrong", is probably better than=20
> uncertainty in cases like this.
>=20
> Regards,
> Barney
>=20
> --
> to unsubscribe send a message to [email-masked] with=20
> 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: Thu, 14 Jul 2005 20:56:18 +0000
Date: Thu, 14 Jul 2005 13:55:59 -0700 (PDT)
From: Saikrishnan <[email-masked]>
To: Bikramjit Singh <[email-masked]>
cc: "[email-masked]'" <[email-masked]>, "'Barney Wolff'" <[email-masked]>, "'Bernard Aboba'" <[email-masked]>
Subject: RE: Fixes Issue: Interim-Accounting-Interval and Local Configurat ion

Thanks Bik, Barney and Bernard for the responses.

I am not at all underestimating the reasons for establishing
a policy (such as if the server gives a smaller period than
the one configured in the NAS then use the one from NAS etc.,)
but the original point I raised in my mail to Bernard was that
such decisions should be left to configurations on the NAS (such
as IOS CLI for Cisco and similarly for other vendors) and we should
not preclude such business policies by MUSTing it out in the RFC.

Thanks
sai.

On Thu, 14 Jul 2005, Bikramjit Singh wrote:

> Argument can be made both ways, but technically NAS is not a proxy. A NAS
> defers to the server on almost every aspect starting from authentication to
> changing of username in accounting packets to a lot of things.
>
> A NAS is asked to grant access to the user by the server according to the
> terms and conditions specified by the server in form of attributes. So
> unless there is a very concrete case for a NAS overriding the value of an
> attribute specified by the server, it should adhere and use the values of
> attributes specified by the server.
>
> Thanks
>
> -Bik
>
> ------------------------------------
> Nomadix
> Bikramjit Singh
> Technical Project Manager
> tel: 818-575-2518
> fax: 818-597-1502
> mobile: 818-613-6998
> www.nomadix.com
> ------------------------------------
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Barney Wolff
> Sent: Thursday, July 14, 2005 10:35 AM
> To: Bernard Aboba
> Cc: [email-masked]
> Subject: Re: Fixes Issue: Interim-Accounting-Interval and Local
> Configuration
>
> On Thu, Jul 14, 2005 at 10:05:32AM -0700, Bernard Aboba wrote:
> >
> > The Interim Accounting Interval is often set in order to ensure against
> > loss of income by billing systems.  So I can understand why there is
> > concern if an Interim-Accounting-Interval attribute sent by a RADIUS
> > server would be ignored by the NAS.
> >
> > Although I do not recall the conversations that lead to this paragraph
> > being inserted, I think the concern may relate to inappropriately small
> > values being sent by a RADIUS server.  For example, if the implementation
> > has a setting for "minimum Interim-Accounting-Interval" then I would say
> > that this should not be overridden by a smaller value, but could be
> > overridden by a larger one.
>
> I think the issue is whose policy shall apply, when the RADIUS server
> and NAS are under different administrative control.  Setting the value
> in the NAS is the equivalent of overriding whatever value is set by
> the server in the proxy that (presumably) should exist between the NAS
> and the server in this case.
>
> > However, if the nature of the implementation setting is "use value X by
> > default, but allow the RADIUS server to override it" I don't understand
> > why that should be prohibited.
>
> One can always speculate on why values would be configured directly in
> the NAS if the proxy is under the same administration.  Perhaps the
> thinking was that some NASes may be intelligent enough to pick the right
> server based on NAI or other info without an intervening proxy.  In that
> case configuration of values on the NAS is the equivalent of doing so
> in a virtual proxy, and, since a proxy can always override attribute
> values, the NAS settings win.
>
> A definite choice, even if "wrong", is probably better than uncertainty
> in cases like this.
>
> Regards,
> Barney
>
------------------------------------
>
> From: Saikrishnan [mailto:[email-masked]]
> Sent: Thu 7/14/2005 9:47 AM
> To: [email-masked]; [email-masked]; Glen Zorn
> Cc: [email-masked]; Bernard Aboba
> Subject: RFC 2869 and draft-aboba-radext-fixes-00.txt

> Hi,
>
> In section 2.1 of RFC 2869, it is mentioned that the
> interim-accounting-interval
> coming from the RADIUS server is superceded by the local config on the
> NAS.
>
> Pl. find below the snippet.
>
> -----
>
>  2.1.  RADIUS support for Interim Accounting Updates
>
>    When a user is authenticated, a RADIUS server issues an
> Access-Accept
>    in response to a successful Access-Request. If the server wishes to
>    receive interim accounting messages for the given user it must
>    include the Acct-Interim-Interval RADIUS attribute in the message,
>    which indicates the interval in seconds between interim messages.
>
>    It is also possible to statically configure an interim value on the
>    NAS itself. Note that a locally configured value on the NAS MUST
>    override the value found in an Access-Accept.
>
> ----
>
> But in terms of priority it makes more sense for the finer granularity
> config overriding the global config. For instance, if you
> want to apply
> an umbrella policy that all the sessions are done periodic
> accounting every
> 30 mins but for Jane's session, we need to do periodic
> accounting every
> 45 mins, the only way for provisioning this is by adding 45' to Jane's
> user profile.
>
> But the RFC MUSTs it out. I am copying the authors for clarification.
>
> Please note that in all the other attributes in Cisco IOS,
> the PER-USER
> attribute (the attribute defined in the user profile)
> overrides what is
> configured globally on the box. At minimum, this should be left for
> implementation. Pl. let me know if I am missing something.
>
> Thanks and Warm regards
> sai.

--
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, 14 Jul 2005 20:23:56 +0000
Date: Thu, 14 Jul 2005 13:23:01 -0700
From: Murtaza Chiba <[email-masked]>
To: Barney Wolff <[email-masked]>
CC: Bernard Aboba <[email-masked]>, [email-masked]
Subject: Re: Fixes Issue: Interim-Accounting-Interval and Local Configuration

Barney Wolff wrote:
> On Thu, Jul 14, 2005 at 10:05:32AM -0700, Bernard Aboba wrote:
> 
>>The Interim Accounting Interval is often set in order to ensure against
>>loss of income by billing systems.  So I can understand why there is
>>concern if an Interim-Accounting-Interval attribute sent by a RADIUS
>>server would be ignored by the NAS.
>>
>>Although I do not recall the conversations that lead to this paragraph
>>being inserted, I think the concern may relate to inappropriately small
>>values being sent by a RADIUS server.  For example, if the implementation
>>has a setting for "minimum Interim-Accounting-Interval" then I would say
>>that this should not be overridden by a smaller value, but could be
>>overridden by a larger one.
> 
> 
> I think the issue is whose policy shall apply, when the RADIUS server
> and NAS are under different administrative control.  Setting the value
> in the NAS is the equivalent of overriding whatever value is set by
> the server in the proxy that (presumably) should exist between the NAS
> and the server in this case.
> 

Thats an interesting point.  In wholesale environments sometimes the 
wholesaler wants to control specific config bits such as compression, 
for instance.  For compression it would be undesireable for a retailer 
to turn it on for users as it significantly degrades the performance and 
hence would affect subscribers for other retailers as well.

In this case too a smaller interim value would presumably chew up more 
resources, so I agree with Bernard that retailers should be able to 
change the interval time on a per user basis as long as they are not 
increasing the frequency of updates beyond a configured threshold.

Murtaza

> 
>>However, if the nature of the implementation setting is "use value X by
>>default, but allow the RADIUS server to override it" I don't understand
>>why that should be prohibited.
> 
> 
> One can always speculate on why values would be configured directly in
> the NAS if the proxy is under the same administration.  Perhaps the
> thinking was that some NASes may be intelligent enough to pick the right
> server based on NAI or other info without an intervening proxy.  In that
> case configuration of values on the NAS is the equivalent of doing so
> in a virtual proxy, and, since a proxy can always override attribute
> values, the NAS settings win.
> 
> A definite choice, even if "wrong", is probably better than uncertainty
> in cases like this.
> 
> Regards,
> Barney
> 
> --
> 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, 14 Jul 2005 20:02:42 +0000
From: Bikramjit Singh <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: 'Barney Wolff' <[email-masked]>, 'Bernard Aboba' <[email-masked]>
Subject: RE: Fixes Issue: Interim-Accounting-Interval and Local Configurat ion
Date: Thu, 14 Jul 2005 13:02:31 -0700

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C588AE.F7FE4390
Content-Type: text/plain

Argument can be made both ways, but technically NAS is not a proxy. A NAS
defers to the server on almost every aspect starting from authentication to
changing of username in accounting packets to a lot of things. 

A NAS is asked to grant access to the user by the server according to the
terms and conditions specified by the server in form of attributes. So
unless there is a very concrete case for a NAS overriding the value of an
attribute specified by the server, it should adhere and use the values of
attributes specified by the server. 

Thanks

-Bik

------------------------------------
Nomadix
Bikramjit Singh
Technical Project Manager
tel: 818-575-2518
fax: 818-597-1502
mobile: 818-613-6998
www.nomadix.com
------------------------------------

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Barney Wolff
Sent: Thursday, July 14, 2005 10:35 AM
To: Bernard Aboba
Cc: [email-masked]
Subject: Re: Fixes Issue: Interim-Accounting-Interval and Local
Configuration

On Thu, Jul 14, 2005 at 10:05:32AM -0700, Bernard Aboba wrote:
> 
> The Interim Accounting Interval is often set in order to ensure against
> loss of income by billing systems.  So I can understand why there is
> concern if an Interim-Accounting-Interval attribute sent by a RADIUS
> server would be ignored by the NAS.
> 
> Although I do not recall the conversations that lead to this paragraph
> being inserted, I think the concern may relate to inappropriately small
> values being sent by a RADIUS server.  For example, if the implementation
> has a setting for "minimum Interim-Accounting-Interval" then I would say
> that this should not be overridden by a smaller value, but could be
> overridden by a larger one.

I think the issue is whose policy shall apply, when the RADIUS server
and NAS are under different administrative control.  Setting the value
in the NAS is the equivalent of overriding whatever value is set by
the server in the proxy that (presumably) should exist between the NAS
and the server in this case.

> However, if the nature of the implementation setting is "use value X by
> default, but allow the RADIUS server to override it" I don't understand
> why that should be prohibited.

One can always speculate on why values would be configured directly in
the NAS if the proxy is under the same administration.  Perhaps the
thinking was that some NASes may be intelligent enough to pick the right
server based on NAI or other info without an intervening proxy.  In that
case configuration of values on the NAS is the equivalent of doing so
in a virtual proxy, and, since a proxy can always override attribute
values, the NAS settings win.

A definite choice, even if "wrong", is probably better than uncertainty
in cases like this.

Regards,
Barney

--
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_01C588AE.F7FE4390
Content-Type: text/html
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=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2657.73">
<TITLE>RE: Fixes Issue: Interim-Accounting-Interval and Local =
Configuration</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Argument can be made both ways, but technically NAS =
is not a proxy. A NAS defers to the server on almost every aspect =
starting from authentication to changing of username in accounting =
packets to a lot of things. </FONT></P>

<P><FONT SIZE=3D2>A NAS is asked to grant access to the user by the =
server according to the terms and conditions specified by the server in =
form of attributes. So unless there is a very concrete case for a NAS =
overriding the value of an attribute specified by the server, it should =
adhere and use the values of attributes specified by the server. =
</FONT></P>

<P><FONT SIZE=3D2>Thanks</FONT>
</P>

<P><FONT SIZE=3D2>-Bik</FONT>
</P>

<P><FONT SIZE=3D2>------------------------------------</FONT>
<BR><FONT SIZE=3D2>Nomadix</FONT>
<BR><FONT SIZE=3D2>Bikramjit Singh</FONT>
<BR><FONT SIZE=3D2>Technical Project Manager</FONT>
<BR><FONT SIZE=3D2>tel: 818-575-2518</FONT>
<BR><FONT SIZE=3D2>fax: 818-597-1502</FONT>
<BR><FONT SIZE=3D2>mobile: 818-613-6998</FONT>
<BR><FONT SIZE=3D2>www.nomadix.com</FONT>
<BR><FONT SIZE=3D2>------------------------------------</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: [email-masked] [<A =
HREF=3D"mailto:[email-masked]">mailto:owner-radiusext@ops.=
ietf.org</A>] On Behalf Of Barney Wolff</FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, July 14, 2005 10:35 AM</FONT>
<BR><FONT SIZE=3D2>To: Bernard Aboba</FONT>
<BR><FONT SIZE=3D2>Cc: [email-masked]</FONT>
<BR><FONT SIZE=3D2>Subject: Re: Fixes Issue: =
Interim-Accounting-Interval and Local Configuration</FONT>
</P>

<P><FONT SIZE=3D2>On Thu, Jul 14, 2005 at 10:05:32AM -0700, Bernard =
Aboba wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; The Interim Accounting Interval is often set in =
order to ensure against</FONT>
<BR><FONT SIZE=3D2>&gt; loss of income by billing systems.&nbsp; So I =
can understand why there is</FONT>
<BR><FONT SIZE=3D2>&gt; concern if an Interim-Accounting-Interval =
attribute sent by a RADIUS</FONT>
<BR><FONT SIZE=3D2>&gt; server would be ignored by the NAS.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Although I do not recall the conversations that =
lead to this paragraph</FONT>
<BR><FONT SIZE=3D2>&gt; being inserted, I think the concern may relate =
to inappropriately small</FONT>
<BR><FONT SIZE=3D2>&gt; values being sent by a RADIUS server.&nbsp; For =
example, if the implementation</FONT>
<BR><FONT SIZE=3D2>&gt; has a setting for &quot;minimum =
Interim-Accounting-Interval&quot; then I would say</FONT>
<BR><FONT SIZE=3D2>&gt; that this should not be overridden by a smaller =
value, but could be</FONT>
<BR><FONT SIZE=3D2>&gt; overridden by a larger one.</FONT>
</P>

<P><FONT SIZE=3D2>I think the issue is whose policy shall apply, when =
the RADIUS server</FONT>
<BR><FONT SIZE=3D2>and NAS are under different administrative =
control.&nbsp; Setting the value</FONT>
<BR><FONT SIZE=3D2>in the NAS is the equivalent of overriding whatever =
value is set by</FONT>
<BR><FONT SIZE=3D2>the server in the proxy that (presumably) should =
exist between the NAS</FONT>
<BR><FONT SIZE=3D2>and the server in this case.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; However, if the nature of the implementation =
setting is &quot;use value X by</FONT>
<BR><FONT SIZE=3D2>&gt; default, but allow the RADIUS server to =
override it&quot; I don't understand</FONT>
<BR><FONT SIZE=3D2>&gt; why that should be prohibited.</FONT>
</P>

<P><FONT SIZE=3D2>One can always speculate on why values would be =
configured directly in</FONT>
<BR><FONT SIZE=3D2>the NAS if the proxy is under the same =
administration.&nbsp; Perhaps the</FONT>
<BR><FONT SIZE=3D2>thinking was that some NASes may be intelligent =
enough to pick the right</FONT>
<BR><FONT SIZE=3D2>server based on NAI or other info without an =
intervening proxy.&nbsp; In that</FONT>
<BR><FONT SIZE=3D2>case configuration of values on the NAS is the =
equivalent of doing so</FONT>
<BR><FONT SIZE=3D2>in a virtual proxy, and, since a proxy can always =
override attribute</FONT>
<BR><FONT SIZE=3D2>values, the NAS settings win.</FONT>
</P>

<P><FONT SIZE=3D2>A definite choice, even if &quot;wrong&quot;, is =
probably better than uncertainty</FONT>
<BR><FONT SIZE=3D2>in cases like this.</FONT>
</P>

<P><FONT SIZE=3D2>Regards,</FONT>
<BR><FONT SIZE=3D2>Barney</FONT>
</P>

<P><FONT SIZE=3D2>--</FONT>
<BR><FONT SIZE=3D2>to unsubscribe send a message to =
[email-masked] with</FONT>
<BR><FONT SIZE=3D2>the word 'unsubscribe' in a single line as the =
message text body.</FONT>
<BR><FONT SIZE=3D2>archive: &lt;<A =
HREF=3D"http://psg.com/lists/radiusext/" =
TARGET=3D"_blank">http://psg.com/lists/radiusext/</A>&gt;</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C588AE.F7FE4390--

--
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, 14 Jul 2005 17:35:14 +0000
Date: Thu, 14 Jul 2005 13:34:56 -0400
From: Barney Wolff <[email-masked]>
To: Bernard Aboba <[email-masked]>
Cc: [email-masked]
Subject: Re: Fixes Issue: Interim-Accounting-Interval and Local Configuration

On Thu, Jul 14, 2005 at 10:05:32AM -0700, Bernard Aboba wrote:
> 
> The Interim Accounting Interval is often set in order to ensure against
> loss of income by billing systems.  So I can understand why there is
> concern if an Interim-Accounting-Interval attribute sent by a RADIUS
> server would be ignored by the NAS.
> 
> Although I do not recall the conversations that lead to this paragraph
> being inserted, I think the concern may relate to inappropriately small
> values being sent by a RADIUS server.  For example, if the implementation
> has a setting for "minimum Interim-Accounting-Interval" then I would say
> that this should not be overridden by a smaller value, but could be
> overridden by a larger one.

I think the issue is whose policy shall apply, when the RADIUS server
and NAS are under different administrative control.  Setting the value
in the NAS is the equivalent of overriding whatever value is set by
the server in the proxy that (presumably) should exist between the NAS
and the server in this case.

> However, if the nature of the implementation setting is "use value X by
> default, but allow the RADIUS server to override it" I don't understand
> why that should be prohibited.

One can always speculate on why values would be configured directly in
the NAS if the proxy is under the same administration.  Perhaps the
thinking was that some NASes may be intelligent enough to pick the right
server based on NAI or other info without an intervening proxy.  In that
case configuration of values on the NAS is the equivalent of doing so
in a virtual proxy, and, since a proxy can always override attribute
values, the NAS settings win.

A definite choice, even if "wrong", is probably better than uncertainty
in cases like this.

Regards,
Barney

--
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, 14 Jul 2005 17:06:09 +0000
Date: Thu, 14 Jul 2005 10:05:32 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Fixes Issue: Interim-Accounting-Interval and Local Configuration

Sai --

The Interim Accounting Interval is often set in order to ensure against
loss of income by billing systems.  So I can understand why there is
concern if an Interim-Accounting-Interval attribute sent by a RADIUS
server would be ignored by the NAS.

Although I do not recall the conversations that lead to this paragraph
being inserted, I think the concern may relate to inappropriately small
values being sent by a RADIUS server.  For example, if the implementation
has a setting for "minimum Interim-Accounting-Interval" then I would say
that this should not be overridden by a smaller value, but could be
overridden by a larger one.

However, if the nature of the implementation setting is "use value X by
default, but allow the RADIUS server to override it" I don't understand
why that should be prohibited.

--------------------------------------------------------------------------------
From: Saikrishnan [mailto:[email-masked]]
Sent: Thu 7/14/2005 9:47 AM
To: [email-masked]; [email-masked]; Glen Zorn
Cc: [email-masked]; Bernard Aboba
Subject: RFC 2869 and draft-aboba-radext-fixes-00.txt

Hi,

In section 2.1 of RFC 2869, it is mentioned that the interim-accounting-interval
coming from the RADIUS server is superceded by the local config on the
NAS.

Pl. find below the snippet.

-----

 2.1.  RADIUS support for Interim Accounting Updates

   When a user is authenticated, a RADIUS server issues an Access-Accept
   in response to a successful Access-Request. If the server wishes to
   receive interim accounting messages for the given user it must
   include the Acct-Interim-Interval RADIUS attribute in the message,
   which indicates the interval in seconds between interim messages.

   It is also possible to statically configure an interim value on the
   NAS itself. Note that a locally configured value on the NAS MUST
   override the value found in an Access-Accept.

----

But in terms of priority it makes more sense for the finer granularity
config overriding the global config. For instance, if you want to apply
an umbrella policy that all the sessions are done periodic accounting every
30 mins but for Jane's session, we need to do periodic accounting every
45 mins, the only way for provisioning this is by adding 45' to Jane's
user profile.

But the RFC MUSTs it out. I am copying the authors for clarification.

Please note that in all the other attributes in Cisco IOS, the PER-USER
attribute (the attribute defined in the user profile) overrides what is
configured globally on the box. At minimum, this should be left for
implementation. Pl. let me know if I am missing something.

Thanks and Warm regards
sai.

--
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, 14 Jul 2005 12:46:58 +0000
Content-class: urn:content-classes:message
Subject: Issue: WGLC comments about draft-ietf-radext-ieee802-00
Date: Thu, 14 Jul 2005 13:15:40 +0300
From: <[email-masked]>
To: <[email-masked]>

WGLC comments about draft-ietf-radext-ieee802-00
Submitter name: Pasi Eronen
Submitter email address: [email-masked]
Date first submitted: July 14, 2005
Reference:=20
Document: draft-ietf-radext-ieee802-00
Comment type: T/E
Priority: 1
Section:=20
Rationale/Explanation of issue:

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)"

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?

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)

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

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"?

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=20
in a management interface... maybe something like 0x74/0x75
("t"/"u") or 0x31/0x32 ("1"/"2") would be easier?

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

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"?

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

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

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)

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

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

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, 14 Jul 2005 10:19:35 +0000
Content-class: urn:content-classes:message
Subject: Issue: WGLC comments about NAS/QoS-Filter-Rule
Date: Thu, 14 Jul 2005 13:19:02 +0300
From: <[email-masked]>
To: <[email-masked]>

WGLC comments about NAS/QoS-Filter-Rule
Submitter name: Pasi Eronen
Submitter email address: [email-masked]
Date first submitted: July 14, 2005
Reference:=20
Document: draft-ietf-radext-ieee802-00
Comment type: T/E
Priority: 1
Section:=20
Rationale/Explanation of issue:

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,=20
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=20
or HTTP rules.)

2) Or would using ABNF be of any help? Here's a first sketch=20
(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=20
a literal string )

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.

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.

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?)

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]"

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

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")

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

10) The document should explain why different types of rules must=20
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.

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

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

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

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: Wed, 13 Jul 2005 19:04:06 +0000
Content-class: urn:content-classes:message
Subject: RADEXT WG schedule for IETF-63
Date: Wed, 13 Jul 2005 15:02:27 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>
Cc: "Bernard Aboba" <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C587DD.6919DFDA
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

The initial meeting agenda for IETF-63 has been published.  The RADEXT
WG has been assigned a Wednesday morning slot.  In terms of making
travel arrangements, please be reminded that WG slots are sometimes
shuffled in later agenda versions to resolve various scheduling
conflicts.
=20
WEDNESDAY, August 3, 2005
1030-1230 Morning Session II
=20
OPS  radext    RADIUS Extensions WG
=20
WG agendas are due by July 25, so if you would like a time slot during
the RADEXT WG session, and have not already sent a message to the
chairs, this would be a good time to do so.  We will be posting a
proposed WG agenda soon.

=20

------_=_NextPart_001_01C587DD.6919DFDA
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
pre
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1><pre><font size=3D2 face=3D"Courier New"><span
style=3D'font-size:10.0pt'>The initial meeting agenda for IETF-63 has =
been published. &nbsp;The RADEXT WG has been assigned a Wednesday =
morning slot. &nbsp;In terms of making travel arrangements, please be =
reminded that WG slots are sometimes shuffled in later agenda versions =
to resolve various scheduling =
conflicts.<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre><fon=
t
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>WEDNESDAY, August 3, =
2005<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'>1030-1230 =
Morning Session II<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre><fon=
t
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'>OPS&nbsp; =
radext&nbsp;&nbsp;&nbsp; RADIUS Extensions =
WG<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre><fon=
t
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'>WG =
agendas are due by July 25, so if you would like a time slot during the =
RADEXT WG session, and have not already sent a message to the chairs, =
this would be a good time to do so. &nbsp;We will be posting a proposed =
WG agenda soon.<o:p></o:p></span></font></pre>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C587DD.6919DFDA--

--
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: Mon, 11 Jul 2005 23:49:47 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Subject: ISSUE with draft-ietf-radext-ieee802-00.txt 
Date: Mon, 11 Jul 2005 19:48:50 -0400
Message-Id: <[email-masked]>

Description of Issue: Clarification of Section 7 - Security considerations
Submitter name: Alan DeKok
Submitter email address: [email-masked]
Date first submitted: July 11, 2005
Document: http://www.drizzle.com/~aboba/RADEXT/draft-ietf-radext-ieee802-00.txt
Comment type: Technical
Priority: S
Section: 7.3
Rationale: The last sentence of section 7 has strong new requirements on RADIUS

  The last sentence of section 7 is also the last section of the
document, and says:

      In addition, the same RADIUS shared secret MUST NOT used for both 
      IEEE 802.1X authentication and PAP authentication. 

  It's a little surprising to have a requirement with such a large
impact as the last sentence in the document, with no further
discussion.

  This requirement means that it may be impossible for implementations
to call themselves "unconditionally compliant".  Since RADIUS servers
cannot control the authentication methods used by a NAS, there is no
way for an implementation to know if a particular shared secret is
used for IEEE 802.1X or PAP authentication.

  When a RADIUS server is proxying requests from one or more NASes to
a home server, it may not have a choice about how many shared secrets
it uses.  In order to satisfy the MUST in section 7.3, the proxying
server MUST send send packets from two different IP addresses.  This
configuration may not be possible in many deployments.

  In addition, 802.1X devices may pass through EAP for user
authentication, but also implement device administrator authentication
via RADIUS.  Implementors should be guided as to how to implement
administrator authentication without breaking the security of user
authentication.

Requested change:

  1. Change the MUST to a SHOULD.

  2. Add the following suggested text:

	Implementors are strongly cautioned to treat the preceding SHOULD
	as a MUST.  Issues with the RADIUS protocol prevent the above
	requirement from being a MUST in all deployments.

	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.

	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.

  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: Mon, 11 Jul 2005 10:10:04 +0000
Date: Mon, 11 Jul 2005 13:09:51 +0300
From: Jari Arkko <[email-masked]>
To:  [email-masked]
CC:  [email-masked],  [email-masked],  [email-masked],  [email-masked],  [email-masked],  [email-masked]
Subject: Re: RFC 2486bis issue: "Decorated" NAIs and IDN support

Yes, that's right. But what we really need is an instruction
that says "if you use the ! notation in the way described in
Section X, then you need to convert the realms first to IDN-unaware
ascii strings". It seems that this could be done with or without
explicit ABNF. Pasi argument below seems to call for making
this requirement outside the ABNF....

[email-masked] wrote:

>Actually, not including the realm!user@otherrealm in the ABNF 
>was intentional (and we discussed this in June 2004).
>
>The rationale was that using the "!" notation is not required.
>So, for instance, if some realm uses usernames that have "!" in 
>them (which is allowed by RFC 2486), that is still allowed by 
>2486bis. Since using this syntax is totally optional, it should
>not be hard-coded to the ABNF that applies to all NAIs.
>(And besides, making this change would not actually change 
>the set of strings that match the ABNF...)
>
>BR,
>Pasi
>
>  
>
>>-----Original Message-----
>>From: ext Bernard Aboba [mailto:[email-masked]]
>>Sent: Saturday, July 09, 2005 9:09 PM
>>To: Eronen Pasi (Nokia-NRC/Helsinki)
>>Cc: [email-masked]; [email-masked]; [email-masked];
>>[email-masked]; [email-masked]; Jari Arkko
>>Subject: RE: RFC 2486bis issue: "Decorated" NAIs and IDN support
>>
>>
>>The ABNF in Section 2.1 doesn't seem to take this into 
>>account, so I think
>>that a change may be needed there too.   For example, to 
>>allow NAIs such
>>as
>>
>>[email-masked]
>>
>>I think you need a rule like:
>>
>>   nai         =  username
>>   nai         =/ "@" realm
>>   nai         =/ *(realm "!") username "@" realm
>>
>>
>>
>>On Fri, 8 Jul 2005 [email-masked] wrote:
>>
>>    
>>
>>>I think the approach proposed below is a good one (or at
>>>least I don't see any better approach either).
>>>
>>>It also doesn't require much changes to 2486bis; we just need
>>>to mention that all realm names, both after "@" and before "!"
>>>(when that notation are used), are IDN-unaware domain name
>>>slots.
>>>
>>>Would this clarification to Section 2.7 be sufficient, or do
>>>we need more text?
>>>OLD:
>>>   In this case, the part before the (non-escaped) '!' MUST be a
>>>   realm name as defined in the ABNF in Section 2.1.  When
>>>   receiving such an NAI, ...
>>>NEW:
>>>   In this case, the part before the (non-escaped) '!' MUST be a
>>>   realm name as defined in the ABNF in Section 2.1.  This realm
>>>   name is an "IDN-unaware domain name slot", just like the
>>>   realm name after the "@" character; see Section 2.4 for
>>>   details.  When receiving such an NAI, ...
>>>
>>>Best regards,
>>>Pasi
>>>
>>>      
>>>
>>>>-----Original Message-----
>>>>From: Bernard Aboba
>>>>Sent: Sunday, July 03, 2005 11:52 PM
>>>>To: Paul Hoffman
>>>>Cc: [email-masked]; [email-masked]; [email-masked]
>>>>Subject: Re: RFC 2486bis issue: "Decorated" NAIs and IDN support
>>>>
>>>>
>>>>        
>>>>
>>>>>I am lost here. An IDN client (in this case, the UI where
>>>>>the user enters the NAI), is responsible for doing a
>>>>>Unicode-to-ASCII conversion. It becomes a valid FQDN right
>>>>>there. The only tricky part is that the UI has to look for
>>>>>DNS names amid the ! and @ characters.
>>>>>
>>>>>          
>>>>>
>>>>>>Can you look at the below thread and give us your feedback
>>>>>>on how we should think about this?
>>>>>>            
>>>>>>
>>>>>See above. The thread you passed bounced around among many
>>>>>proposals. Basically, something needs to find the domain names
>>>>>in the string that the user entered and convert them to ASCII.
>>>>>And domain names (even in the middle of the other gunk in the
>>>>>NAI) being displayed should be converted back to UTF-8.
>>>>>          
>>>>>
>>>>OK.  So if I understand this correctly then:
>>>>
>>>>a. It is the responsibility of the peer to provide the NAI in
>>>>the correct (ASCII) format.
>>>>
>>>>b. Similarly, it is the responsbility of the RADIUS proxy to
>>>>provide its realm table entries in the same ASCII format.
>>>>
>>>>c. Assuming a) and b) are done, then the proxy does not need
>>>>to do any conversions in the manipulation of "decorated" NAIs.
>>>>For example, it can convert [email-masked] ->
>>>>[email-masked] without having to "translate"
>>>>microsoft.com (assuming that this contained only
>>>>appropriately formatted ASCII characters).
>>>>
>>>>If a DNS lookup needs to be done (not required in RADIUS but
>>>>potentially needed in Diameter) then the proxy can use the realm
>>>>directly without conversion.
>>>>
>>>>Is this 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: Mon, 11 Jul 2005 09:00:44 +0000
Content-class: urn:content-classes:message
Subject: RE: RFC 2486bis issue: "Decorated" NAIs and IDN support
Date: Mon, 11 Jul 2005 11:59:43 +0300
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>

Actually, not including the realm!user@otherrealm in the ABNF=20
was intentional (and we discussed this in June 2004).

The rationale was that using the "!" notation is not required.
So, for instance, if some realm uses usernames that have "!" in=20
them (which is allowed by RFC 2486), that is still allowed by=20
2486bis. Since using this syntax is totally optional, it should
not be hard-coded to the ABNF that applies to all NAIs.
(And besides, making this change would not actually change=20
the set of strings that match the ABNF...)

BR,
Pasi

> -----Original Message-----
> From: ext Bernard Aboba [mailto:[email-masked]]
> Sent: Saturday, July 09, 2005 9:09 PM
> To: Eronen Pasi (Nokia-NRC/Helsinki)
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; Jari Arkko
> Subject: RE: RFC 2486bis issue: "Decorated" NAIs and IDN support
>=20
>=20
> The ABNF in Section 2.1 doesn't seem to take this into=20
> account, so I think
> that a change may be needed there too.   For example, to=20
> allow NAIs such
> as
>=20
> [email-masked]
>=20
> I think you need a rule like:
>=20
>    nai         =3D  username
>    nai         =3D/ "@" realm
>    nai         =3D/ *(realm "!") username "@" realm
>=20
>=20
>=20
> On Fri, 8 Jul 2005 [email-masked] wrote:
>=20
> >
> > I think the approach proposed below is a good one (or at
> > least I don't see any better approach either).
> >
> > It also doesn't require much changes to 2486bis; we just need
> > to mention that all realm names, both after "@" and before "!"
> > (when that notation are used), are IDN-unaware domain name
> > slots.
> >
> > Would this clarification to Section 2.7 be sufficient, or do
> > we need more text?
> > OLD:
> >    In this case, the part before the (non-escaped) '!' MUST be a
> >    realm name as defined in the ABNF in Section 2.1.  When
> >    receiving such an NAI, ...
> > NEW:
> >    In this case, the part before the (non-escaped) '!' MUST be a
> >    realm name as defined in the ABNF in Section 2.1.  This realm
> >    name is an "IDN-unaware domain name slot", just like the
> >    realm name after the "@" character; see Section 2.4 for
> >    details.  When receiving such an NAI, ...
> >
> > Best regards,
> > Pasi
> >
> > > -----Original Message-----
> > > From: Bernard Aboba
> > > Sent: Sunday, July 03, 2005 11:52 PM
> > > To: Paul Hoffman
> > > Cc: [email-masked]; [email-masked]; [email-masked]
> > > Subject: Re: RFC 2486bis issue: "Decorated" NAIs and IDN support
> > >
> > >
> > > > I am lost here. An IDN client (in this case, the UI where
> > > > the user enters the NAI), is responsible for doing a
> > > > Unicode-to-ASCII conversion. It becomes a valid FQDN right
> > > > there. The only tricky part is that the UI has to look for
> > > > DNS names amid the ! and @ characters.
> > > >
> > > > >Can you look at the below thread and give us your feedback
> > > > >on how we should think about this?
> > > >
> > > > See above. The thread you passed bounced around among many
> > > > proposals. Basically, something needs to find the domain names
> > > > in the string that the user entered and convert them to ASCII.
> > > > And domain names (even in the middle of the other gunk in the
> > > > NAI) being displayed should be converted back to UTF-8.
> > >
> > > OK.  So if I understand this correctly then:
> > >
> > > a. It is the responsibility of the peer to provide the NAI in
> > > the correct (ASCII) format.
> > >
> > > b. Similarly, it is the responsbility of the RADIUS proxy to
> > > provide its realm table entries in the same ASCII format.
> > >
> > > c. Assuming a) and b) are done, then the proxy does not need
> > > to do any conversions in the manipulation of "decorated" NAIs.
> > > For example, it can convert [email-masked] ->
> > > [email-masked] without having to "translate"
> > > microsoft.com (assuming that this contained only
> > > appropriately formatted ASCII characters).
> > >
> > > If a DNS lookup needs to be done (not required in RADIUS but
> > > potentially needed in Diameter) then the proxy can use the realm
> > > directly without conversion.
> > >
> > > Is this right?
> >
>=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, 11 Jul 2005 03:53:23 +0000
Content-class: urn:content-classes:message
Subject: RE: RFC 2486bis issue: "Decorated" NAIs and IDN support
Date: Mon, 11 Jul 2005 06:52:43 +0300
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>

Bernard,

This seems to work.

John

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of ext Bernard Aboba
> Sent: 09 July, 2005 21:09
> To: Eronen Pasi (Nokia-NRC/Helsinki)
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; Jari Arkko
> Subject: RE: RFC 2486bis issue: "Decorated" NAIs and IDN support
>=20
>=20
> The ABNF in Section 2.1 doesn't seem to take this into=20
> account, so I think
> that a change may be needed there too.   For example, to=20
> allow NAIs such
> as
>=20
> [email-masked]
>=20
> I think you need a rule like:
>=20
>    nai         =3D  username
>    nai         =3D/ "@" realm
>    nai         =3D/ *(realm "!") username "@" realm
>=20
>=20
>=20
> On Fri, 8 Jul 2005 [email-masked] wrote:
>=20
> >
> > I think the approach proposed below is a good one (or at
> > least I don't see any better approach either).
> >
> > It also doesn't require much changes to 2486bis; we just need
> > to mention that all realm names, both after "@" and before "!"
> > (when that notation are used), are IDN-unaware domain name
> > slots.
> >
> > Would this clarification to Section 2.7 be sufficient, or do
> > we need more text?
> > OLD:
> >    In this case, the part before the (non-escaped) '!' MUST be a
> >    realm name as defined in the ABNF in Section 2.1.  When
> >    receiving such an NAI, ...
> > NEW:
> >    In this case, the part before the (non-escaped) '!' MUST be a
> >    realm name as defined in the ABNF in Section 2.1.  This realm
> >    name is an "IDN-unaware domain name slot", just like the
> >    realm name after the "@" character; see Section 2.4 for
> >    details.  When receiving such an NAI, ...
> >
> > Best regards,
> > Pasi
> >
> > > -----Original Message-----
> > > From: Bernard Aboba
> > > Sent: Sunday, July 03, 2005 11:52 PM
> > > To: Paul Hoffman
> > > Cc: [email-masked]; [email-masked]; [email-masked]
> > > Subject: Re: RFC 2486bis issue: "Decorated" NAIs and IDN support
> > >
> > >
> > > > I am lost here. An IDN client (in this case, the UI where
> > > > the user enters the NAI), is responsible for doing a
> > > > Unicode-to-ASCII conversion. It becomes a valid FQDN right
> > > > there. The only tricky part is that the UI has to look for
> > > > DNS names amid the ! and @ characters.
> > > >
> > > > >Can you look at the below thread and give us your feedback
> > > > >on how we should think about this?
> > > >
> > > > See above. The thread you passed bounced around among many
> > > > proposals. Basically, something needs to find the domain names
> > > > in the string that the user entered and convert them to ASCII.
> > > > And domain names (even in the middle of the other gunk in the
> > > > NAI) being displayed should be converted back to UTF-8.
> > >
> > > OK.  So if I understand this correctly then:
> > >
> > > a. It is the responsibility of the peer to provide the NAI in
> > > the correct (ASCII) format.
> > >
> > > b. Similarly, it is the responsbility of the RADIUS proxy to
> > > provide its realm table entries in the same ASCII format.
> > >
> > > c. Assuming a) and b) are done, then the proxy does not need
> > > to do any conversions in the manipulation of "decorated" NAIs.
> > > For example, it can convert [email-masked] ->
> > > [email-masked] without having to "translate"
> > > microsoft.com (assuming that this contained only
> > > appropriately formatted ASCII characters).
> > >
> > > If a DNS lookup needs to be done (not required in RADIUS but
> > > potentially needed in Diameter) then the proxy can use the realm
> > > directly without conversion.
> > >
> > > Is this right?
> >
>=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, 11 Jul 2005 03:36:03 +0000
Date: Sun, 10 Jul 2005 20:35:09 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: RADEXT WG last call on draft-ietf-radext-ieee802-00.txt

This is an announcement of RADEXT WG last call on "VLAN, Priority, and
Filtering Attributes" prior to sending this document to the IESG for
consideration as a Proposed Standard. The document will be available for
inspection here:
http://www.ietf.org/internet-drafts/draft-ietf-radext-ieee802-00.txt

Until it arrives on the archive, it will be available at:
http://www.drizzle.com/~aboba/RADEXT/draft-ietf-radext-ieee802-00.txt

RADEXT WG last call will last until August 10, 2005. Please send comments
to the RADEXT WG mailing list in the format described on the RADEXT 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: Sun, 10 Jul 2005 15:52:11 +0000
Date: Sun, 10 Jul 2005 18:51:42 +0300
From: Jari Arkko <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC:  [email-masked],  [email-masked],  [email-masked],  [email-masked],  [email-masked],  [email-masked]
Subject: Re: RFC 2486bis issue: "Decorated" NAIs and IDN support

This would work for me. --Jari

Bernard Aboba wrote:

>The ABNF in Section 2.1 doesn't seem to take this into account, so I think
>that a change may be needed there too.   For example, to allow NAIs such
>as
>
>[email-masked]
>
>I think you need a rule like:
>
>   nai         =  username
>   nai         =/ "@" realm
>   nai         =/ *(realm "!") username "@" realm
>
>
>
>On Fri, 8 Jul 2005 [email-masked] wrote:
>
>  
>
>>I think the approach proposed below is a good one (or at
>>least I don't see any better approach either).
>>
>>It also doesn't require much changes to 2486bis; we just need
>>to mention that all realm names, both after "@" and before "!"
>>(when that notation are used), are IDN-unaware domain name
>>slots.
>>
>>Would this clarification to Section 2.7 be sufficient, or do
>>we need more text?
>>OLD:
>>   In this case, the part before the (non-escaped) '!' MUST be a
>>   realm name as defined in the ABNF in Section 2.1.  When
>>   receiving such an NAI, ...
>>NEW:
>>   In this case, the part before the (non-escaped) '!' MUST be a
>>   realm name as defined in the ABNF in Section 2.1.  This realm
>>   name is an "IDN-unaware domain name slot", just like the
>>   realm name after the "@" character; see Section 2.4 for
>>   details.  When receiving such an NAI, ...
>>
>>Best regards,
>>Pasi
>>
>>    
>>
>>>-----Original Message-----
>>>From: Bernard Aboba
>>>Sent: Sunday, July 03, 2005 11:52 PM
>>>To: Paul Hoffman
>>>Cc: [email-masked]; [email-masked]; [email-masked]
>>>Subject: Re: RFC 2486bis issue: "Decorated" NAIs and IDN support
>>>
>>>
>>>      
>>>
>>>>I am lost here. An IDN client (in this case, the UI where
>>>>the user enters the NAI), is responsible for doing a
>>>>Unicode-to-ASCII conversion. It becomes a valid FQDN right
>>>>there. The only tricky part is that the UI has to look for
>>>>DNS names amid the ! and @ characters.
>>>>
>>>>        
>>>>
>>>>>Can you look at the below thread and give us your feedback
>>>>>on how we should think about this?
>>>>>          
>>>>>
>>>>See above. The thread you passed bounced around among many
>>>>proposals. Basically, something needs to find the domain names
>>>>in the string that the user entered and convert them to ASCII.
>>>>And domain names (even in the middle of the other gunk in the
>>>>NAI) being displayed should be converted back to UTF-8.
>>>>        
>>>>
>>>OK.  So if I understand this correctly then:
>>>
>>>a. It is the responsibility of the peer to provide the NAI in
>>>the correct (ASCII) format.
>>>
>>>b. Similarly, it is the responsbility of the RADIUS proxy to
>>>provide its realm table entries in the same ASCII format.
>>>
>>>c. Assuming a) and b) are done, then the proxy does not need
>>>to do any conversions in the manipulation of "decorated" NAIs.
>>>For example, it can convert [email-masked] ->
>>>[email-masked] without having to "translate"
>>>microsoft.com (assuming that this contained only
>>>appropriately formatted ASCII characters).
>>>
>>>If a DNS lookup needs to be done (not required in RADIUS but
>>>potentially needed in Diameter) then the proxy can use the realm
>>>directly without conversion.
>>>
>>>Is this 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: Sat, 09 Jul 2005 18:10:17 +0000
Date: Sat, 9 Jul 2005 11:09:22 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], Jari Arkko <[email-masked]>
Subject: RE: RFC 2486bis issue: "Decorated" NAIs and IDN support

The ABNF in Section 2.1 doesn't seem to take this into account, so I think
that a change may be needed there too.   For example, to allow NAIs such
as

[email-masked]

I think you need a rule like:

   nai         =  username
   nai         =/ "@" realm
   nai         =/ *(realm "!") username "@" realm

On Fri, 8 Jul 2005 [email-masked] wrote:

>
> I think the approach proposed below is a good one (or at
> least I don't see any better approach either).
>
> It also doesn't require much changes to 2486bis; we just need
> to mention that all realm names, both after "@" and before "!"
> (when that notation are used), are IDN-unaware domain name
> slots.
>
> Would this clarification to Section 2.7 be sufficient, or do
> we need more text?
> OLD:
>    In this case, the part before the (non-escaped) '!' MUST be a
>    realm name as defined in the ABNF in Section 2.1.  When
>    receiving such an NAI, ...
> NEW:
>    In this case, the part before the (non-escaped) '!' MUST be a
>    realm name as defined in the ABNF in Section 2.1.  This realm
>    name is an "IDN-unaware domain name slot", just like the
>    realm name after the "@" character; see Section 2.4 for
>    details.  When receiving such an NAI, ...
>
> Best regards,
> Pasi
>
> > -----Original Message-----
> > From: Bernard Aboba
> > Sent: Sunday, July 03, 2005 11:52 PM
> > To: Paul Hoffman
> > Cc: [email-masked]; [email-masked]; [email-masked]
> > Subject: Re: RFC 2486bis issue: "Decorated" NAIs and IDN support
> >
> >
> > > I am lost here. An IDN client (in this case, the UI where
> > > the user enters the NAI), is responsible for doing a
> > > Unicode-to-ASCII conversion. It becomes a valid FQDN right
> > > there. The only tricky part is that the UI has to look for
> > > DNS names amid the ! and @ characters.
> > >
> > > >Can you look at the below thread and give us your feedback
> > > >on how we should think about this?
> > >
> > > See above. The thread you passed bounced around among many
> > > proposals. Basically, something needs to find the domain names
> > > in the string that the user entered and convert them to ASCII.
> > > And domain names (even in the middle of the other gunk in the
> > > NAI) being displayed should be converted back to UTF-8.
> >
> > OK.  So if I understand this correctly then:
> >
> > a. It is the responsibility of the peer to provide the NAI in
> > the correct (ASCII) format.
> >
> > b. Similarly, it is the responsbility of the RADIUS proxy to
> > provide its realm table entries in the same ASCII format.
> >
> > c. Assuming a) and b) are done, then the proxy does not need
> > to do any conversions in the manipulation of "decorated" NAIs.
> > For example, it can convert [email-masked] ->
> > [email-masked] without having to "translate"
> > microsoft.com (assuming that this contained only
> > appropriately formatted ASCII characters).
> >
> > If a DNS lookup needs to be done (not required in RADIUS but
> > potentially needed in Diameter) then the proxy can use the realm
> > directly without conversion.
> >
> > Is this 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, 08 Jul 2005 08:38:26 +0000
Content-class: urn:content-classes:message
Subject: RE: RFC 2486bis issue: "Decorated" NAIs and IDN support
Date: Fri, 8 Jul 2005 11:37:40 +0300
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>

I think the approach proposed below is a good one (or at=20
least I don't see any better approach either).=20

It also doesn't require much changes to 2486bis; we just need=20
to mention that all realm names, both after "@" and before "!"=20
(when that notation are used), are IDN-unaware domain name=20
slots.

Would this clarification to Section 2.7 be sufficient, or do
we need more text?
OLD:
   In this case, the part before the (non-escaped) '!' MUST be a
   realm name as defined in the ABNF in Section 2.1.  When
   receiving such an NAI, ...
NEW:
   In this case, the part before the (non-escaped) '!' MUST be a
   realm name as defined in the ABNF in Section 2.1.  This realm
   name is an "IDN-unaware domain name slot", just like the
   realm name after the "@" character; see Section 2.4 for
   details.  When receiving such an NAI, ...

Best regards,
Pasi

> -----Original Message-----
> From: Bernard Aboba
> Sent: Sunday, July 03, 2005 11:52 PM
> To: Paul Hoffman
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: RFC 2486bis issue: "Decorated" NAIs and IDN support
>=20
>=20
> > I am lost here. An IDN client (in this case, the UI where=20
> > the user enters the NAI), is responsible for doing a=20
> > Unicode-to-ASCII conversion. It becomes a valid FQDN right=20
> > there. The only tricky part is that the UI has to look for=20
> > DNS names amid the ! and @ characters.
> >
> > >Can you look at the below thread and give us your feedback=20
> > >on how we should think about this?
> >
> > See above. The thread you passed bounced around among many=20
> > proposals. Basically, something needs to find the domain names=20
> > in the string that the user entered and convert them to ASCII.=20
> > And domain names (even in the middle of the other gunk in the=20
> > NAI) being displayed should be converted back to UTF-8.
>=20
> OK.  So if I understand this correctly then:
>=20
> a. It is the responsibility of the peer to provide the NAI in=20
> the correct (ASCII) format.
>=20
> b. Similarly, it is the responsbility of the RADIUS proxy to=20
> provide its realm table entries in the same ASCII format.
>=20
> c. Assuming a) and b) are done, then the proxy does not need=20
> to do any conversions in the manipulation of "decorated" NAIs. =20
> For example, it can convert [email-masked] ->=20
> [email-masked] without having to "translate"=20
> microsoft.com (assuming that this contained only=20
> appropriately formatted ASCII characters).
>=20
> If a DNS lookup needs to be done (not required in RADIUS but=20
> potentially needed in Diameter) then the proxy can use the realm=20
> directly without conversion.
>=20
> Is this 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: Thu, 07 Jul 2005 14:03:51 +0000
Date: Thu, 7 Jul 2005 07:03:45 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: RADEXT WG Last Call on draft-ietf-radext-dynauth-server-mib-01.txt (fwd)

This is an announcement of RADEXT WG last call on the "Dynamic
Authorization Server MIB", prior to sending this document to the IESG for
publication as an Informational RFC.  The document will be available on
the IETF archive at the following location:
http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-server-mib-01.txt

Until then, it is available for inspection at:
http://www.drizzle.com/~aboba/RADEXT/draft-ietf-radext-dynauth-server-mib-01.txt

RADEXT WG Last Call will last until July 28, 2005.  Please send your
comments to the RADEXT WG mailing list ([email-masked]) in the
format described in the RADEXT Issues List, located at:

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, 07 Jul 2005 14:02:49 +0000
Date: Thu, 7 Jul 2005 07:01:57 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: RADEXT WG Last Call on draft-ietf-radext-dynauth-client-mib-01.txt

This is an announcement of RADEXT WG last call on the "Dynamic
Authorization Client MIB", prior to sending this document to the IESG for
publication as an Informational RFC.  The document will be available on
the IETF archive at the following location:
http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-client-mib-01.txt

Until then, it is available for inspection at:
http://www.drizzle.com/~aboba/RADEXT/draft-ietf-radext-dynauth-client-mib-01.txt

RADEXT WG Last Call will last until July 28, 2005.  Please send your
comments to the RADEXT WG mailing list ([email-masked]) in the
format described in the RADEXT Issues List, located at:

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: Sun, 03 Jul 2005 20:52:39 +0000
Date: Sun, 3 Jul 2005 13:51:54 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Paul Hoffman <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Subject: Re: RFC 2486bis issue: "Decorated" NAIs and IDN support

> I am lost here. An IDN client (in this case, the UI where the user
> enters the NAI), is responsible for doing a Unicode-to-ASCII
> conversion. It becomes a valid FQDN right there. The only tricky part
> is that the UI has to look for DNS names amid the ! and @ characters.
>
> >Can you look at the below thread and give us your feedback on how
> >we should think about this?
>
> See above. The thread you passed bounced around among many proposals.
> Basically, something needs to find the domain names in the string
> that the user entered and convert them to ASCII. And domain names
> (even in the middle of the other gunk in the NAI) being displayed
> should be converted back to UTF-8.

OK.  So if I understand this correctly then:

a. It is the responsibility of the peer to provide the NAI in the
correct (ASCII) format.

b. Similarly, it is the responsbility of the RADIUS proxy to provide its
realm table entries in the same ASCII format.

c. Assuming a) and b) are done, then the proxy does not need to do any
conversions in the manipulation of "decorated" NAIs.  For example, it can
convert [email-masked] -> [email-masked] without
having to "translate" microsoft.com (assuming that this contained only
appropriately formatted ASCII characters).

If a DNS lookup needs to be done (not required in RADIUS but potentially
needed in Diameter) then the proxy can use the realm directly without
conversion.

Is this 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, 01 Jul 2005 22:03:39 +0000
Date: Fri, 01 Jul 2005 15:03:37 -0700
From: Murtaza Chiba <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: [email-masked]
Subject: Re: Last call on MIB documents?

All,
	Stefaan was going to handle one last comment of splitting timeouts for 
DM and CoA.  He was going to be back next week, so we should have it 
ready by the end of the week.

THanks,
Murtaza

Bernard Aboba wrote:
> Since the MIB documents (RADIUS MIB Update, RFC 3576 MIBs) are not getting
> a lot of comment, it seems like it might be appropriate to bring them to
> WG last call as soon as the next revisions are available.
> 
> Can the authors indicate when they expect to have a revision submitted
> that addresses the outstanding issues?
> 
> --
> 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, 01 Jul 2005 21:48:56 +0000
Date: Fri, 1 Jul 2005 14:48:12 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Last call on MIB documents?

Since the MIB documents (RADIUS MIB Update, RFC 3576 MIBs) are not getting
a lot of comment, it seems like it might be appropriate to bring them to
WG last call as soon as the next revisions are available.

Can the authors indicate when they expect to have a revision submitted
that addresses the outstanding issues?

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