Subject: RADEXT WG Agenda for IETF 62: Take three
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Date: Mon, 28 Feb 2005 07:41:37 -0800 (PST)

IETF 62 RADEXT WG Meeting
Thursday, March 10, 2005
0900 - 1130

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-05.txt

In WG Last Call (to end March 14, 2005)

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

WG Work Items

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

MIBs

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

RFC 3576 MIBs, TBD (5 minutes)
http://www.ietf.org/internet-drafts/draft-decnodder-radext-dynauth-client-mib-03.txt
http://www.ietf.org/internet-drafts/draft-decnodder-radext-dynauth-server-mib-03.txt

Pre-work Item Review

RADIUS Extensions for IEEE 802, Mauricio Sanchez (10 minutes)
http://www.ietf.org/internet-drafts/draft-congdon-radext-ieee802-03.txt

RADIUS Extensions for Management Authorization, David Nelson (10 Minutes)
http://www.ietf.org/internet-drafts/draft-nelson-radius-management-authorization-01.txt

Prepaid Extensions for RADIUS, Avi Lior (10 minutes)
http://www.ietf.org/internet-drafts/draft-lior-radius-prepaid-extensions-07.txt

Issues and Fixes, David Nelson (10 minutes)
http://www.drizzle.com/~aboba/RADEXT/

RADIUS Work in Other WGs

Using RADIUS for PE-based VPN Discovery, Greg Weber (10 minutes)
http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-radius-pe-discovery-01.txt

RADIUS Location, Hannes Tschofenig (10 minutes)
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius-lo-02.txt

Miscellaneous

Service Decisions, Jari Arkko (5 minutes)
http://www.ietf.org/internet-drafts/draft-arkko-radext-multi-service-decisions-01.txt

Capabilities Discovery (15 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, 28 Feb 2005 15:20:33 +0000
Date: Mon, 28 Feb 2005 07:19:58 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: RADEXT WG Agenda for IETF 62: Take two

IETF 62 RADEXT WG Meeting
Thursday, March 10, 2005
0900 - 1130

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-05.txt

In WG Last Call (to end March 14, 2005)

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

WG Work Items

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

MIBs

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

RFC 3576 MIBs, TBD (5 minutes)
http://www.ietf.org/internet-drafts/draft-decnodder-radext-dynauth-client-mib-03.txt
http://www.ietf.org/internet-drafts/draft-decnodder-radext-dynauth-server-mib-03.txt

Pre-work Item Review

RADIUS Extensions for IEEE 802, Mauricio Sanchez (10 minutes)
http://www.ietf.org/internet-drafts/draft-congdon-radext-ieee802-03.txt

RADIUS Extensions for Management Authorization, David Nelson (10 Minutes)
http://www.ietf.org/internet-drafts/draft-nelson-radius-management-authorization-01.txt

Prepaid Extensions for RADIUS, Avi Lior (10 minutes)
http://www.ietf.org/internet-drafts/draft-lior-radius-prepaid-extensions-07.txt

Issues and Fixes, David Nelson (10 minutes)
http://www.drizzle.com/~aboba/RADEXT/

RADIUS Work in Other WGs

Using RADIUS for PE-based VPN Discovery, Greg Weber (10 minutes)
http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-radius-pe-discovery-01.txt

RADIUS Location, Hannes Tschofenig (10 minutes)
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius-lo-02.txt

General Issue Discussion

Capabilities Discovery (15 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, 28 Feb 2005 13:02:16 +0000
Date: Mon, 28 Feb 2005 15:01:36 +0200
From: Jari Arkko <[email-masked]>
To: Bernard Aboba <[email-masked]>
Cc: [email-masked]
Subject: Re: Issue 67: Interpretation of Idle-Timeout

Bernard Aboba wrote:

>Issue 67: Interpretation of Idle-Timeout
>Submitter name: Bernard Aboba
>Submitter email address: [email-masked]
>Date first submitted: February 27, 2005
>Reference:
>Document: ISSUES, IEEE 802
>Comment type: T
>Priority: S
>Section:
>Rationale/Explanation of issue:
>
>Here is what RFC 2865, Section 5.28 says about Idle-Timeout:
>
>"This Attribute sets the maximum number of consecutive seconds of
>idle connection allowed to the user before termination of the
>session or prompt. This Attribute is available to be sent by the
>server to the client in an Access-Accept or Access-Challenge."
>  
>
Ok.

>Here is what RFC 3580, Section 3.12 says about Idle-Timeout:
>
>"The Idle-Timeout attribute is described in [RFC2865]. For IEEE 802
>media other than 802.11 the media are always on. As a result the
>Idle-Timeout attribute is typically only used with wireless media
>such as IEEE 802.11. It is possible for a wireless device to wander
>out of range of all Access Points. In this case, the Idle-Timeout
>attribute indicates the maximum time that a wireless device may
>remain idle."
>  
>
I wonder if there are in fact two separate issues in the
above text. At least some wireless technology is capable
of sensing the presence and reachability of the client.
(And I think 802.11 belongs to this category too, but I
may be mistaken.)

The presence of a client is different from it being idle.
Of course, if your L2 only gives you an idle indicator,
not presence indicator, you may wish to simulate the
latter with the former. But this is often unsatisfactory
and leads to overly long attachment times for hosts
that have moved on, or too short idle timers.

The presence problem requires a soft process because
we don't want to disconnect anyone just because a truck
passed by and blocked coverage for few seconds. We may
also leave around state so that roaming hosts can come
back and not have to redo full authentication.

>However, there is no definition of "idle". Does this really mean
>"no traffic"? In practice, a connected host will send broadcast
>traffic, including ARP, NetBIOS, IPX, AppleTalk, SSDP, etc. So
>if idle = "no traffic" then the idle timeout might never trigger.
>  
>
Right.

>In practice, devices often provide support for access lists
>that define what types of traffic are used to bring
>connections up and down.  So that filter defines what "idle" is.
>If not provided, local policy makes the determination.
>  
>
Yes, but this is problematic too, because it isn't certain
that the client's view of the policy is the same as the
network provider's.  The operators policy may be based
on incorrect assumptions about the software that
people run, for instance.

>The suggested resolution is to look at defining "idle" conditions more
>explicitly within RADIUS, such as defining the maximum traffic over a
>defined period that qualifies as "idle" and possibly defining a filter
>that would indicate what traffic is *not* to be counted.
>  
>
Defining idle traffic is probably a better idea than defining
non-idle traffic. If you define idle lists, no one is going to get
logged out because their favorite protocol was not included
in the list -- they just might stay logged on longer. But if you
define non-idle traffic then what happens if the stuff that
I use is not included in the filter. Say, if I use IPv6:TCP and
the filter said IPv4:TCP...

The other thing that I would recommend is encouraging
L2 to provide "carrier sense" so that we could accurately
track whether particular nodes are still within range or not.

>Within the Issues and Fixes document, it would be stated that "Idle"
>is defined by local policy in the absence of these other attributes.
>  
>
I support this.

--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: Sun, 27 Feb 2005 19:19:40 +0000
Date: Sun, 27 Feb 2005 11:19:02 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Issue 67: Interpretation of Idle-Timeout

Issue 67: Interpretation of Idle-Timeout
Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: February 27, 2005
Reference:
Document: ISSUES, IEEE 802
Comment type: T
Priority: S
Section:
Rationale/Explanation of issue:

Here is what RFC 2865, Section 5.28 says about Idle-Timeout:

"This Attribute sets the maximum number of consecutive seconds of
idle connection allowed to the user before termination of the
session or prompt. This Attribute is available to be sent by the
server to the client in an Access-Accept or Access-Challenge."

Here is what RFC 3580, Section 3.12 says about Idle-Timeout:

"The Idle-Timeout attribute is described in [RFC2865]. For IEEE 802
media other than 802.11 the media are always on. As a result the
Idle-Timeout attribute is typically only used with wireless media
such as IEEE 802.11. It is possible for a wireless device to wander
out of range of all Access Points. In this case, the Idle-Timeout
attribute indicates the maximum time that a wireless device may
remain idle."

However, there is no definition of "idle". Does this really mean
"no traffic"? In practice, a connected host will send broadcast
traffic, including ARP, NetBIOS, IPX, AppleTalk, SSDP, etc. So
if idle = "no traffic" then the idle timeout might never trigger.

In practice, devices often provide support for access lists
that define what types of traffic are used to bring
connections up and down.  So that filter defines what "idle" is.
If not provided, local policy makes the determination.

The suggested resolution is to look at defining "idle" conditions more
explicitly within RADIUS, such as defining the maximum traffic over a
defined period that qualifies as "idle" and possibly defining a filter
that would indicate what traffic is *not* to be counted.

Within the Issues and Fixes document, it would be stated that "Idle"
is defined by local policy in the absence of these other attributes.

--
to unsubscribe send 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, 25 Feb 2005 19:44:24 +0000
Date: Fri, 25 Feb 2005 11:43:46 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Review of draft-chiba-radius-dynauthor-ext-00.txt

RFC 3576 introduced the concept of dynamic authorization to RADIUS, where
a session that had previously been authorized can be terminated or
modified by an exchange initiated by the RADIUS server.

In order to be able to utilize the facilities introduced in RFC 3576, it
is necessary for the server initiating a CoA or Disconnect-Request to have
kept state on the session it is looking to modify.  This includes
recording the NAS with which the session was initiated (NAS-IP-Address,
NAS-Identifier, NAS-IPv6-Address) as well as the session itself
(User-Name, NAS-Port, Framed-IP-Address, Called-Station-Id,
Calling-Station-Id, Acct-Session-Id, Acct-Multi-Session-Id, NAS-Port-Type,
NAS-Port-Id, Originating-Line-Info, Framed-Interface-Id,
Framed-IPv6-Prefix).

However, since RADIUS Accounting packets may be lost, it is possible for
the state on the server to have gotten out of sync.  For example, an
accounting server may not receive an Accounting STOP, and therefore may
think that a session continues when in fact it had ended.  It is also
possible for an Accounting Start or Interim message to be lost in which
case the server may not be aware that it had started (until a subsequent
Interim or STOP message is received).

In these circumstances, it is possible for a server initiating a CoA or
Disconnect-Request to receive an error message in response, indicating
that the session did not exist.

Where this occurs, how can the server resynchronize its state?  Note that
to achieve the resynchronization it may not be sufficient just to retrieve
the current state of the NAS that responded with an error;  the session
may have moved elsewhere, and that Accounting message may have been lost
too (e.g. the server knows of no other session on another NAS with the
same multi-session-id).

In order to address this problem, the document introduces a Query-Select
attribute, enabling a server to query for sessions of a given type.

The query syntax is quite general, allowing a number of attributes to be
returned based on whether the service or expression matching.

Since modern NAS devices can be very large, supporting hundreds of
sessions, it does seem necessary to be able to support selective queries,
since a complete dump of NAS session state could easily exceed the maximum
RADIUS packet size of 4096 octets.

However, the query syntax introduces an entirely new "URI"-based model for
RADIUS service types, which has no precedent within previous RADIUS
documents.  The query syntax also appears to be more complex than is
required to solve the problem as stated above.  Many NAS devices remain
short of resources, so that they cannot support complex queries such
as is proposed here.

For example, in order to attempt to locate the sessions of a given user,
an equality query for the User-Name attribute would be sufficient.  The
same could be said of other session attributes; there is no need to do
other types of comparisons on such session identifiers.

The other element this document introduces is the Authorization-Command.
attribute.  The only value of this attribute used is "Query-Only", used
for the query functionality described earlier.

Since there are already multiple RADIUS command codes defined for resource
querying (23 = Resource-Query-Request, 24 = Resource-Query-Response) it is
not clear why this new attribute is needed.  RFC 2882 describes these
commands, but does not provide details on their functionality, and as a
result, it is not clear that whether the functionality provided in this
document already exists.

RFC 3575 includes the following language relating to allocation of new
RADIUS command codes:

Packet
   Type Codes 6-10, 12-13, 21-34, 50-51 have no meaning defined by an
   IETF RFC, but are reserved until a specification is provided for
   them.  This is being done to avoid interoperability problems with
   software that implements non-standard RADIUS extensions that are or
   have been in use on the Internet.  Because a new Packet Type has
   considerable impact on interoperability, a new Packet Type Code
   requires IESG Approval.  The intention is that any allocation will be
   accompanied by a published RFC.  Type Codes 52-249 should be
   allocated first; when these are exhausted, Type Codes 14-20, 35-39,
   46-49 may be allocated.  For a list of Type Codes, see Appendix A.

And Service-Type values:

   The exception to this policy is
   the Service-Type attribute (6), whose values define new modes of
   operation for RADIUS.  Values 1-16 of the Service-Type attribute have
   been allocated.  Allocation of new Service-Type values are by IETF
   Consensus.  The intention is that any allocation will be accompanied
   by a published RFC.

Between command codes and Service-Type values, it seems to me that the
functionality required in this document can be covered, so that allocating
a new Authorization-Command attribute is not necessary or desirable.

--
to unsubscribe send 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, 24 Feb 2005 09:22:25 +0000
Date: Thu, 24 Feb 2005 11:20:09 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: "[email-masked]'" <[email-masked]>
Subject: FW: I-D ACTION:draft-arkko-radext-multi-service-decisions-01.txt

We have published the following draft, as an output from
the work on "EAP lower layer attribute" issue that
has been held in the last couple of IETFs. Comments
appreciated.

--Jari

[email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
> 	Title		: Policy Decisions for Users with Access to Multiple Services
> 	Author(s)	: J. Arkko, P. Eronen
> 	Filename	: draft-arkko-radext-multi-service-decisions-01.txt
> 	Pages		: 17
> 	Date		: 2005-2-23
> 	
>    This draft relates to the use of Authentication, Authorization, and
>    Accounting (AAA) where the same user credentials can be used on many
>    different types of devices, ranging from wireless access points to
>    Virtual Private Network (VPN) gateways.  More specifically, this
>    draft discusses how AAA servers can determine what incoming service
>    was provided, and how they can use this information as a basis for
>    policy decisions.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-arkko-radext-multi-service-decisions-01.txt

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

Delivery-date: Wed, 23 Feb 2005 20:31:24 +0000
Content-class: urn:content-classes:message
Subject: FW: I-D ACTION:draft-nelson-radius-management-authorization-01.txt
Date: Wed, 23 Feb 2005 15:30:22 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

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

	Title		: RADIUS Extension for Management Authorization
	Author(s)	: D. Nelson, G. Weber
	Filename	: draft-nelson-radius-management-authorization-01.txt
	Pages		: 18
	Date		: 2005-2-22
=09
   This document describes RADIUS attributes for the authorization and
=A0=A0 service provisioning of local and remote management of embedded
=A0=A0 systems and other managed entities (NASes).=A0 Specific =
provisions are
=A0=A0 made for remote management via framed management protocols, and =
for
=A0=A0 more granular levels of security and command privilege level =
beyond
=A0=A0 those included in the base RADIUS specification.=A0 Provisions =
are also
=A0=A0 introduced for enhancing auditability of individual management
=A0=A0 operations.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-nelson-radius-management-author=
ization-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.=A0=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-nelson-radius-management-authorization-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-nelson-radius-management-authorization-01.txt".
=09
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.=A0 To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.=A0 To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.=A0 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.

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

--
to unsubscribe send 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, 23 Feb 2005 17:14:51 +0000
From: Avi Lior <[email-masked]>
To: [email-masked]
Subject: FW: {Blocked Content} [Geopriv] I-D ACTION:draft-ietf-geopriv-rad ius-lo-02.txt
Date: Wed, 23 Feb 2005 12:14:17 -0500

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_000_01C519CB.1B014250
Content-Type: text/plain

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, February 22, 2005 3:39 PM
To: [email-masked]
Cc: [email-masked]
Subject: {Blocked Content} [Geopriv] I-D
ACTION:draft-ietf-geopriv-radius-lo-02.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. This draft is a work item of the Geographic Location/Privacy
Working Group of the IETF.

	Title		: Carrying Location Objects in RADIUS
	Author(s)	: H. Tschofenig, et al.
	Filename	: draft-ietf-geopriv-radius-lo-02.txt
	Pages		: 48
	Date		: 2005-2-22
	
This document describes RADIUS attributes for conveying the Access
   Network's operational ownership and location information based on a
   civil and geospatial location location format.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius-lo-02.txt

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

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-ietf-geopriv-radius-lo-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
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-ietf-geopriv-radius-lo-02.txt".
	
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.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

------_=_NextPart_000_01C519CB.1B014250
Content-Type: message/rfc822

To: 
Subject: 
Date: Wed, 23 Feb 2005 10:28:12 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_002_01C519CB.1B014250"

------_=_NextPart_002_01C519CB.1B014250
Content-Type: text/plain

------_=_NextPart_002_01C519CB.1B014250
Content-Type: text/plain;
	name="VirusWarning.txt"
Content-Disposition: attachment;
	filename="VirusWarning.txt"

This is a message from the MailScanner E-Mail Virus Protection Service
----------------------------------------------------------------------
The original e-mail attachment "not named"
was believed to be dangerous and/or infected by a virus and has been
replaced by this warning message.

Due to limitations placed on us by the Regulation of Investigatory Powers
Act 2000, we were unable to keep a copy of the infected attachment. Please
ask the sender of the message to disinfect their original version and send
you a clean copy.

At Wed Feb 23 03:36:20 2005 the scanner said:
   External message bodies cannot be scanned and are removed

-- 
Postmaster

MailScanner thanks transtec Computers for their support

------_=_NextPart_002_01C519CB.1B014250
Content-Type: text/plain;
	name="VirusWarning.txt"
Content-Disposition: attachment;
	filename="VirusWarning.txt"

This is a message from the MailScanner E-Mail Virus Protection Service
----------------------------------------------------------------------
The original e-mail attachment "not named"
was believed to be dangerous and/or infected by a virus and has been
replaced by this warning message.

Due to limitations placed on us by the Regulation of Investigatory Powers
Act 2000, we were unable to keep a copy of the infected attachment. Please
ask the sender of the message to disinfect their original version and send
you a clean copy.

At Wed Feb 23 03:36:20 2005 the scanner said:
   External message bodies cannot be scanned and are removed

-- 
Postmaster

MailScanner thanks transtec Computers for their support

------_=_NextPart_002_01C519CB.1B014250--

------_=_NextPart_000_01C519CB.1B014250
Content-Type: text/plain;
	name="ATT651484.txt"
Content-Disposition: attachment;
	filename="ATT651484.txt"

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

------_=_NextPart_000_01C519CB.1B014250--

--
to unsubscribe send 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, 22 Feb 2005 17:06:44 +0000
From: Avi Lior <[email-masked]>
To: [email-masked]
Subject: FW: {Blocked Content} I-D ACTION:draft-lior-radius-prepaid-extens ions-07.txt
Date: Tue, 22 Feb 2005 12:06:06 -0500

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_000_01C51900.CBE8C050
Content-Type: text/plain

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, February 21, 2005 3:38 PM
To: [email-masked]
Subject: {Blocked Content} I-D
ACTION:draft-lior-radius-prepaid-extensions-07.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
Dial-In User
			  Service (RADIUS)
	Author(s)	: A. Lior, et al.
	Filename	: draft-lior-radius-prepaid-extensions-07.txt
	Pages		: 58
	Date		: 2005-2-21
	
This draft presents an extension to the Remote Authentication Dial-
   In User Service (RADIUS) protocol to support charging for prepaid 
   services. The charging models supported are namely: volume-based 
   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-07.
txt

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

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

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
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-07.txt".
	
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.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

------_=_NextPart_000_01C51900.CBE8C050
Content-Type: message/rfc822

To: 
Subject: 
Date: Tue, 22 Feb 2005 10:58:06 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_002_01C51900.CBE8C050"

------_=_NextPart_002_01C51900.CBE8C050
Content-Type: text/plain

------_=_NextPart_002_01C51900.CBE8C050
Content-Type: text/plain;
	name="VirusWarning.txt"
Content-Disposition: attachment;
	filename="VirusWarning.txt"

This is a message from the MailScanner E-Mail Virus Protection Service
----------------------------------------------------------------------
The original e-mail attachment "not named"
was believed to be dangerous and/or infected by a virus and has been
replaced by this warning message.

Due to limitations placed on us by the Regulation of Investigatory Powers
Act 2000, we were unable to keep a copy of the infected attachment. Please
ask the sender of the message to disinfect their original version and send
you a clean copy.

At Tue Feb 22 03:07:15 2005 the scanner said:
   External message bodies cannot be scanned and are removed

-- 
Postmaster

MailScanner thanks transtec Computers for their support

------_=_NextPart_002_01C51900.CBE8C050
Content-Type: text/plain;
	name="VirusWarning.txt"
Content-Disposition: attachment;
	filename="VirusWarning.txt"

This is a message from the MailScanner E-Mail Virus Protection Service
----------------------------------------------------------------------
The original e-mail attachment "not named"
was believed to be dangerous and/or infected by a virus and has been
replaced by this warning message.

Due to limitations placed on us by the Regulation of Investigatory Powers
Act 2000, we were unable to keep a copy of the infected attachment. Please
ask the sender of the message to disinfect their original version and send
you a clean copy.

At Tue Feb 22 03:07:15 2005 the scanner said:
   External message bodies cannot be scanned and are removed

-- 
Postmaster

MailScanner thanks transtec Computers for their support

------_=_NextPart_002_01C51900.CBE8C050--

------_=_NextPart_000_01C51900.CBE8C050
Content-Type: text/plain;
	name="ATT647498.txt"
Content-Disposition: attachment;
	filename="ATT647498.txt"

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

------_=_NextPart_000_01C51900.CBE8C050--

--
to unsubscribe send 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, 21 Feb 2005 13:59:58 +0000
Date: Mon, 21 Feb 2005 15:57:57 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: "[email-masked]'" <[email-masked]>
Subject: new revision of the 2486bis draft

Hi,

To address the issues that were raised by IESG (64, 65)
and elsewhere (47) I have sent in a new revision of
the NAI draft*.

Here's a preliminary link to the draft and
a diff to the previous version:

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

Comments appreciated, as always.

--Jari

*) Actually, I submitted two revisions today, -04 and
-05. I got some unexpectedly quick comments from the
IESG about the modifications, so I wanted to revise
the first one. Anyone still remember the good old
days when it took a long time to get input from
the IESG? ;-) Nevertheless, we didn't quite finish the
discussion so its possible that we still need to
submit new revisions. If that's the case then we
will send a new revision when the submissions open
up again.

--
to unsubscribe send 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, 21 Feb 2005 10:44:19 +0000
Date: Mon, 21 Feb 2005 12:42:25 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: "[email-masked]'" <[email-masked]>
Subject: Suggested resolution of the IESG discuss comment on RFC 2486bis

> I'm concerned about the way the documents formal syntax attempts to bring in the SASLprep
> work; it seems likely that an implementor might believe that only the mapping and normalization 
> steps of saslprep are required, where I believe the intent is to prohibit characters which are not
> legal output characters according to SASLprep.  The document says this:
> 
>  c           =/ %x80-ff ; UTF-8            allowed (not in RFC 2486)
>                ; c must also satisfy rules in Section 2.4
>    x           =  %x00-FF ; all 128 ASCII characters, no exception;
>                           ; as well as all UTF-8 characters (this
>                           ; was not allowed in RFC 2486)
> 
> 
> Section 2.4, in turn, says:
> 
>    In order to ensure a canonical representation, characters of the
>    username portion in an NAI MUST fulfill the requirements specified in
>    [I-D.ietf-sasl-saslprep].  In addition, the use of certain special
>    characters (see grammar rule c) are prohibited as well in order to
>    retain compatibility with the previous version of this RFC.
> 
> 
> SASLprep has multiple aspects; mapping, normalization, and prohibited
> output.  If the authors mean to disallow the prohibited output set of
> characters from SASLprep, I believe the statement in the formal syntax
> should reference the prohibited set.  Other mechanisms which make
> clear whether the prohibited output set is or is not allowed in a username
> side would be fine as well.

I agree with the issue that was raised.

Here's an attempt to correct the problem. What I want to do is
to make the requirement explicit, both in the ABNF and in the
text. Here's the relevant part of the new ABNF

    c           =/ %x80-FF ; UTF-8-Octet      allowed (not in RFC 2486)
                           ; Where UTF-8-octet is any octet in the
                           ; multi-octet UTF-8 representation of a
                           ; unicode codepoint above %x7F.
                           ; Note that c must also satisfy rules in
                           ; Section 2.4, including, for instance,
                           ; checking that no prohibited output is
                           ; used (see also Section 2.3 of
                           ; [I-D.ietf-sasl-saslprep]).
    x           =  %x00-FF ; all 128 ASCII characters, no exception;
                           ; as well as all UTF-8-octets as defined
                           ; above (this was not allowed in
                           ; RFC 2486). Note that c must nevertheless
                           ; again satisfy the Section 2.4 rules.

and new text in Section 2.4:

2.4  International Character Sets

    This specification allows both international usernames and realms.
    International usernames are based on the use of Unicode characters,
    encoded as UTF-8 and processed with a certain algorithm to ensure a
    canonical representation.  The realm part internationalization is
    based on International Domain Name (IDN) [RFC3490].

    In order to ensure a canonical representation, characters of the
    username portion in an NAI MUST fulfill both the ABNF in this
    specification as well as the requirements specified in
    [I-D.ietf-sasl-saslprep].  These requirements consist of the
    following:

    o  Mapping requirements, as specified in Section 2.1 of
       [I-D.ietf-sasl-saslprep].  Mapping consists of mapping certain
       characters to others (such as SPACE) in order to increase the
       likelihood of correctly performed comparisons.

    o  Normalization requirements, as specified in Section 2.2 of
       [I-D.ietf-sasl-saslprep], also designed to assist comparisons.

    o  Prohibited output.  Certain characters are not permitted in
       correctly formed strings that follow Section 2.3 of
       [I-D.ietf-sasl-saslprep].  Ensuring that NAIs conform to their
       ABNF is not sufficient, it is also necessary to ensure that they
       do not contain prohibited output.

    o  Bidirectional characters are handled as specified in Section 2.4
       of [I-D.ietf-sasl-saslprep].

    o  Unassigned code points are specified in Section 2.5 of
       [I-D.ietf-sasl-saslprep].

    The realm name is an "IDN-unaware domain name slot" as defined in
    [RFC3490].  That is, it can contain only ASCII characters.  An
    implementation MAY support internationalized domain names (IDNs)
    using the ToASCII operation; see [RFC3490] for more information.

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

Delivery-date: Mon, 21 Feb 2005 09:46:47 +0000
Date: Mon, 21 Feb 2005 10:45:54 +0100
From: [email-masked]
To: Bernard Aboba <[email-masked]>
CC: [email-masked]
Subject: Re: updated MIBs for RFC3576

Unfortunately, I will not be in Minneapolis and I do not know yet about 
the other co-authors. It is good to have the drafts on the agenda. The 
agenda mentions version 04 -> should be 03.

regards,

Stefaan

Bernard Aboba wrote:

> Thanks.  Will you be available to present them in Minneapolis?
> 
> On Sun, 20 Feb 2005 [email-masked] wrote:
> 
> 
>>Hi,
>>
>>Updated versions of the MIBs for RFC3576 are now available at
>>
>>http://www.ietf.org/internet-drafts/draft-decnodder-radext-dynauth-server-mib-03.txt
>>
>>and
>>
>>http://www.ietf.org/internet-drafts/draft-decnodder-radext-dynauth-client-mib-03.txt
>>
>>These updated versions include all comments from Dan and Bert (issues
>>31, 44, 45, and 48).
>>
>>regards,
>>
>>Stefaan
>>
>>
>>--
>>to unsubscribe send a message to [email-masked] with
>>the word 'unsubscribe' in a single line as the message text body.
>>archive: <http://psg.com/lists/radiusext/>
>>

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

Delivery-date: Mon, 21 Feb 2005 08:58:15 +0000
Date: Mon, 21 Feb 2005 10:56:34 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: "[email-masked]'" <[email-masked]>
Cc: Henrik Levkowetz <[email-masked]>
Subject: 2486bis issue: utf-8

> Comment:	Curtesy of Henrik Levkowetz <[email-masked]>
> 
> 1)
> 
> In Section 2.1 it says:
> 
>>    char        =  c
>>    char        =/ "\" x
> 
> [...]
> 
>>    c          =/ %x80-ff ; UTF-8            allowed (not in RFC 2486)
>>                ; c must also satisfy rules in Section 2.4
>>    x          =  %x00-FF ; all 128 ASCII characters, no exception;
>>                          ; as well as all UTF-8 characters (this
>>                          ; was not allowed in RFC 2486)
> 
> With good will and positive thinking, it is possible to work out that
> the indication "UTF-8" means any component octet in an utf-8 encoded
> character; however it is not correct in either of the above ABNF rules
> that 0x80-ff is a UTF-8 character, nor that an arbitrary UTF-8 character
> can be represented as %x80-FF. 
> 
> So maybe replace this with:
> 
>     c          =/ %x80-FF ; UTF-8-octet      allowed (not in RFC 2486)
>                             ; where UTF-8-octet is any octet in the
>                             ; multi-octet UTF-8 representation of a
>                             ; unicode codepoint above %x7F.
>                 ; c must also satisfy rules in Section 2.4
>     x          =  %x00-FF ; all 128 ASCII characters, no exception;
>                             ; as well as all UTF-8-octets as defined
>                             ; above (this was not allowed in RFC 2486)

Right. This works for me. Changed...

--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: Mon, 21 Feb 2005 08:52:24 +0000
Date: Mon, 21 Feb 2005 10:50:27 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: "[email-masked]'" <[email-masked]>, Henrik Levkowetz <[email-masked]>
Subject: 2486bis issue: upper/lowercase hex

 From the I-D tracker:
> Curtesy of Henrik Levkowetz <[email-masked]>
> 
> RFC2234 defines
> 
>         num-val        =  "%" (bin-val / dec-val / hex-val)
>         hex-val        =  "x" 1*HEXDIG
>                           [ 1*("." 1*HEXDIG) / ("-" 1*HEXDIG) ]
>         HEXDIG        =  DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
> 
> 
> 2486bis uses both the lower-case form (e.g, %xff) and the upper-case form
> (e.g., %xFF); the former is not according to RFC2234 (which doesn't really
> bother me that much), but mixing the lower-case form and the upper-case form
> makes me wonder whether there is some significance in the use of lower-case
> vs. upper-case.

Lower case is wrong. Fixed. Thanks for noticing this.

--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: Mon, 21 Feb 2005 06:12:35 +0000
Date: Sun, 20 Feb 2005 22:11:32 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: Re: updated MIBs for RFC3576

Thanks.  Will you be available to present them in Minneapolis?

On Sun, 20 Feb 2005 [email-masked] wrote:

>
> Hi,
>
> Updated versions of the MIBs for RFC3576 are now available at
>
> http://www.ietf.org/internet-drafts/draft-decnodder-radext-dynauth-server-mib-03.txt
>
> and
>
> http://www.ietf.org/internet-drafts/draft-decnodder-radext-dynauth-client-mib-03.txt
>
> These updated versions include all comments from Dan and Bert (issues
> 31, 44, 45, and 48).
>
> regards,
>
> Stefaan
>
>
> --
> to unsubscribe send 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, 20 Feb 2005 23:41:54 +0000
Content-class: urn:content-classes:message
Subject: RE: Strawman Agenda for IETF 62
Date: Sun, 20 Feb 2005 15:41:23 -0800
From: "Adrangi, Farid" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>

We would like the following drafts to included in the agenda as well.

http://www.ietf.org/internet-drafts/draft-lior-radext-end-to-end-caps-00
.txt

http://www.ietf.org/internet-drafts/draft-lior-radius-bandwidth-capabili
ty-00.txt

Thanks,
Farid

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Sunday, February 20, 2005 2:26 PM
> To: [email-masked]
> Subject: Strawman Agenda for IETF 62
>=20
>=20
> Preliminaries (10 minutes)
>  Blue Sheets
>  Minutes
>  Document Status
>  Issue Status
>=20
> Completed IETF Last Call
>=20
> RFC 2486bis, Jari Arkko (10 minutes)
> http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2486b
is-03.txt

In WG Last Call (to end March 14, 2005)

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

WG Work Items

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

In Pre-Work Item Review

RADIUS MIB Revision, David Nelson (10 minutes)
http://www.ietf.org/internet-drafts/draft-nelson-rfc2618bis-00.txt
http://www.ietf.org/internet-drafts/draft-nelson-rfc2619bis-00.txt
http://www.ietf.org/internet-drafts/draft-nelson-rfc2620bis-00.txt
http://www.ietf.org/internet-drafts/draft-nelson-rfc2621bis-00.txt

RFC 3576 MIBs, TBD (10 minutes)
http://www.ietf.org/internet-drafts/draft-decnodder-radext-dynauth-clien
t-mib-04.txt
http://www.ietf.org/internet-drafts/draft-decnodder-radext-dynauth-serve
r-mib-04.txt

RADIUS Extensions for IEEE 802, Mauricio Sanchez (10 minutes)
http://www.ietf.org/internet-drafts/draft-congdon-radext-ieee802-03.txt

RADIUS Extensions for Management Authorization, David Nelson (10
Minutes)
TBD

Issues and Fixes, David Nelson (10 minutes)
http://www.drizzle.com/~aboba/RADEXT/

RADIUS Location, Hannes Tschofenig (10 minutes)
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius-lo-02.txt

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

--
to unsubscribe send 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, 20 Feb 2005 22:26:48 +0000
Date: Sun, 20 Feb 2005 14:26:18 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Strawman Agenda for IETF 62

Preliminaries (10 minutes)
 Blue Sheets
 Minutes
 Document Status
 Issue Status

Completed IETF Last Call

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

In WG Last Call (to end March 14, 2005)

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

WG Work Items

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

In Pre-Work Item Review

RADIUS MIB Revision, David Nelson (10 minutes)
http://www.ietf.org/internet-drafts/draft-nelson-rfc2618bis-00.txt
http://www.ietf.org/internet-drafts/draft-nelson-rfc2619bis-00.txt
http://www.ietf.org/internet-drafts/draft-nelson-rfc2620bis-00.txt
http://www.ietf.org/internet-drafts/draft-nelson-rfc2621bis-00.txt

RFC 3576 MIBs, TBD (10 minutes)
http://www.ietf.org/internet-drafts/draft-decnodder-radext-dynauth-client-mib-04.txt
http://www.ietf.org/internet-drafts/draft-decnodder-radext-dynauth-server-mib-04.txt

RADIUS Extensions for IEEE 802, Mauricio Sanchez (10 minutes)
http://www.ietf.org/internet-drafts/draft-congdon-radext-ieee802-03.txt

RADIUS Extensions for Management Authorization, David Nelson (10 Minutes)
TBD

Issues and Fixes, David Nelson (10 minutes)
http://www.drizzle.com/~aboba/RADEXT/

RADIUS Location, Hannes Tschofenig (10 minutes)
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius-lo-02.txt

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

Delivery-date: Sun, 20 Feb 2005 17:07:44 +0000
Date: Sun, 20 Feb 2005 18:07:22 +0100
From: [email-masked]
To: [email-masked]
Subject: updated MIBs for RFC3576

Hi,

Updated versions of the MIBs for RFC3576 are now available at

http://www.ietf.org/internet-drafts/draft-decnodder-radext-dynauth-server-mib-03.txt

and

http://www.ietf.org/internet-drafts/draft-decnodder-radext-dynauth-client-mib-03.txt

These updated versions include all comments from Dan and Bert (issues 
31, 44, 45, and 48).

regards,

Stefaan

--
to unsubscribe send 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, 20 Feb 2005 15:49:30 +0000
Date: Sun, 20 Feb 2005 07:48:55 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: RADEXT WG Last Call on RADIUS Extension for Digest Authentication

This is an announcement of RADEXT WG last call on "RADIUS Extension
for Digest Authentication" prior to sending the document to the IESG
for consideration as a Proposed Standard.

The document will be available on the IETF archive here:
http://www.ietf.org/internet-drafts/draft-ietf-radext-digest-auth-01.txt

Prior to its arrival on the archive, it can be retrieved here:
http://www.drizzle.com/~aboba/RADEXT/draft-ietf-radext-digest-auth-01.txt

RADEXT WG Last Call will last until March 14, 2005.  Please send comments
to the RADEXT WG mailing list ([email-masked]), so that they can
be tracked.

Note that the AAA WG is simultaneously requesting a WG Last Call
on the "Diameter SIP Application" document, to end on
the same day.  Since both documents need to remain in sync to ensure
interoperation between RADIUS and Diameter, we encourage participants in
both the AAA and RADEXT WGs to read both documents and comment on them.

--
to unsubscribe send 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, 19 Feb 2005 01:56:16 +0000
Content-class: urn:content-classes:message
Subject: CUI Version 03 submitted
Date: Fri, 18 Feb 2005 17:55:28 -0800
From: "Adrangi, Farid" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>

Bernard, all

Proposed text and comments included in Issue 66 (see below) were
incorporated into version -03.  I just submitted version -03.  Until
this version appears on the I-D repository, you can find it here:
http://mng.ctgisp.com/IETF/RADIUSEXT/draft-ietf-radext-chargeable-user-i
d-03.txt.

Thanks,
Farid

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Monday, February 14, 2005 8:31 AM
> To: [email-masked]
> Subject: [Issue 66]: Review of CUI-02
>=20
>=20
> Issue 66: Review of CUI-02
> Submitter name: Bernard Aboba
> Submitter email address: [email-masked]
> Date first submitted: February 14, 2005
> Reference:
> Document: CUI-02
> Comment type: T
> Priority: S
> Section: Various
> Rationale/Explanation of issue:
>=20
> Section 1
>=20
> "  Several organizations, including WISPr, GSMA, 3GPP, Wi-Fi Alliance,
>    IRAP, have been studying mechanisms to provide roaming services,
>    using RADIUS.  One missing element is a mechanism for providing the
>    current deployments with the capacity to deploy, bill and=20
> oversee WPA
>    networks against fraud.
>=20
>    The CUI attribute is intended to close operational loopholes in
>    RADIUS specifications that have impacted roaming solutions
>    negatively, especially when tunneled protocols with multiple
>    identities, such as PEAP or TTLS, are used.  Use of the=20
> CUI is geared
>    to multi-identity EAP authentications which are, for the most part,
>    recent deployments.  A chargeable identity reflecting the user
>    profile authenticated by the home network is needed in such roaming
>    scenarios."
>=20
> Why is usage of CUI specific to WPA, as opposed to say, WPA2 or WEP?
> For example, couldn't CUI be useful on PPP dialup networks=20
> authenticating
> via EAP?  Here is my suggested rewrite:
>=20
> "  Several organizations, including WISPr, GSMA, 3GPP, Wi-Fi Alliance,
>    IRAP, have been studying mechanisms to provide roaming services,
>    using RADIUS.  Missing elements include mechanisms for billing and
>    fraud prevention.
>=20
>    The CUI attribute is intended to close operational loopholes in
>    RADIUS specifications that have impacted roaming solutions
>    negatively.  Use of the CUI is geared toward EAP methods supporting
>    privacy (such as PEAP and EAP-TTLS), which are, for the most part,
>    recent deployments.  A chargeable identity reflecting the user
>    profile authenticated by the home network is needed in such roaming
>    scenarios."
>=20
> Section 1.1
>=20
> "  The CUI attribute provides a solution to the above problem=20
> and avoids
>    overloading the use of current RADIUS attributes (e.g.,=20
> User-Name(1)
>    re-write).  The CUI is the correct standards-based=20
> approach to fixing
>    the problems which have arisen with multiple-identity RADIUS
>    authorization and accounting methods.  It does not solve=20
> all related
>    problems, but does provide networks the ability to bill and oversee
>    WPA networks against fraud."
>=20
> Again, not sure why WPA is singled out.  Proposed revision:
>=20
> "  The CUI attribute provides a solution to the above=20
> problems and avoids
>    overloading (User-Name) or changing the usage of existing
>    RADIUS attributes (Class).  The CUI therefore provides a standard
>    approach to billing and fraud prevention when EAP methods=20
> supporting
>    privacy are used.  It does not solve all related
>    problems, but does provide for billing and fraud prevention."
>=20
> Section 2.1
>=20
> "Therefore whether a
> RADIUS server/proxy or client accepts or rejects the presence or lack
> of presence of the CUI attribute is a matter of business policy."
>=20
> Not sure what this means.  Since the NAS indicates whether it supports
> CUI, did you mean to say:
>=20
> "Therefore a RADIUS server supporting this specification may=20
> not choose
> to send the CUI in response to an Access-Request from a given=20
> NAS, even
> if the NAS has indicated that it supports CUI."
>=20
> Section 2.1
>=20
> "  If an Access-Accept packet without the CUI attribute was=20
> received by
>    a RADIUS client (NAS or Proxy) that requires the presence=20
> of the CUI
>    attribute, then the Access-Accept packet MAY be treated as an
>    Access-Reject packet based on local policies.
>=20
>    If the CUI was included in the Access-Accept packet, RADIUS client
>    (Proxy or NAS) that supports the CUI attribute MUST ensure that the
>    CUI attribute appears in the RADIUS Accounting-Request (Start,
>    Interim, and Stop)."
>=20
> The term "required" usually refers to a MUST, in which case MAY is too
> mild. Also, earlier you say that proxies may not modify the CUI; but I
> assume this does not apply to inserting it.
>=20
> Suggested rewrite:
>=20
> "  If an Access-Accept packet without the CUI attribute was=20
> received by
>    a RADIUS client that requested the CUI attribute, then the
>    Access-Accept packet MAY be treated as an Access-Reject.
>=20
>    If the CUI was included in an Access-Accept packet, RADIUS clients
>    supporting the CUI attribute MUST ensure that the CUI attribute
>    appears in the RADIUS Accounting-Request (Start, Interim,=20
> and Stop)."
>=20
> "   Therefore, RADIUS client or server that does not support the CUI
>     attribute MAY ignore this attribute.
>=20
>    If RADIUS client (Proxy or NAS) requires the presence of the CUI
>    attribute in the Access-Accept, it MUST indicate its requirement by
>    including the CUI attribute in the Access-Request packet=20
> with a value
>    set to the nul character (hereafter, it is also referred=20
> to as a nul
>    CUI)."
>=20
> I'd suggest you drop the upper case MAY here:
>=20
> "   Therefore, RADIUS clients or servers that do not support the CUI
>     may ignore the attribute.  A RADIUS client requesting the CUI
>     attribute in an Access-Accept MUST include within the=20
> Access-Request
>     a CUI attribute with a single NUL character (referred to as a nul
>     CUI)."
>=20
> "  A RADIUS server (a RADIUS proxy or the home RADIUS server) that
>    requires the presence of the CUI in the Accounting-Request packets
>    (Start, Stop, Interims) MAY respond with an Access-Reject packet if
>    it receives an Access-Request messsage from a RADIUS client, that
>    does not support the CUI attribute.  The Access-Reject packet MUST
>    include Error-Cause attribute [RFC3576] with value (to-be-defined)
>    (decimal), "CUI-Support-Required".
>=20
> This usage does not appear consistent with the only approved usage
> scenario, which is driven by RADIUS client requirements.  So far,
> the document has only made an argument that Class cannot be used by
> clients.  However, this paragraph implies that CUI can be used instead
> of Class in order to provide accounting information to servers.  That
> usage is out of scope.  I recommend that this paragraph be deleted.
>=20
> "   A summary of the RADIUS CUI Attribute is given below."
>=20
> Suggest a new section start prior to this section:
>=20
> "2.2  CUI Attribute
>=20
> A summary of the RADIUS CUI Attribute is given below."
>=20
> Section 5.2
>=20
> I don't see how this section relates to an approved scenario.  Suggest
> deleting it.
>=20
> Section 6.
>=20
> "   If the NAS includes CUI in an Access-Request.  A man in the middle
>    may remove the CUI attribute from the Access-Request.  The=20
> result is
>    that the Access-Accept will not have a CUI which will cause the NAS
>    to reject the session resulting in a DOS attack.  To prevent this
>    attack, the NAS SHOULD include Message-Authenticator(80) in the
>    Access-Request packets that contain a CUI."
>=20
> Suggest rewriting to:
>=20
> "  If the NAS includes CUI in an Access-Request, a man-in-the-middle
>    may remove it.  This will cause the Access-Accept to not include
>    a CUI attribute, which may cause the NAS to reject the session.
>    To prevent such a DoS attack, the NAS SHOULD include a
>    Message-Authenticator(80) attribute within Access-Request packets
>    containing a CUI attribute."
>=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: Fri, 18 Feb 2005 18:29:24 +0000
Date: Fri, 18 Feb 2005 10:28:45 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Update to IEEE 802 attributes draft

An update to the IEEE 802 attributes draft has been submitted.  Prior to
its appearance on the archive, you can obtain it at:

http://www.drizzle.com/~aboba/RADEXT/draft-congdon-radext-ieee802-03.txt

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

Delivery-date: Thu, 17 Feb 2005 22:43:56 +0000
Content-class: urn:content-classes:message
Subject: RADEXT Meeting at IETF 62
Date: Thu, 17 Feb 2005 17:41:15 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

The current *DRAFT* Agenda for IETF 62
http://www1.ietf.org/meetings/agenda_62.txt has RADEXT meeting on
Thursday, March 10, 2005 from 9:00 to 11:30 AM.  Please note that this
is *not* the final agenda, and our time slot might be changed.

--
to unsubscribe send 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, 15 Feb 2005 23:58:31 +0000
Reply-To: <[email-masked]>
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "'Alan DeKok'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: FW: I-D ACTION:draft-zorn-radius-encattr-00.txt 
Date: Tue, 15 Feb 2005 15:58:05 -0800

Alan DeKok <> supposedly scribbled:

> "Glen Zorn (gwz)" <[email-masked]> wrote:
>>>   This allows the Encrypted-Attribute to be "stand-alone", and
...
>> 
>> Yes, but the semantic validity of the encrypted data may, in
fact,
>> depend upon the integrity of unencrypted data, so it just seemed
>> better make sure the whole message arrived intact.
> 
>   Hmm... OK.
> 
>   Is there a security issue, then, with the clear-text data being
> related to the encrypted data?  Are there potential attacks? 

I don't think so (though I've never even played a cryptographer on
TV ;-).  The attributes are only semantically related, so for
example it would be bad if (to use the LI example) the User-Name
attribute were to be modified such that surveillance was turned off
(or on) for the wrong person, but the user name gives no hint as to
the contents of the encrypted attributes.

> 
>>> In
>>> addition, the Message-Authentication-Code has different
algorithms
>>> for different kinds of packets, which makes implementation a
little
>>> more awkward.
>> 
>> I don't understand.
> 
>   Sorry, not "different algorithms", but "different treatments".
> 
>   i.e. In order to to calculate the Message-Authentication-Code
for
> Access-Accept, you need the Request Authenticator, and the
attributes
> from the Access-Accept.  So the Message-Authentication-Code
> calculation requires access to information from multiple packets. 

Right, but the new version includes an optional but recommended
Nonce Attribute that solves that problem (among others), I think.
  
> 
>   My feeling is that a MAC in the Encrypted-Attribute feels better
to
> me, but I can see your arguments. 
> 
>   Just my $0.02.
> 
>   Alan DeKok.

Hope this helps,

~gwz

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

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

Envelope-to: [email-masked]
Delivery-date: Tue, 15 Feb 2005 23:06:14 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Subject: Re: FW: I-D ACTION:draft-zorn-radius-encattr-00.txt 
Date: Tue, 15 Feb 2005 18:01:09 -0500
Message-Id: <[email-masked]>

"Glen Zorn (gwz)" <[email-masked]> wrote:
> >   This allows the Encrypted-Attribute to be "stand-alone", and
...
> 
> Yes, but the semantic validity of the encrypted data may, in fact,
> depend upon the integrity of unencrypted data, so it just seemed
> better make sure the whole message arrived intact.

  Hmm... OK.

  Is there a security issue, then, with the clear-text data being
related to the encrypted data?  Are there potential attacks?

> > In
> > addition, the Message-Authentication-Code has different algorithms
> > for different kinds of packets, which makes implementation a
> > little  more awkward. 
> 
> I don't understand.

  Sorry, not "different algorithms", but "different treatments".

  i.e. In order to to calculate the Message-Authentication-Code for
Access-Accept, you need the Request Authenticator, and the attributes
from the Access-Accept.  So the Message-Authentication-Code
calculation requires access to information from multiple packets.

  My feeling is that a MAC in the Encrypted-Attribute feels better to
me, but I can see your arguments.

  Just my $0.02.

  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, 15 Feb 2005 21:45:17 +0000
Reply-To: <[email-masked]>
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "'Alan DeKok'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: FW: I-D ACTION:draft-zorn-radius-encattr-00.txt 
Date: Tue, 15 Feb 2005 13:44:33 -0800

Alan DeKok <> supposedly scribbled:

> "Glen Zorn (gwz)" <[email-masked]> wrote:
>> FYI, general-purpose scheme for
encrypting/transmitting/decrypting
>> arbitrary RADIUS attributes.
> 
>   Nice.  

Thank you!

> Minor nit: It references keywrap-03, which isn't in the I-D
> archive yet. 

Sequencing problem: it will be, shortly.

> 
>   Have you considered using a HMAC header as part of the
> Encrypted-Attribute, rather than a separate attribute? 
> 
>   e.g.    Encrypted-Attribute[s] = HMAC(encrypted_data) +
> encrypted_data 
> 
>   This allows the Encrypted-Attribute to be "stand-alone", and
avoids
> having the HMAC calculation depend on other, non-encrypted data.  

Yes, but the semantic validity of the encrypted data may, in fact,
depend upon the integrity of unencrypted data, so it just seemed
better make sure the whole message arrived intact.

> In
> addition, the Message-Authentication-Code has different algorithms
> for different kinds of packets, which makes implementation a
little
> more awkward. 

I don't understand.
   
> 
>   Having the Encrypted-Attribute contain its own HMAC ensures that
> it's calculation can be done with only "local" information about
the
> attributes to be encrypted, and not require any "outside" data
like
> authentication vectors or other attributes.   
> 
>   Alan DeKok.

Hope this helps,

~gwz

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

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

Envelope-to: [email-masked]
Delivery-date: Tue, 15 Feb 2005 19:34:38 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Subject: Re: FW: I-D ACTION:draft-zorn-radius-encattr-00.txt 
Date: Tue, 15 Feb 2005 14:29:34 -0500
Message-Id: <[email-masked]>

"Glen Zorn (gwz)" <[email-masked]> wrote:
> FYI, general-purpose scheme for encrypting/transmitting/decrypting
> arbitrary RADIUS attributes.

  Nice.  Minor nit: It references keywrap-03, which isn't in the I-D
archive yet.

  Have you considered using a HMAC header as part of the
Encrypted-Attribute, rather than a separate attribute?

  e.g.    Encrypted-Attribute[s] = HMAC(encrypted_data) + encrypted_data

  This allows the Encrypted-Attribute to be "stand-alone", and avoids
having the HMAC calculation depend on other, non-encrypted data.  In
addition, the Message-Authentication-Code has different algorithms for
different kinds of packets, which makes implementation a little more
awkward.

  Having the Encrypted-Attribute contain its own HMAC ensures that
it's calculation can be done with only "local" information about the
attributes to be encrypted, and not require any "outside" data like
authentication vectors or other attributes.

  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, 15 Feb 2005 19:15:27 +0000
Reply-To: <[email-masked]>
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: <[email-masked]>
Subject: FW: I-D ACTION:draft-zorn-radius-encattr-00.txt
Date: Tue, 15 Feb 2005 11:15:08 -0800

This is a multi-part message in MIME format.

------=_NextPart_000_039C_01C5134F.9C7BCB70
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

FYI, general-purpose scheme for encrypting/transmitting/decrypting
arbitrary RADIUS attributes.

> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. 
> 
> 
> 	Title		: Transmitting Confidential Data in RADIUS
> 	Author(s)	: G. Zorn, et al.
> 	Filename	: draft-zorn-radius-encattr-00.txt
> 	Pages		: 10
> 	Date		: 2005-2-14
> 
> This document defines a pair of RADIUS Attributes designed to
allow
>    the secure transmission of sensitive or confidential data
between
>    RADIUS clients and servers.
> 
> A URL for this Internet-Draft is:
>
http://www.ietf.org/internet-drafts/draft-zorn-radius-encattr-00.txt
> 
> To remove yourself from the I-D Announcement list, send a message
to
> [email-masked] with the word unsubscribe in the
body
> of the message.  
> You can also visit
https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
> 
> 
> 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-zorn-radius-encattr-00.txt".  
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html 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-zorn-radius-encattr-00.txt".
> 
> 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.
> 
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
--------------------------------------------------------------------
-----
> CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY
>
--------------------------------------------------------------------
-----
> In order to maintain computing infrastructure integrity, Cisco
Systems
> Enterprise Messaging Services and InfoSec teams have set a mail
policy
> disallowing executable attachments in email.
> 
> This message contained an executable attachment type that is
> prohibited 
> by this policy. The attachment has been removed from this message
and
> copied to quarantine by our systems. It will be held in quarantine
for
> seven days in the event that the content needs to be retrieved.
> 
> Please be aware many viruses attempt to look like legitimate email
or
> notifications from anti-virus systems. We will clearly mark a
> seperation 
> between our notifications and the original email as follows:
> 
>   "CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION
TECHNOLOGY"
> 
> For further reference information about viruses and email
antivirus
> efforts within Cisco, please visit:
> 
> http://wwwin.cisco.com/it/ems/services/antiviral
> 
> If your concern isn't addressed by the information in this
> notification 
> or the above web page, you may open a support request:
> 
> http://wwwin.cisco.com/support/
> 
> Select "Messaging", "Email-Related", "Mail Routing"
> 
> Please include in the text of your case the following information:
> 
> * Full headers of the message. Documentation on displaying the
full
> headers is available at this URL:
> 
> http://wwwin.cisco.com/support/library/faqs/solution002471.html
> 
> * This unique quarantine identifier: j1FIGLwU012341
> 
> If the matter is urgent, you may follow up by calling one of the
below
> referenced numbers. Please make every effort to provide the above
> requested information via the support web tool prior to calling as
it
> will greatly aid the resolution of your issue.
> 
> Americas:
> 1 408 526 8888
> 
> Asiapac
> +61 2 8446 8888
> 
> EMEA
> +31 20 485 4888
> 
> Japan
> +81 3 5549 6888
> 
> US (Toll Free)
> 1| 800| 888| 8187| (ext.68888)
> 
> Thank you for your cooperation,
> 
> Enterprise Messaging Services
> Cisco Systems, Inc

Hope this helps,

~gwz

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

------=_NextPart_000_039C_01C5134F.9C7BCB70
Content-Type: text/plain;
	name="ATT00772.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="ATT00772.txt"

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

------=_NextPart_000_039C_01C5134F.9C7BCB70--

--
to unsubscribe send 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, 15 Feb 2005 18:49:54 +0000
Content-class: urn:content-classes:message
Subject: RADIUS MIB Update I-Ds
Date: Tue, 15 Feb 2005 13:49:00 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

I would like to call the RADEXT WG's attention to four new Internet
Drafts:

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

These drafts propose to update their respective base RFCs by adding
support for IPv6 addressing formats in the respective RADIUS MIBs.  The
preference of the WG at IETF 60 was to update the existing RFCs rather
than obsolete them.

Please take some time to review these drafts and send comments to the
list.

Thanks!

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

Delivery-date: Tue, 15 Feb 2005 17:53:20 +0000
Reply-To: <[email-masked]>
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: <[email-masked]>
Subject: FW: I-D ACTION:draft-zorn-radius-err-msg-03.txt
Date: Tue, 15 Feb 2005 09:52:36 -0800

This is a multi-part message in MIME format.

------=_NextPart_000_02A0_01C51344.14D08180
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

FYI

> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. 
> 
> 
> 	Title		: RADIUS Error Messages
> 	Author(s)	: G. Zorn
> 	Filename	: draft-zorn-radius-err-msg-03.txt
> 	Pages		: 10
> 	Date		: 2005-2-14
> 
> This document describes new RADIUS protocol elements designed to
>    allow the communication of packet and attribute errors between
>    RADIUS servers and clients.
> 
> A URL for this Internet-Draft is:
>
http://www.ietf.org/internet-drafts/draft-zorn-radius-err-msg-03.txt
> 
> To remove yourself from the I-D Announcement list, send a message
to
> [email-masked] with the word unsubscribe in the
body
> of the message.  
> You can also visit
https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
> 
> 
> 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-zorn-radius-err-msg-03.txt".  
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html 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-zorn-radius-err-msg-03.txt".
> 
> 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.
> 
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
--------------------------------------------------------------------
-----
> CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY
>
--------------------------------------------------------------------
-----
> In order to maintain computing infrastructure integrity, Cisco
Systems
> Enterprise Messaging Services and InfoSec teams have set a mail
policy
> disallowing executable attachments in email.
> 
> This message contained an executable attachment type that is
> prohibited 
> by this policy. The attachment has been removed from this message
and
> copied to quarantine by our systems. It will be held in quarantine
for
> seven days in the event that the content needs to be retrieved.
> 
> Please be aware many viruses attempt to look like legitimate email
or
> notifications from anti-virus systems. We will clearly mark a
> seperation 
> between our notifications and the original email as follows:
> 
>   "CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION
TECHNOLOGY"
> 
> For further reference information about viruses and email
antivirus
> efforts within Cisco, please visit:
> 
> http://wwwin.cisco.com/it/ems/services/antiviral
> 
> If your concern isn't addressed by the information in this
> notification 
> or the above web page, you may open a support request:
> 
> http://wwwin.cisco.com/support/
> 
> Select "Messaging", "Email-Related", "Mail Routing"
> 
> Please include in the text of your case the following information:
> 
> * Full headers of the message. Documentation on displaying the
full
> headers is available at this URL:
> 
> http://wwwin.cisco.com/support/library/faqs/solution002471.html
> 
> * This unique quarantine identifier: j1FHZThm023716
> 
> If the matter is urgent, you may follow up by calling one of the
below
> referenced numbers. Please make every effort to provide the above
> requested information via the support web tool prior to calling as
it
> will greatly aid the resolution of your issue.
> 
> Americas:
> 1 408 526 8888
> 
> Asiapac
> +61 2 8446 8888
> 
> EMEA
> +31 20 485 4888
> 
> Japan
> +81 3 5549 6888
> 
> US (Toll Free)
> 1| 800| 888| 8187| (ext.68888)
> 
> Thank you for your cooperation,
> 
> Enterprise Messaging Services
> Cisco Systems, Inc

Hope this helps,

~gwz

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

------=_NextPart_000_02A0_01C51344.14D08180
Content-Type: text/plain;
	name="ATT00646.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="ATT00646.txt"

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

------=_NextPart_000_02A0_01C51344.14D08180--

--
to unsubscribe send 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, 15 Feb 2005 15:38:11 +0000
Date: Tue, 15 Feb 2005 07:37:54 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: CUI: Issue update? 

The issues list currently indicates that CUI-03, once posted, will have
no open issues:

http://www.drizzle.com/~aboba/RADEXT/

Once CUI-03 shows up on the archive, I would like to get confirmation that
in fact, all previously posted issues are closed.  If you have posted an
issue that is *not* addressed in CUI-03, please send the remaining
concerns to the list.

Assuming that there are no objections, and that new issues do not crop up,
it may be possible to start RADEXT WG last call on this document after
IETF 62.

--
to unsubscribe send 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, 15 Feb 2005 15:14:37 +0000
Content-class: urn:content-classes:message
Subject: Agenda for RADEXT at IETF 62
Date: Tue, 15 Feb 2005 10:13:16 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

RADEXT will meet at IETF 62 in Minneapolis.  We will have one 2.5 hour
meeting slot.  I hesitate to pre-announce the time and date, as we were
surprised in Washington by a last minute schedule change to 8 AM Monday.
The official IETF Agenda should be published soon.

It's not too early to solicit requests for RADEXT agenda time slots,
however.  If you have a presentation for RADEXT at IETF 62 please send a
message to the chairs, indicating the topic, the draft document name and
the desired number of minutes for your presentation.

--
to unsubscribe send 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, 15 Feb 2005 10:22:27 +0000
Content-class: urn:content-classes:message
Subject: RE: [Issue 66]: Review of CUI-02
Date: Tue, 15 Feb 2005 12:19:19 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Bernard,
> Section 1
>=20
> "  Several organizations, including WISPr, GSMA, 3GPP, Wi-Fi Alliance,
>    IRAP, have been studying mechanisms to provide roaming services,
>    using RADIUS.  One missing element is a mechanism for providing the
>    current deployments with the capacity to deploy, bill and oversee =
WPA
>    networks against fraud.
>=20
>    The CUI attribute is intended to close operational loopholes in
>    RADIUS specifications that have impacted roaming solutions
>    negatively, especially when tunneled protocols with multiple
>    identities, such as PEAP or TTLS, are used.  Use of the CUI is =
geared
>    to multi-identity EAP authentications which are, for the most part,
>    recent deployments.  A chargeable identity reflecting the user
>    profile authenticated by the home network is needed in such roaming
>    scenarios."
>=20
> Why is usage of CUI specific to WPA, as opposed to say, WPA2 or WEP?
> For example, couldn't CUI be useful on PPP dialup networks =
authenticating
> via EAP?  Here is my suggested rewrite:

It would be, the sample text is not meant to be exhaustive, so ...
>=20
> "  Several organizations, including WISPr, GSMA, 3GPP, Wi-Fi Alliance,
>    IRAP, have been studying mechanisms to provide roaming services,
>    using RADIUS.  Missing elements include mechanisms for billing and
>    fraud prevention.
>=20
>    The CUI attribute is intended to close operational loopholes in
>    RADIUS specifications that have impacted roaming solutions
>    negatively.  Use of the CUI is geared toward EAP methods supporting
>    privacy (such as PEAP and EAP-TTLS), which are, for the most part,
>    recent deployments.  A chargeable identity reflecting the user
>    profile authenticated by the home network is needed in such roaming
>    scenarios."

This looks OK to me.

> Section 1.1
>=20
> "  The CUI attribute provides a solution to the above problem and =
avoids
>    overloading the use of current RADIUS attributes (e.g., =
User-Name(1)
>    re-write).  The CUI is the correct standards-based approach to =
fixing
>    the problems which have arisen with multiple-identity RADIUS
>    authorization and accounting methods.  It does not solve all =
related
>    problems, but does provide networks the ability to bill and oversee
>    WPA networks against fraud."
>=20
> Again, not sure why WPA is singled out.  Proposed revision:
>=20
> "  The CUI attribute provides a solution to the above problems and =
avoids
>    overloading (User-Name) or changing the usage of existing
>    RADIUS attributes (Class).  The CUI therefore provides a standard
>    approach to billing and fraud prevention when EAP methods =
supporting
>    privacy are used.  It does not solve all related
>    problems, but does provide for billing and fraud prevention."

This looks OK to me as well.

> Section 2.1
>=20
> "Therefore whether a
> RADIUS server/proxy or client accepts or rejects the presence or lack
> of presence of the CUI attribute is a matter of business policy."
>=20
> Not sure what this means.  Since the NAS indicates whether it supports
> CUI, did you mean to say:
>=20
> "Therefore a RADIUS server supporting this specification may not =
choose
> to send the CUI in response to an Access-Request from a given NAS, =
even
> if the NAS has indicated that it supports CUI."

That works for me.

> Section 2.1
>=20
> "  If an Access-Accept packet without the CUI attribute was received =
by
>    a RADIUS client (NAS or Proxy) that requires the presence of the =
CUI
>    attribute, then the Access-Accept packet MAY be treated as an
>    Access-Reject packet based on local policies.
>=20
>    If the CUI was included in the Access-Accept packet, RADIUS client
>    (Proxy or NAS) that supports the CUI attribute MUST ensure that the
>    CUI attribute appears in the RADIUS Accounting-Request (Start,
>    Interim, and Stop)."
>=20
> The term "required" usually refers to a MUST, in which case MAY is too
> mild. Also, earlier you say that proxies may not modify the CUI; but I
> assume this does not apply to inserting it.
>=20
> Suggested rewrite:
>=20
> "  If an Access-Accept packet without the CUI attribute was received =
by
>    a RADIUS client that requested the CUI attribute, then the
>    Access-Accept packet MAY be treated as an Access-Reject.
>=20
>    If the CUI was included in an Access-Accept packet, RADIUS clients
>    supporting the CUI attribute MUST ensure that the CUI attribute
>    appears in the RADIUS Accounting-Request (Start, Interim, and =
Stop)."

I think that is better.

> "   Therefore, RADIUS client or server that does not support the CUI
>     attribute MAY ignore this attribute.
>=20
>    If RADIUS client (Proxy or NAS) requires the presence of the CUI
>    attribute in the Access-Accept, it MUST indicate its requirement by
>    including the CUI attribute in the Access-Request packet with a =
value
>    set to the nul character (hereafter, it is also referred to as a =
nul
>    CUI)."
>=20
> I'd suggest you drop the upper case MAY here:
>=20
> "   Therefore, RADIUS clients or servers that do not support the CUI
>     may ignore the attribute.  A RADIUS client requesting the CUI
>     attribute in an Access-Accept MUST include within the =
Access-Request
>     a CUI attribute with a single NUL character (referred to as a nul
>     CUI)."

OK with me.

> "  A RADIUS server (a RADIUS proxy or the home RADIUS server) that
>    requires the presence of the CUI in the Accounting-Request packets
>    (Start, Stop, Interims) MAY respond with an Access-Reject packet if
>    it receives an Access-Request messsage from a RADIUS client, that
>    does not support the CUI attribute.  The Access-Reject packet MUST
>    include Error-Cause attribute [RFC3576] with value (to-be-defined)
>    (decimal), "CUI-Support-Required".
>=20
> This usage does not appear consistent with the only approved usage
> scenario, which is driven by RADIUS client requirements.  So far,
> the document has only made an argument that Class cannot be used by
> clients.  However, this paragraph implies that CUI can be used instead
> of Class in order to provide accounting information to servers.  That
> usage is out of scope.  I recommend that this paragraph be deleted.

OK.
=20
> "   A summary of the RADIUS CUI Attribute is given below."
>=20
> Suggest a new section start prior to this section:
>=20
> "2.2  CUI Attribute
>=20
> A summary of the RADIUS CUI Attribute is given below."

OK.

> Section 5.2
>=20
> I don't see how this section relates to an approved scenario.  Suggest
> deleting it.

OK.

> Section 6.
>=20
> "   If the NAS includes CUI in an Access-Request.  A man in the middle
>    may remove the CUI attribute from the Access-Request.  The result =
is
>    that the Access-Accept will not have a CUI which will cause the NAS
>    to reject the session resulting in a DOS attack.  To prevent this
>    attack, the NAS SHOULD include Message-Authenticator(80) in the
>    Access-Request packets that contain a CUI."
>=20
> Suggest rewriting to:
>=20
> "  If the NAS includes CUI in an Access-Request, a man-in-the-middle
>    may remove it.  This will cause the Access-Accept to not include
>    a CUI attribute, which may cause the NAS to reject the session.
>    To prevent such a DoS attack, the NAS SHOULD include a
>    Message-Authenticator(80) attribute within Access-Request packets
>    containing a CUI attribute."

That is better.

Thanks for the text.
John

--
to unsubscribe send 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, 15 Feb 2005 07:38:20 +0000
Content-class: urn:content-classes:message
Subject: RE: [Issue 66]: Review of CUI-02
Date: Mon, 14 Feb 2005 23:36:06 -0800
From: "Adrangi, Farid" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>

Hi Bernard,
Thanks for your review.  I think these are good and fair comments.  Will
incorporate them into -03 verison, and submit it shortly.
Thanks,
Farid

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Monday, February 14, 2005 8:31 AM
> To: [email-masked]
> Subject: [Issue 66]: Review of CUI-02
>=20
>=20
> Issue 66: Review of CUI-02
> Submitter name: Bernard Aboba
> Submitter email address: [email-masked]
> Date first submitted: February 14, 2005
> Reference:
> Document: CUI-02
> Comment type: T
> Priority: S
> Section: Various
> Rationale/Explanation of issue:
>=20
> Section 1
>=20
> "  Several organizations, including WISPr, GSMA, 3GPP, Wi-Fi Alliance,
>    IRAP, have been studying mechanisms to provide roaming services,
>    using RADIUS.  One missing element is a mechanism for providing the
>    current deployments with the capacity to deploy, bill and=20
> oversee WPA
>    networks against fraud.
>=20
>    The CUI attribute is intended to close operational loopholes in
>    RADIUS specifications that have impacted roaming solutions
>    negatively, especially when tunneled protocols with multiple
>    identities, such as PEAP or TTLS, are used.  Use of the=20
> CUI is geared
>    to multi-identity EAP authentications which are, for the most part,
>    recent deployments.  A chargeable identity reflecting the user
>    profile authenticated by the home network is needed in such roaming
>    scenarios."
>=20
> Why is usage of CUI specific to WPA, as opposed to say, WPA2 or WEP?
> For example, couldn't CUI be useful on PPP dialup networks=20
> authenticating
> via EAP?  Here is my suggested rewrite:
>=20
> "  Several organizations, including WISPr, GSMA, 3GPP, Wi-Fi Alliance,
>    IRAP, have been studying mechanisms to provide roaming services,
>    using RADIUS.  Missing elements include mechanisms for billing and
>    fraud prevention.
>=20
>    The CUI attribute is intended to close operational loopholes in
>    RADIUS specifications that have impacted roaming solutions
>    negatively.  Use of the CUI is geared toward EAP methods supporting
>    privacy (such as PEAP and EAP-TTLS), which are, for the most part,
>    recent deployments.  A chargeable identity reflecting the user
>    profile authenticated by the home network is needed in such roaming
>    scenarios."
>=20
> Section 1.1
>=20
> "  The CUI attribute provides a solution to the above problem=20
> and avoids
>    overloading the use of current RADIUS attributes (e.g.,=20
> User-Name(1)
>    re-write).  The CUI is the correct standards-based=20
> approach to fixing
>    the problems which have arisen with multiple-identity RADIUS
>    authorization and accounting methods.  It does not solve=20
> all related
>    problems, but does provide networks the ability to bill and oversee
>    WPA networks against fraud."
>=20
> Again, not sure why WPA is singled out.  Proposed revision:
>=20
> "  The CUI attribute provides a solution to the above=20
> problems and avoids
>    overloading (User-Name) or changing the usage of existing
>    RADIUS attributes (Class).  The CUI therefore provides a standard
>    approach to billing and fraud prevention when EAP methods=20
> supporting
>    privacy are used.  It does not solve all related
>    problems, but does provide for billing and fraud prevention."
>=20
> Section 2.1
>=20
> "Therefore whether a
> RADIUS server/proxy or client accepts or rejects the presence or lack
> of presence of the CUI attribute is a matter of business policy."
>=20
> Not sure what this means.  Since the NAS indicates whether it supports
> CUI, did you mean to say:
>=20
> "Therefore a RADIUS server supporting this specification may=20
> not choose
> to send the CUI in response to an Access-Request from a given=20
> NAS, even
> if the NAS has indicated that it supports CUI."
>=20
> Section 2.1
>=20
> "  If an Access-Accept packet without the CUI attribute was=20
> received by
>    a RADIUS client (NAS or Proxy) that requires the presence=20
> of the CUI
>    attribute, then the Access-Accept packet MAY be treated as an
>    Access-Reject packet based on local policies.
>=20
>    If the CUI was included in the Access-Accept packet, RADIUS client
>    (Proxy or NAS) that supports the CUI attribute MUST ensure that the
>    CUI attribute appears in the RADIUS Accounting-Request (Start,
>    Interim, and Stop)."
>=20
> The term "required" usually refers to a MUST, in which case MAY is too
> mild. Also, earlier you say that proxies may not modify the CUI; but I
> assume this does not apply to inserting it.
>=20
> Suggested rewrite:
>=20
> "  If an Access-Accept packet without the CUI attribute was=20
> received by
>    a RADIUS client that requested the CUI attribute, then the
>    Access-Accept packet MAY be treated as an Access-Reject.
>=20
>    If the CUI was included in an Access-Accept packet, RADIUS clients
>    supporting the CUI attribute MUST ensure that the CUI attribute
>    appears in the RADIUS Accounting-Request (Start, Interim,=20
> and Stop)."
>=20
> "   Therefore, RADIUS client or server that does not support the CUI
>     attribute MAY ignore this attribute.
>=20
>    If RADIUS client (Proxy or NAS) requires the presence of the CUI
>    attribute in the Access-Accept, it MUST indicate its requirement by
>    including the CUI attribute in the Access-Request packet=20
> with a value
>    set to the nul character (hereafter, it is also referred=20
> to as a nul
>    CUI)."
>=20
> I'd suggest you drop the upper case MAY here:
>=20
> "   Therefore, RADIUS clients or servers that do not support the CUI
>     may ignore the attribute.  A RADIUS client requesting the CUI
>     attribute in an Access-Accept MUST include within the=20
> Access-Request
>     a CUI attribute with a single NUL character (referred to as a nul
>     CUI)."
>=20
> "  A RADIUS server (a RADIUS proxy or the home RADIUS server) that
>    requires the presence of the CUI in the Accounting-Request packets
>    (Start, Stop, Interims) MAY respond with an Access-Reject packet if
>    it receives an Access-Request messsage from a RADIUS client, that
>    does not support the CUI attribute.  The Access-Reject packet MUST
>    include Error-Cause attribute [RFC3576] with value (to-be-defined)
>    (decimal), "CUI-Support-Required".
>=20
> This usage does not appear consistent with the only approved usage
> scenario, which is driven by RADIUS client requirements.  So far,
> the document has only made an argument that Class cannot be used by
> clients.  However, this paragraph implies that CUI can be used instead
> of Class in order to provide accounting information to servers.  That
> usage is out of scope.  I recommend that this paragraph be deleted.
>=20
> "   A summary of the RADIUS CUI Attribute is given below."
>=20
> Suggest a new section start prior to this section:
>=20
> "2.2  CUI Attribute
>=20
> A summary of the RADIUS CUI Attribute is given below."
>=20
> Section 5.2
>=20
> I don't see how this section relates to an approved scenario.  Suggest
> deleting it.
>=20
> Section 6.
>=20
> "   If the NAS includes CUI in an Access-Request.  A man in the middle
>    may remove the CUI attribute from the Access-Request.  The=20
> result is
>    that the Access-Accept will not have a CUI which will cause the NAS
>    to reject the session resulting in a DOS attack.  To prevent this
>    attack, the NAS SHOULD include Message-Authenticator(80) in the
>    Access-Request packets that contain a CUI."
>=20
> Suggest rewriting to:
>=20
> "  If the NAS includes CUI in an Access-Request, a man-in-the-middle
>    may remove it.  This will cause the Access-Accept to not include
>    a CUI attribute, which may cause the NAS to reject the session.
>    To prevent such a DoS attack, the NAS SHOULD include a
>    Message-Authenticator(80) attribute within Access-Request packets
>    containing a CUI attribute."
>=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, 14 Feb 2005 16:31:28 +0000
Date: Mon, 14 Feb 2005 08:30:54 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: [Issue 66]: Review of CUI-02

Issue 66: Review of CUI-02
Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: February 14, 2005
Reference:
Document: CUI-02
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:

Section 1

"  Several organizations, including WISPr, GSMA, 3GPP, Wi-Fi Alliance,
   IRAP, have been studying mechanisms to provide roaming services,
   using RADIUS.  One missing element is a mechanism for providing the
   current deployments with the capacity to deploy, bill and oversee WPA
   networks against fraud.

   The CUI attribute is intended to close operational loopholes in
   RADIUS specifications that have impacted roaming solutions
   negatively, especially when tunneled protocols with multiple
   identities, such as PEAP or TTLS, are used.  Use of the CUI is geared
   to multi-identity EAP authentications which are, for the most part,
   recent deployments.  A chargeable identity reflecting the user
   profile authenticated by the home network is needed in such roaming
   scenarios."

Why is usage of CUI specific to WPA, as opposed to say, WPA2 or WEP?
For example, couldn't CUI be useful on PPP dialup networks authenticating
via EAP?  Here is my suggested rewrite:

"  Several organizations, including WISPr, GSMA, 3GPP, Wi-Fi Alliance,
   IRAP, have been studying mechanisms to provide roaming services,
   using RADIUS.  Missing elements include mechanisms for billing and
   fraud prevention.

   The CUI attribute is intended to close operational loopholes in
   RADIUS specifications that have impacted roaming solutions
   negatively.  Use of the CUI is geared toward EAP methods supporting
   privacy (such as PEAP and EAP-TTLS), which are, for the most part,
   recent deployments.  A chargeable identity reflecting the user
   profile authenticated by the home network is needed in such roaming
   scenarios."

Section 1.1

"  The CUI attribute provides a solution to the above problem and avoids
   overloading the use of current RADIUS attributes (e.g., User-Name(1)
   re-write).  The CUI is the correct standards-based approach to fixing
   the problems which have arisen with multiple-identity RADIUS
   authorization and accounting methods.  It does not solve all related
   problems, but does provide networks the ability to bill and oversee
   WPA networks against fraud."

Again, not sure why WPA is singled out.  Proposed revision:

"  The CUI attribute provides a solution to the above problems and avoids
   overloading (User-Name) or changing the usage of existing
   RADIUS attributes (Class).  The CUI therefore provides a standard
   approach to billing and fraud prevention when EAP methods supporting
   privacy are used.  It does not solve all related
   problems, but does provide for billing and fraud prevention."

Section 2.1

"Therefore whether a
RADIUS server/proxy or client accepts or rejects the presence or lack
of presence of the CUI attribute is a matter of business policy."

Not sure what this means.  Since the NAS indicates whether it supports
CUI, did you mean to say:

"Therefore a RADIUS server supporting this specification may not choose
to send the CUI in response to an Access-Request from a given NAS, even
if the NAS has indicated that it supports CUI."

Section 2.1

"  If an Access-Accept packet without the CUI attribute was received by
   a RADIUS client (NAS or Proxy) that requires the presence of the CUI
   attribute, then the Access-Accept packet MAY be treated as an
   Access-Reject packet based on local policies.

   If the CUI was included in the Access-Accept packet, RADIUS client
   (Proxy or NAS) that supports the CUI attribute MUST ensure that the
   CUI attribute appears in the RADIUS Accounting-Request (Start,
   Interim, and Stop)."

The term "required" usually refers to a MUST, in which case MAY is too
mild. Also, earlier you say that proxies may not modify the CUI; but I
assume this does not apply to inserting it.

Suggested rewrite:

"  If an Access-Accept packet without the CUI attribute was received by
   a RADIUS client that requested the CUI attribute, then the
   Access-Accept packet MAY be treated as an Access-Reject.

   If the CUI was included in an Access-Accept packet, RADIUS clients
   supporting the CUI attribute MUST ensure that the CUI attribute
   appears in the RADIUS Accounting-Request (Start, Interim, and Stop)."

"   Therefore, RADIUS client or server that does not support the CUI
    attribute MAY ignore this attribute.

   If RADIUS client (Proxy or NAS) requires the presence of the CUI
   attribute in the Access-Accept, it MUST indicate its requirement by
   including the CUI attribute in the Access-Request packet with a value
   set to the nul character (hereafter, it is also referred to as a nul
   CUI)."

I'd suggest you drop the upper case MAY here:

"   Therefore, RADIUS clients or servers that do not support the CUI
    may ignore the attribute.  A RADIUS client requesting the CUI
    attribute in an Access-Accept MUST include within the Access-Request
    a CUI attribute with a single NUL character (referred to as a nul
    CUI)."

"  A RADIUS server (a RADIUS proxy or the home RADIUS server) that
   requires the presence of the CUI in the Accounting-Request packets
   (Start, Stop, Interims) MAY respond with an Access-Reject packet if
   it receives an Access-Request messsage from a RADIUS client, that
   does not support the CUI attribute.  The Access-Reject packet MUST
   include Error-Cause attribute [RFC3576] with value (to-be-defined)
   (decimal), "CUI-Support-Required".

This usage does not appear consistent with the only approved usage
scenario, which is driven by RADIUS client requirements.  So far,
the document has only made an argument that Class cannot be used by
clients.  However, this paragraph implies that CUI can be used instead
of Class in order to provide accounting information to servers.  That
usage is out of scope.  I recommend that this paragraph be deleted.

"   A summary of the RADIUS CUI Attribute is given below."

Suggest a new section start prior to this section:

"2.2  CUI Attribute

A summary of the RADIUS CUI Attribute is given below."

Section 5.2

I don't see how this section relates to an approved scenario.  Suggest
deleting it.

Section 6.

"   If the NAS includes CUI in an Access-Request.  A man in the middle
   may remove the CUI attribute from the Access-Request.  The result is
   that the Access-Accept will not have a CUI which will cause the NAS
   to reject the session resulting in a DOS attack.  To prevent this
   attack, the NAS SHOULD include Message-Authenticator(80) in the
   Access-Request packets that contain a CUI."

Suggest rewriting to:

"  If the NAS includes CUI in an Access-Request, a man-in-the-middle
   may remove it.  This will cause the Access-Accept to not include
   a CUI attribute, which may cause the NAS to reject the session.
   To prevent such a DoS attack, the NAS SHOULD include a
   Message-Authenticator(80) attribute within Access-Request packets
   containing a CUI attribute."

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

Delivery-date: Mon, 14 Feb 2005 14:01:26 +0000
From: "Beck01, Wolfgang" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: AW: digest-auth: proposed text for SIP-AOR, Realm
Date: Mon, 14 Feb 2005 15:00:53 +0100

Hi Miguel,

> I am fine with the current text. I have a minor improvement: since the 
> purpose of the atttribute is two fold, authentication and authorization, 
> I would suggest to add the "authorization" bit to the description of the 
> attribute:
> 
>        The SIP-AOR attribute identifies the URI the use of which must
>        be authenticated and authorized.
>                         ^^^^^^^^^^^^^^^
Good point, I will change it.

Wolfgang

--
T-Systems
Internet Platforms
+49 6151 937 2863
Am Kavalleriesand 3
64295 Darmstadt
Germany 

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

Delivery-date: Mon, 14 Feb 2005 13:19:12 +0000
Date: Mon, 14 Feb 2005 15:17:29 +0200
From: Miguel Garcia <[email-masked]>
To: [email-masked], "" <[email-masked]>
CC: [email-masked]
Subject: Re: digest-auth: proposed text for SIP-AOR, Realm

Hi Wolfgang:

I am fine with the current text. I have a minor improvement: since the 
purpose of the atttribute is two fold, authentication and authorization, 
I would suggest to add the "authorization" bit to the description of the 
attribute:

       The SIP-AOR attribute identifies the URI the use of which must
       be authenticated and authorized.
                        ^^^^^^^^^^^^^^^

BR,

      Miguel

Beck01, Wolfgang wrote:

> to close issue 53, I propose the following text:
> 
> 2.20  SIP-AOR
> 
>    This attribute is for the authorization of SIP messages.
> 
>    Type
>          [IANA:use 121 if possible] for SIP-AOR
>    Length
>          >=3
>    String
>          The syntax of this attribute corresponds either to a SIP URI
>          (with the format defined in [RFC3261] or a TEL URI (with the
>          format defined in [RFC3966]).
>          The SIP-AOR attribute identifies the URI the use of which must
>          be authenticated.  The RADIUS server uses this attribute to
>          authorize the processing of the SIP request.  The SIP-AOR can
>          be derived from, e.g., the To header field in a SIP REGISTER
>          request (user under registration), or the From header field in
>          other SIP requests.  However, the exact mapping of this
>          attribute to SIP can change due to new developments in the
>          protocol.
>          This attribute MUST only be used when the RADIUS client wants
>          to authorize SIP users and MUST only be used in Access-Request
>          messages.
> 
> Issue 43, choosing the correct credentials from a set of authorization headers:
> 
> RADIUS Client Behaviour
> [..] 
> On reception of an HTTP-style request message, the RADIUS client checks
> whether it is responsible to authenticate the request.
> There are situation where an HTTP-style request traverses several proxies,
> and each of the proxies request to authenticate the HTTP-style client. In
> this situation, it is a valid scenario that a HTTP-style request received
> at a HTTP-style server contains several sets of credentials. The 'realm'
> directive in HTTP is the key that the RADIUS client can use to determine
> which credential is applicable. It may happen also that none of the
> realms are of interests to the RADIUS client, in which case the RADIUS
> client MUST consider that no credentials (of interest) were sent. In
> any case, a RADIUS client MUST send zero or exactly one credential to
> the RADIUS server. The RADIUS client MUST choose the credential of the
> (Proxy-)Authorization header where the realm directive matches its locally
> configured realm value.  If such a header is present and contains HTTP
> digest information, the RADIUS client checks the 'nonce' parameter.
> If the RADIUS client generates nonces but did not issue the received
> nonce, it responds with a 401 (Unauthorized) or 407 (Proxy Authentication
> Required) to the HTTP-style client. In this error response, the RADIUS
> client sends a new nonce.
> 
> 
> Wolfgang
> 
> --
> T-Systems
> Internet Platforms
> +49 6151 937 2863
> Am Kavalleriesand 3
> 64295 Darmstadt
> Germany 

-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Research Center      Helsinki, Finland

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

Delivery-date: Mon, 14 Feb 2005 09:21:22 +0000
From: "Beck01, Wolfgang" <[email-masked]>
To: [email-masked], [email-masked]
Subject: radius-digest-auth: Issue 11
Date: Mon, 14 Feb 2005 10:21:10 +0100

Hi Jari,

on http://www.drizzle.com/~aboba/RADEXT/, issue 11 is still marked
as 'open'. Most of this has been addressed in
http://www.ietf.org/internet-drafts/draft-ietf-radext-digest-auth-00.txt.
One remaining thing is your concern about the interoperation of RADIUS
clients and servers that may or may not support nonce generation.

Here's a proposal:
"If the RADIUS server generates nonces, its RADIUS clients MUST NOT
try to generate nonces.  If the RADIUS server does not generate
nonces, its RADIUS clients MUST generate nonces locally.
If at least one HTTP-style client requires AKA authentication
[RFC3310], the RADIUS server MUST generate nonces and its RADIUS
clients MUST NOT generate nonces locally."

However, if a RADIUS client accidentally chooses a nonce:

"If the RADIUS server does not accept the nonce received in an
Access-Request message but authentication was successful, the RADIUS
server MUST send an Access-Challenge message containing a
Digest-Stale attribute set to 'true' (without quotes).  The RADIUS
server MUST add Digest-Nonce, Digest-Algorithm, Digest-Realm, SHOULD
add one or more Digest-Qop and MAY add Digest-Domain, Digest-Opaque
attributes to the Access-Challenge message."

and the RADIUS client will deal with it:
"  If the RADIUS client receives an Access-Challenge message in response
   to an Access-Request containing a Digest-Nonce attribute, the RADIUS
   server did not accept the nonce.  If a Digest-Stale attribute is
   present in the Access-Challenge and has a value of 'true' (without
   quotes), the RADIUS client sends an error (401 or 407) response
   containing WWW-/Proxy-Authenticate header with the directive 'stale'
   and the digest directives derived from the Digest-* attributes."

If neither RADIUS client nor RADIUS support nonce generation:
"  If the RADIUS server receives an Access-Request message with a
   Digest-Method and a Digest-URI attribute but without a Digest-Nonce
   attribute, it chooses a nonce.  [..] If the server cannot choose a
   nonce, it replies with an Access-Reject message."

To summarize, we don't want to mix modes but if you do, the behaviour
is predictable. If you RADIUS server supports nonce generation, you
are on the safe side.

Is this sufficient to close the issue?

Wolfgang

--
T-Systems
Internet Platforms
+49 6151 937 2863
Am Kavalleriesand 3
64295 Darmstadt
Germany 

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

Delivery-date: Mon, 14 Feb 2005 08:38:56 +0000
Date: Mon, 14 Feb 2005 10:36:37 +0200
From: Miguel Garcia <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: [AAA-WG]: AAA WG Last Call on Diameter SIP Application

A reminder:

The list of current open issues is stored at:

http://danforsberg.info:8080/draft-ietf-aaa-diameter-sip/

We have 7 issues listed there, all of them have proposed resolutions, I 
will be implementing them unless I hear voices against.

/Miguel

Bernard Aboba wrote:

> This is an announcement of a AAA WG last call on "Diameter SIP
> Application" prior to sending the document to the IESG for consideration
> as a Proposed Standard.
> 
> The document is available here:
> http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-sip-app-06.txt
> 
> AAA WG Last Call will last until March 14, 2005.  Please send comments to
> the AAA WG mailing list ([email-masked]), so that they can be tracked.
> 
> Note that the RADEXT WG will simultaneously be requesting a WG Last Call
> on the "RADIUS Extension for Digest Authentication" document, to end on
> the same day.  Since both documents need to remain in sync to ensure
> interoperation between RADIUS and Diameter, we encourage participants in
> both the AAA and RADEXT WGs to read both documents and comment on them.
> 

-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Research Center      Helsinki, Finland

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

Delivery-date: Mon, 14 Feb 2005 08:38:47 +0000
Date: Mon, 14 Feb 2005 10:34:24 +0200
From: Miguel Garcia <[email-masked]>
To: [email-masked]
CC: "Beck01, Wolfgang" <[email-masked]>, "Bernard Aboba" <[email-masked]>
Subject: Issus in Radius HTTP/SIP Digest authentication

Hi:

Review of the open issues initiated by me, all of them referring to 
draft-ietf-radext-digest-auth-00.txt

Issue #4
=========
This isssue was solved some time ago. It should be close now.

Issue #5
=========
Same as #4, close already now.

Issue #43
=========
This contained a bunch of editorials to the current version. Wolfgang 
has agreed on all, presumably they will be part of version -01.

Regards,

         Miguel

-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Research Center      Helsinki, Finland

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

Delivery-date: Mon, 14 Feb 2005 07:28:44 +0000
Content-class: urn:content-classes:message
Subject: RE: RADEXT issues list update
Date: Sun, 13 Feb 2005 23:28:03 -0800
From: "Adrangi, Farid" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>

Did you update CUI issue list?  I did not see any changes.  We submitted
version -02 a while ago which addressed a number of issues such as: 46,
49, 52.  13 should've been close a while ago.
Farid

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Sunday, February 13, 2005 2:33 PM
> To: [email-masked]
> Subject: RADEXT issues list update
>=20
>=20
> We are currently in the process of updating the RADEXT issue list:
> http://www.drizzle.com/~aboba/RADEXT
>=20
> As part of this process, we are requesting that document=20
> editors examine
> the list and send email if the status of an issue is not up to date.
>=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, 13 Feb 2005 22:33:16 +0000
Date: Sun, 13 Feb 2005 14:32:46 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: RADEXT issues list update

We are currently in the process of updating the RADEXT issue list:
http://www.drizzle.com/~aboba/RADEXT

As part of this process, we are requesting that document editors examine
the list and send email if the status of an issue is not up to date.

--
to unsubscribe send 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, 13 Feb 2005 20:27:21 +0000
From: "Beck01, Wolfgang" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: digest-auth: proposed text for SIP-AOR, Realm
Date: Sun, 13 Feb 2005 21:26:53 +0100

to close issue 53, I propose the following text:

2.20  SIP-AOR

   This attribute is for the authorization of SIP messages.

   Type
         [IANA:use 121 if possible] for SIP-AOR
   Length
         >=3
   String
         The syntax of this attribute corresponds either to a SIP URI
         (with the format defined in [RFC3261] or a TEL URI (with the
         format defined in [RFC3966]).
         The SIP-AOR attribute identifies the URI the use of which must
         be authenticated.  The RADIUS server uses this attribute to
         authorize the processing of the SIP request.  The SIP-AOR can
         be derived from, e.g., the To header field in a SIP REGISTER
         request (user under registration), or the From header field in
         other SIP requests.  However, the exact mapping of this
         attribute to SIP can change due to new developments in the
         protocol.
         This attribute MUST only be used when the RADIUS client wants
         to authorize SIP users and MUST only be used in Access-Request
         messages.

Issue 43, choosing the correct credentials from a set of authorization headers:

RADIUS Client Behaviour
[..] 
On reception of an HTTP-style request message, the RADIUS client checks
whether it is responsible to authenticate the request.
There are situation where an HTTP-style request traverses several proxies,
and each of the proxies request to authenticate the HTTP-style client. In
this situation, it is a valid scenario that a HTTP-style request received
at a HTTP-style server contains several sets of credentials. The 'realm'
directive in HTTP is the key that the RADIUS client can use to determine
which credential is applicable. It may happen also that none of the
realms are of interests to the RADIUS client, in which case the RADIUS
client MUST consider that no credentials (of interest) were sent. In
any case, a RADIUS client MUST send zero or exactly one credential to
the RADIUS server. The RADIUS client MUST choose the credential of the
(Proxy-)Authorization header where the realm directive matches its locally
configured realm value.  If such a header is present and contains HTTP
digest information, the RADIUS client checks the 'nonce' parameter.
If the RADIUS client generates nonces but did not issue the received
nonce, it responds with a 401 (Unauthorized) or 407 (Proxy Authentication
Required) to the HTTP-style client. In this error response, the RADIUS
client sends a new nonce.

Wolfgang

--
T-Systems
Internet Platforms
+49 6151 937 2863
Am Kavalleriesand 3
64295 Darmstadt
Germany 

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

Delivery-date: Sun, 13 Feb 2005 18:59:29 +0000
Date: Sun, 13 Feb 2005 10:58:48 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: AAA WG Last Call on Diameter SIP Application

This is an announcement of a AAA WG last call on "Diameter SIP
Application" prior to sending the document to the IESG for consideration
as a Proposed Standard.

The document is available here:
http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-sip-app-06.txt

AAA WG Last Call will last until March 14, 2005.  Please send comments to
the AAA WG mailing list ([email-masked]), so that they can be tracked.

Note that the RADEXT WG will simultaneously be requesting a WG Last Call
on the "RADIUS Extension for Digest Authentication" document, to end on
the same day.  Since both documents need to remain in sync to ensure
interoperation between RADIUS and Diameter, we encourage participants in
both the AAA and RADEXT WGs to read both documents and comment on them.

--
to unsubscribe send 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, 11 Feb 2005 05:27:43 +0000
Reply-To: <[email-masked]>
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "'Alan DeKok'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Question on extended RADIUS attribute format in draft-congdon-radext-ieee802-02.txt 
Date: Thu, 10 Feb 2005 21:27:05 -0800

Alan DeKok <> supposedly scribbled:

> [email-masked] wrote:
>> I don't think that it's necessary: you could just define the real
>> value of Large-Attribute as the concatenation of the String
fields of
>> all the Large-Attribute Attributes in the message, since
Attributes
>> are guaranteed now to maintain relative order; that wasn't true
when
>> RFC 2868 was undertaken.
> 
>   Sure.  My thought originally was backwards compatibility with
> servers that *don't* maintain relative order, but that's neither
here
> nor there.  
> 
> 
>   What of the discussion of packing Diameter attributes inside of
> RADIUS attributes?  I haven't seen your draft 

It's not mine, it belongs to Paul Congdon, Chuck Black & Bernard --
that's why I addressed my initial question to them instead of the
WG.

> (reference?), 

http://www.ietf.org/internet-drafts/draft-congdon-radext-ieee802-02.
txt

> but as an
> implementor, I'm leery of yet another packing format for
attributes.  
> It makes implementation harder, interoperability becomes more
> difficult, and code re-use goes down. 
> 
>   My preference would be to define "Diameter-Attributes", which
would
> pack one or more Diameter attributes, in the Diameter format.
There
> should be additional requirements on those attributes (e.g.
> non-VSA's, Mandatory bit must be set), 

Don't forget the length limit!

> which limit the attributes to
> a known subset of Diameter that is compatible with RADIUS.    
> 
>   Alan DeKok.

Hope this helps,

~gwz

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

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

Envelope-to: [email-masked]
Delivery-date: Fri, 11 Feb 2005 01:27:13 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Subject: Re: Question on extended RADIUS attribute format in draft-congdon-radext-ieee802-02.txt 
Date: Thu, 10 Feb 2005 20:22:04 -0500
Message-Id: <[email-masked]>

[email-masked] wrote:
> I don't think that it's necessary: you could just define the real
> value of Large-Attribute as the concatenation of the String fields
> of all the Large-Attribute Attributes in the message, since
> Attributes are guaranteed now to maintain relative order; that
> wasn't true when RFC 2868 was undertaken.

  Sure.  My thought originally was backwards compatibility with
servers that *don't* maintain relative order, but that's neither here nor there.

  What of the discussion of packing Diameter attributes inside of
RADIUS attributes?  I haven't seen your draft (reference?), but as an
implementor, I'm leery of yet another packing format for attributes.
It makes implementation harder, interoperability becomes more
difficult, and code re-use goes down.

  My preference would be to define "Diameter-Attributes", which would
pack one or more Diameter attributes, in the Diameter format.  There
should be additional requirements on those attributes (e.g. non-VSA's,
Mandatory bit must be set), which limit the attributes to a known
subset of Diameter that is compatible with RADIUS.

  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, 11 Feb 2005 01:15:36 +0000
Reply-To: <[email-masked]>
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: <[email-masked]>, "'Alan DeKok'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Question on extended RADIUS attribute format in draft-congdon-radext-ieee802-02.txt 
Date: Thu, 10 Feb 2005 17:15:20 -0800

Glen Zorn (gwz) <> supposedly scribbled:

...

> The value of the Length field can't be > 253; that doesn't
> necessarily mean that an attribute can't be bigger than that (for
> example, using the technique I roughly outlined).  I can't think
of
> any compatibility problems off the top of my head, but I haven't
> spent much (any ;-) time on it.   

Um, yes I can: if I were an editing proxy groveling through a
message looking for attributes of interest, I suspect this would
cause me a lot of pain...
 
...

Hope this helps,

~gwz

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

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

Delivery-date: Fri, 11 Feb 2005 01:07:40 +0000
Reply-To: <[email-masked]>
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "'Alan DeKok'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Question on extended RADIUS attribute format in draft-congdon-radext-ieee802-02.txt 
Date: Thu, 10 Feb 2005 17:07:01 -0800

Alan DeKok <> supposedly scribbled:

> Bernard Aboba <[email-masked]> wrote:
>> It would be nice to allow larger attributes if there was some way
to
>> accomplish this while maintaining backward compatibility.  Do we
have
>> a proposal for how to do this?
> 
>   As an absolutely horrible idea, how about overloading the "tag"
> concept for new attributes which need (length > 253).  Quoting RFC
> 2868 out of context, the tag is already defined as "... a means of
> grouping attributes in the same packet..." 
> 
>   We could say that a new attribute, say Large-Attribute is of
type
> string, has a tag, and that the interpretation of the attribute is
> such that all instances of Large-Attribute with the same tag
should
> have their string data concatenated, to obtain data with
> (length>253). The definition of that data would come from the
> requirements on the Large-Attribute design.    
> 
>   I don't immediately see much in the way of backwards
> incompatibility with this idea, but I'm not sure it's a good one. 

I don't think that it's necessary: you could just define the real
value of Large-Attribute as the concatenation of the String fields
of all the Large-Attribute Attributes in the message, since
Attributes are guaranteed now to maintain relative order; that
wasn't true when RFC 2868 was undertaken.

> 
>> For example, if an attribute is defined with a length > 253,
won't
>> existing proxies have trouble figuring this out?
> 
>   I'm not sure how a RADIUS attribute can have length>253.

The value of the Length field can't be > 253; that doesn't
necessarily mean that an attribute can't be bigger than that (for
example, using the technique I roughly outlined).  I can't think of
any compatibility problems off the top of my head, but I haven't
spent much (any ;-) time on it. 

> 
>>  Or is the idea to have the *inner* length different from the
>> *outer* length?  That way the outer length <= 253, but the inner
>> length can be larger?
> 
>   That makes more sense to me.  But it gets back into the "packing
> attributes inside of attributes", which was previously discussed
with
> some energy.

And is already allowed (in VSAs) by RFC 2865.
  
> 
>   Alan DeKok.

Hope this helps,

~gwz

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

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

Envelope-to: [email-masked]
Delivery-date: Fri, 11 Feb 2005 00:37:00 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Subject: Re: Question on extended RADIUS attribute format in draft-congdon-radext-ieee802-02.txt 
Date: Thu, 10 Feb 2005 19:31:40 -0500
Message-Id: <[email-masked]>

Bernard Aboba <[email-masked]> wrote:
> It would be nice to allow larger attributes if there was some way to
> accomplish this while maintaining backward compatibility.  Do we have a
> proposal for how to do this?

  As an absolutely horrible idea, how about overloading the "tag"
concept for new attributes which need (length > 253).  Quoting RFC
2868 out of context, the tag is already defined as "... a means of
grouping attributes in the same packet..."

  We could say that a new attribute, say Large-Attribute is of type
string, has a tag, and that the interpretation of the attribute is
such that all instances of Large-Attribute with the same tag should
have their string data concatenated, to obtain data with (length>253).
The definition of that data would come from the requirements on the
Large-Attribute design.

  I don't immediately see much in the way of backwards incompatibility
with this idea, but I'm not sure it's a good one.

> For example, if an attribute is defined with a length > 253, won't
> existing proxies have trouble figuring this out?

  I'm not sure how a RADIUS attribute can have length>253.

>  Or is the idea to have the *inner* length different from the
> *outer* length?  That way the outer length <= 253, but the inner
> length can be larger?

  That makes more sense to me.  But it gets back into the "packing
attributes inside of attributes", which was previously discussed with
some energy.

  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, 11 Feb 2005 00:36:52 +0000
Reply-To: <[email-masked]>
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "'Bernard Aboba'" <[email-masked]>
Cc: "'Paul Congdon'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: Question on extended RADIUS attribute format in draft-congdon-radext-ieee802-02.txt
Date: Thu, 10 Feb 2005 16:36:23 -0800

Bernard Aboba <mailto:[email-masked]> supposedly scribbled:

> It would be nice to allow larger attributes if there was some way
to
> accomplish this while maintaining backward compatibility.  Do we
have
> a proposal for how to do this?  

Beats me -- thought that this was one?

> 
> For example, if an attribute is defined with a length > 253, won't
> existing proxies have trouble figuring this out?  Or is the idea
to
> have the *inner* length different from the *outer* length?  That
way
> the outer length <= 253, but the inner length can be larger? 

That was my assumption.  Otherwise, why allocate 16 bits for
Length2?  The draft says (in Appendix a.2) 

In order to enable Extended attributes to be encoded more
economically, a "Short Form" of the Extended attribute format is
proposed.  The Short Form can be used to encode any Diameter AVP
that meets the following constraints: 
         [a] An IETF standard attribute (not Vendor-Specific) 
         [b] Diameter Code between 0 and 16384 (all existing
attributes) 
         [c] No flag bits other than the Mandatory bit.  
 
Aside from the fact that Length2 is only 2/3 the size of the
Diameter AVP Length field (thus making the assertion invalid
anyway), the intent seems to be to carry payloads larger than 253
octets.

> 
> Inquiring minds want to know :)
> 
> On Thu, 10 Feb 2005, Glen Zorn (gwz) wrote:
> 
>> Glen Zorn (gwz) <mailto:[email-masked]> supposedly scribbled:
>> 
>>> It seems as if one of the purposes of defining the extended
format
>>> might be to allow larger attribute (i.e., > 253 bytes of data).
>>> However, the Length field of the extended format is defined to
>>> include the length of Type, Length, S, Code, Length2, Flags,
>>> Vendor-Id and Data fields.  If it includes the length of the
Data
>>> field then that would seem to limit the total length of the
>>> attribute to 253 octets anyway.  Am I just missing something, or
>>> should it say 
>>> 
>>> 	Length
>>> 
>>>       The length of the extended attribute header in octets,
>>>       including the Type, Length, S, Code, and Length2 fields.
>>> 
>>> With the definition of Length2 changed to
>>> 
>>>    Length2
>>> 
>>>       The length of the sub-attribute in octets, including the
>>> 	Length2, Flags, Vendor-Id and Data fields.
>>> 
>>> Or something similar?
>> 
>> BTW, if you do this, I believe that you can get rid of the 'S'
bit
>> (which seems a little weird to me) and keep the Flags field in
the
>> "Short form" at the cost of 6 bits.  The short and long forms
could
>> be distinguished by inspection of the Length field: 6 for short
>> form, 8 for long form.  In addition, you could carry 16 and 32
bits
>> of the Diameter type code in the short & long forms,
respectively.
>> 
>>> 
>>> ~gwz
>>> 
>>> Treat the Earth well.
>>> It was not given to you by your parents.
>>> It was loaned to you by your children.
>>>   -- Kenyan Proverb
>>> 
>>> Humankind has not woven the web of life.
>>> We are but one thread within it.
>>> Whatever we do to the web, we do to ourselves.
>>> All things are bound together.
>>> All things connect.
>>>   -- Chief Seattle
>> 
>> Hope this helps,
>> 
>> ~gwz
>> 
>> Why is it that most of the world's problems can't be solved by
simply
>>   listening to John Coltrane? -- Henry Gabriel

Hope this helps,

~gwz

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

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

Delivery-date: Thu, 10 Feb 2005 23:57:36 +0000
Date: Thu, 10 Feb 2005 15:57:08 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: "Glen Zorn (gwz)" <[email-masked]>
cc: "'Paul Congdon'" <[email-masked]>, [email-masked], [email-masked]
Subject: RE: Question on extended RADIUS attribute format in draft-congdon-radext-ieee802-02.txt

It would be nice to allow larger attributes if there was some way to
accomplish this while maintaining backward compatibility.  Do we have a
proposal for how to do this?

For example, if an attribute is defined with a length > 253, won't
existing proxies have trouble figuring this out?  Or is the idea to have
the *inner* length different from the *outer* length?  That way the
outer length <= 253, but the inner length can be larger?

Inquiring minds want to know :)

On Thu, 10 Feb 2005, Glen Zorn (gwz) wrote:

> Glen Zorn (gwz) <mailto:[email-masked]> supposedly scribbled:
>
> > It seems as if one of the purposes of defining the extended format
> > might be to allow larger attribute (i.e., > 253 bytes of data).
> > However, the Length field of the extended format is defined to
> > include the length of Type, Length, S, Code, Length2, Flags,
> > Vendor-Id and Data fields.  If it includes the length of the Data
> > field then that would seem to limit the total length of the
> attribute
> > to 253 octets anyway.  Am I just missing something, or should it
> say
> >
> > 	Length
> >
> >       The length of the extended attribute header in octets,
> >       including the Type, Length, S, Code, and Length2 fields.
> >
> > With the definition of Length2 changed to
> >
> >    Length2
> >
> >       The length of the sub-attribute in octets, including the
> > 	Length2, Flags, Vendor-Id and Data fields.
> >
> > Or something similar?
>
> BTW, if you do this, I believe that you can get rid of the 'S' bit
> (which seems a little weird to me) and keep the Flags field in the
> "Short form" at the cost of 6 bits.  The short and long forms could
> be distinguished by inspection of the Length field: 6 for short
> form, 8 for long form.  In addition, you could carry 16 and 32 bits
> of the Diameter type code in the short & long forms, respectively.
>
> >
> > ~gwz
> >
> > Treat the Earth well.
> > It was not given to you by your parents.
> > It was loaned to you by your children.
> >   -- Kenyan Proverb
> >
> > Humankind has not woven the web of life.
> > We are but one thread within it.
> > Whatever we do to the web, we do to ourselves.
> > All things are bound together.
> > All things connect.
> >   -- Chief Seattle
>
> Hope this helps,
>
> ~gwz
>
> Why is it that most of the world's problems can't be solved by
> simply
>   listening to John Coltrane? -- Henry Gabriel
>

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

Delivery-date: Thu, 10 Feb 2005 22:03:07 +0000
From: Avi Lior <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RADIUS PANA interaction -- a new draft.
Date: Thu, 10 Feb 2005 17:02:23 -0500

This is to inform you that we have written a draft for RADIUS PANA
interaction.

This is was also posted in PANA WG.

Please review and send us comments as soon as possible.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, February 10, 2005 3:47 PM
To: [email-masked]
Subject: {Blocked Content} I-D ACTION:draft-lior-pana-radius-00.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		: Interworking of Protocol for Carrying
authentication for 
			  Network Access (PANA) and Remote Authentication
Dial In User 
			  Service(RADIUS).
	Author(s)	: A. Lior, A. Yegin
	Filename	: draft-lior-pana-radius-00.txt
	Pages		: 23
	Date		: 2005-2-10
	
This document provides information on the use of Remote
   Authentication Dial In User Service (RADIUS) with the Protocol for
   Carrying Authentication for Network Access (PANA).

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

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

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-pana-radius-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
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-pana-radius-00.txt".
	
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.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

------------------------------------------------
Avi Lior                                    
Bridgewater Systems Corporation                
Phone :  (613) 591-9104 x6417
Cell    :  (613) 297-2177
E-mail : mailto:[email-masked]
www.bridgewatersystems.com 

--
to unsubscribe send 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, 08 Feb 2005 01:33:05 +0000
Date: Mon, 7 Feb 2005 17:32:45 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: NIST moves to stronger hashing (fwd)

------- Forwarded Message
Date: Mon, 7 Feb 2005 12:39:36 -0500
To: [email-masked], [email-masked]
From: "R.A. Hettinga" <[email-masked]>
Subject: NIST moves to stronger hashing

<http://www.fcw.com/print.asp>

Federal Computer Week
Monday, February 7, 2005

NIST moves to stronger hashing

 BY  Florence Olsen
 Published on Feb. 7, 2005

Federal agencies have been put on notice that National Institute of
Standards and Technology officials plan to phase out a widely used
cryptographic hash function known as SHA-1 in favor of larger and stronger
hash functions such as SHA-256 and SHA-512.

 The change will affect many federal cryptographic functions that
incorporate hashes, particularly digital signatures, said William Burr,
manager of NIST's security technology group, which advises federal agencies
on electronic security standards.

"There's really no emergency here," Burr said. "But you should be planning
how you're going to transition - whether you're a vendor or a user - so
that you can do better cryptography by the next decade."

Hashing is used to prevent tampering with electronic messages. A hash is a
numerical code generated from a string of text when a message is sent. The
receiving system checks it against a hash it creates from the same text,
and if they match, the message was sent intact.

Speaking at a recent meeting of the federal Public Key Infrastructure
Technical Working Group at NIST, Burr said some critics have questioned the
security of the government-developed SHA-1 after some researchers managed
to break a variant of the SHA-1 hash function last year.

But Burr said no complete implementation of the SHA-1 function has been
successfully attacked. "SHA-1 is not broken," he said, "and there is not
much reason to suspect that it will be soon." But advances in computer
processing capability make it prudent to phase out SHA-1 by 2010, he said.

Burr said other widely used hash functions such as MD5 are vulnerable to
attack and their use should be discontinued. "If by some chance you are
still using MD5 in certificates or for digital signatures, you should
stop," he said.

--
to unsubscribe send 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, 08 Feb 2005 01:06:31 +0000
From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: RE: I-D ACTION:draft-nakhjiri-radius-mip4-00.txt
Date: Mon, 7 Feb 2005 19:06:17 -0600 

Hi Glen,

Thanks for forwarding the announcement to the list.
I just introduced the draft to the MIPv4 list, but was not really sure whether cross-posting to two lists is considered proper etiquette.
Hopefully we will get the issues fixed at both ends faster now. Here is an intro:

The draft proposes a specification for support of RADIUS for Mobile IP key management procedures. The draft goes through two cases of co-located mobile nodes and nodes behind an FA and describes RADIUS messaging and attributes for each case. Since the draft deals with both Mobile IPv4 and RADIUS, it needs to be examined by both groups. We know that this is really more an extension to RADIUS than to Mobile IP and should be standardized by RADIUS group eventually.

Comments are welcome 
(again draft can be found at 
 http://www.ietf.org/internet-drafts/draft-nakhjiri-radius-mip4-00.txt)

Regards,

Madjid

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Glen Zorn \(gwz\)
Sent: Monday, February 07, 2005 6:36 PM
To: [email-masked]
Subject: FW: I-D ACTION:draft-nakhjiri-radius-mip4-00.txt

FYI

> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. 
> 
> 
> 	Title		: RADIUS Mobile IPv4 extensions
> 	Author(s)	: M. Nakhjiri, et al.
> 	Filename	: draft-nakhjiri-radius-mip4-00.txt
> 	Pages		: 28
> 	Date		: 2005-2-7
> 
> Mobile IPv4 specifies mechanisms that need assistance from a AAA
>    server and a AAA infrastructure. Examples of such mechanisms
are
>    those providing key management and authentication services
during a
>    mobile nodeFs registration process with MN-AAA authentication
>    extension. Although Diameter Mobile IP application is being
>    specified to support the needs of Mobile IPv4 from the AAA
>    infrastructureFs point of view, such support does not exist
within
>    RADIUS framework. This document defines the RADIUS attributes
that
>    provide support for Mobile IPv4 operation.
> 
> A URL for this Internet-Draft is:
>
http://www.ietf.org/internet-drafts/draft-nakhjiri-radius-mip4-00.tx
t
> 
> To remove yourself from the I-D Announcement list, send a message
to
> [email-masked] with the word unsubscribe in the
body
> of the message.  
> You can also visit
https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
> 
> 
> 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-nakhjiri-radius-mip4-00.txt".  
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html 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-nakhjiri-radius-mip4-00.txt".
> 
> 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.
> 
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
--------------------------------------------------------------------
-----
> CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY
>
--------------------------------------------------------------------
-----
> In order to maintain computing infrastructure integrity, Cisco
Systems
> Enterprise Messaging Services and InfoSec teams have set a mail
policy
> disallowing executable attachments in email.
> 
> This message contained an executable attachment type that is
> prohibited 
> by this policy. The attachment has been removed from this message
and
> copied to quarantine by our systems. It will be held in quarantine
for
> seven days in the event that the content needs to be retrieved.
> 
> Please be aware many viruses attempt to look like legitimate email
or
> notifications from anti-virus systems. We will clearly mark a
> seperation 
> between our notifications and the original email as follows:
> 
>   "CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION
TECHNOLOGY"
> 
> For further reference information about viruses and email
antivirus
> efforts within Cisco, please visit:
> 
> http://wwwin.cisco.com/it/ems/services/antiviral
> 
> If your concern isn't addressed by the information in this
> notification 
> or the above web page, you may open a support request:
> 
> http://wwwin.cisco.com/support/
> 
> Select "Messaging", "Email-Related", "Mail Routing"
> 
> Please include in the text of your case the following information:
> 
> * Full headers of the message. Documentation on displaying the
full
> headers is available at this URL:
> 
> http://wwwin.cisco.com/support/library/faqs/solution002471.html
> 
> * This unique quarantine identifier: j17LCsUf027052
> 
> If the matter is urgent, you may follow up by calling one of the
below
> referenced numbers. Please make every effort to provide the above
> requested information via the support web tool prior to calling as
it
> will greatly aid the resolution of your issue.
> 
> Americas:
> 1 408 526 8888
> 
> Asiapac
> +61 2 8446 8888
> 
> EMEA
> +31 20 485 4888
> 
> Japan
> +81 3 5549 6888
> 
> US (Toll Free)
> 1| 800| 888| 8187| (ext.68888)
> 
> Thank you for your cooperation,
> 
> Enterprise Messaging Services
> Cisco Systems, Inc

Hope this helps,

~gwz

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

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

Delivery-date: Tue, 08 Feb 2005 00:36:29 +0000
Reply-To: <[email-masked]>
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: <[email-masked]>
Subject: FW: I-D ACTION:draft-nakhjiri-radius-mip4-00.txt
Date: Mon, 7 Feb 2005 16:35:45 -0800

This is a multi-part message in MIME format.

------=_NextPart_000_012F_01C50D33.16362EB0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

FYI

> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. 
> 
> 
> 	Title		: RADIUS Mobile IPv4 extensions
> 	Author(s)	: M. Nakhjiri, et al.
> 	Filename	: draft-nakhjiri-radius-mip4-00.txt
> 	Pages		: 28
> 	Date		: 2005-2-7
> 
> Mobile IPv4 specifies mechanisms that need assistance from a AAA
>    server and a AAA infrastructure. Examples of such mechanisms
are
>    those providing key management and authentication services
during a
>    mobile nodeFs registration process with MN-AAA authentication
>    extension. Although Diameter Mobile IP application is being
>    specified to support the needs of Mobile IPv4 from the AAA
>    infrastructureFs point of view, such support does not exist
within
>    RADIUS framework. This document defines the RADIUS attributes
that
>    provide support for Mobile IPv4 operation.
> 
> A URL for this Internet-Draft is:
>
http://www.ietf.org/internet-drafts/draft-nakhjiri-radius-mip4-00.tx
t
> 
> To remove yourself from the I-D Announcement list, send a message
to
> [email-masked] with the word unsubscribe in the
body
> of the message.  
> You can also visit
https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
> 
> 
> 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-nakhjiri-radius-mip4-00.txt".  
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html 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-nakhjiri-radius-mip4-00.txt".
> 
> 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.
> 
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
--------------------------------------------------------------------
-----
> CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY
>
--------------------------------------------------------------------
-----
> In order to maintain computing infrastructure integrity, Cisco
Systems
> Enterprise Messaging Services and InfoSec teams have set a mail
policy
> disallowing executable attachments in email.
> 
> This message contained an executable attachment type that is
> prohibited 
> by this policy. The attachment has been removed from this message
and
> copied to quarantine by our systems. It will be held in quarantine
for
> seven days in the event that the content needs to be retrieved.
> 
> Please be aware many viruses attempt to look like legitimate email
or
> notifications from anti-virus systems. We will clearly mark a
> seperation 
> between our notifications and the original email as follows:
> 
>   "CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION
TECHNOLOGY"
> 
> For further reference information about viruses and email
antivirus
> efforts within Cisco, please visit:
> 
> http://wwwin.cisco.com/it/ems/services/antiviral
> 
> If your concern isn't addressed by the information in this
> notification 
> or the above web page, you may open a support request:
> 
> http://wwwin.cisco.com/support/
> 
> Select "Messaging", "Email-Related", "Mail Routing"
> 
> Please include in the text of your case the following information:
> 
> * Full headers of the message. Documentation on displaying the
full
> headers is available at this URL:
> 
> http://wwwin.cisco.com/support/library/faqs/solution002471.html
> 
> * This unique quarantine identifier: j17LCsUf027052
> 
> If the matter is urgent, you may follow up by calling one of the
below
> referenced numbers. Please make every effort to provide the above
> requested information via the support web tool prior to calling as
it
> will greatly aid the resolution of your issue.
> 
> Americas:
> 1 408 526 8888
> 
> Asiapac
> +61 2 8446 8888
> 
> EMEA
> +31 20 485 4888
> 
> Japan
> +81 3 5549 6888
> 
> US (Toll Free)
> 1| 800| 888| 8187| (ext.68888)
> 
> Thank you for your cooperation,
> 
> Enterprise Messaging Services
> Cisco Systems, Inc

Hope this helps,

~gwz

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

------=_NextPart_000_012F_01C50D33.16362EB0
Content-Type: text/plain;
	name="ATT00153.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="ATT00153.txt"

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

------=_NextPart_000_012F_01C50D33.16362EB0--

--
to unsubscribe send 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, 07 Feb 2005 04:21:55 +0000
Content-class: urn:content-classes:message
Subject: CUI version -02
Date: Sun, 6 Feb 2005 20:21:04 -0800
From: "Adrangi, Farid" <[email-masked]>
To: <[email-masked]>
Cc: "Nelson, David" <[email-masked]>, "Bernard Aboba" <[email-masked]>

Hi all,
We just submitted version -02 of the document.  It does not yet appear
in the I-D repository, but you can access it here.=20
http://mng.ctgisp.com/IETF/RADIUSEXT/draft-ietf-radext-chargeable-user-i
d-02.txt

This version includes resolutions for:

- Issue 52 ; please see the mail snapshot below for exact changes.
- Issue 46 ; please see the mail snapshot below for exact changes.
- Issue 49
- Issue 13 - should be closed.
- Issue 56, 57, 58 are related to capability advertisement.  Note: Since
the CUI advertisement is not REQUIRED, the CUI does not need to wait for
Capabilities attribute - your thoughts?.
- And some editorial clean-ups ...
Thanks,
Farid =20

///---------------------------------------
/// Issue 52
///---------------------------------------
> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Saturday, January 08, 2005 3:42 PM
> To: [email-masked]
> Subject: Issue 52: Review of CUI-01
>=20
>=20
> Issue 52: Review of CUI-01
> Submitter name: Bernard Aboba
> Submitter email address: [email-masked]
> Date first submitted: January 8, 2004
> Reference:
> Document: CUI-01
> Comment type: T
> Priority: S
> Section: Various
> Rationale/Explanation of issue:
> Section 1
>=20
> " For example, local or intermediate networks may limit the number of
> simultaneous sessions for specific users; they may require a
> chargeable-user-identity in order to demonstrate willingness to pay
> or otherwise limit the potential for fraud.
>=20
> This implies that an authenticated and unique identity provided by
> the home network should be able to be conveyed to all parties
> involved in the roaming transaction for correlating the
> authentication and accounting packets.
>=20
> Providing a unique identity, called the Chargeable-User-Identity
> (CUI) to intermediaries, is necessary to fulfill certain business
> needs. This should not undermine the anonymity of the user. The
> mechanism provided by this draft allows the home operator to meet
> these business requirements by providing a temporary identity
> representing the subscriber and at the same time protecting the
> anonymity of the subscriber."
>=20
> There is a tradeoff between providing an authenticated and
> unique identity to all parties suitable for correlation, while also
> not compromising some aspects of privacy.
>=20
> Later on in Section 1.1, it is stated:
>=20
> "  When the home network assigns a value to
>    the CUI, it asserts that this value represents a user in the home
>    network.  The assertion should be temporary.  Long enough to be
>    useful for the external applications and not too long such that it
>    can be used to identify the user."
>=20
> I think this paragraph helps clarify the tradeoff, so that it
> should follow the paragraph above.
>=20
[FA] Done.

> Section 1.1
>=20
> The first two paragraphs appear like they belong better in Section 1.
>=20

[FA] There were moved to section 1 with some editing:

"
Several organizations, including WISPr, GSMA, 3GPP, Wi-Fi Alliance,
IRAP, have been studying mechanisms to provide roaming services, using
RADIUS. One missing element is a mechanism for providing the current
deployments with the capacity to deploy, bill and oversee WPA networks
against fraud.

The CUI attribute is intended to close operational loopholes in RADIUS
specifications that have impacted roaming solutions negatively,
especially when tunneled protocols with multiple identities, such as
PEAP or TTLS, are used. =20
Use of the CUI is geared to multi-identity EAP authentications which
are, for the most part, recent deployments.  A chargeable identity
reflecting the user profile authenticated by the home network is needed
in such roaming scenarios.
"

> "A mechanism for providing the current deployments wit
> the capacity to deploy, bill and oversee WPA networks against fraud."
>=20
> This is not a sentence. Should this be
> "One missing element is a mechanism for...."
>=20
[FA] Done - please see the above edited paragraphs that moved up.

> "Therefore whether a RADIUS
> server/proxy or client accepts or rejects the presence or lack of
> presence of the CUI attribute is a matter of business policy."
>=20
> This statement appears to come out of the blue. We are just
> getting into a discussion of usage scenarios, and suddenly
> we jump to a discussion which appears to be about backward
> compatibility. I'd suggest you move this sentence later
> in the document where it may be better put in context.
>=20

[FA] This paragraph was moved to section 2.1.  It was combined with the
second paragraph in section 2.1, as below:

"
The RADIUS server (a RADIUS proxy, home RADIUS server) may include the
CUI attribute in the Access-Accept message destined to a roaming
partner.  The CUI support by RADIUS infrastructure is driven by the
business requirements
between roaming entities.  Therefore whether a RADIUS server/proxy or
client accepts or rejects the presence or lack of presence of the CUI
attribute is a matter of business policy.
"

> "Additionally,
> there could be multiple class attributes in a RADIUS packet with
> unspecified ordering, which makes it hard to the entities outside
> home network to determine which one contains the CUI."
>=20
> RFC 2865 does specify that attributes of the same type are not
> reordered by proxies, so I don't think ordering is an issue.
> The problem is opacity, which would occur whether a single
> Class attribute was used, or multiple attributes. My
> recommendation is to delete this sentence.

[FA]=20

You are right that 2865 does specify the ordering of class.  But it is
still an issue. =20

An intermediary receives an list of class attributes:=20
If the home network inserted once class attributes then the intermediary
can assume that the first class attributes represents the CUI however if
it did not and someone else inserted the class attribute then the next
intermediary
will act on the first class attribute which would not be the CUI.  So
the problem really stems from the fact that even though class is
ordered, an intermediary cannot with certainty detect which one if any
contains the CUI-like-information.  So, perhaps we can fix the above
sentence (as below) instead of removing it:

"Additionally, there could be multiple class attributes in a RADIUS
packet, and since the contents of Class attribute is not to be
interpreted by clients, this makes it hard to the entities outside home
network to determine which one contains the CUI."

>=20
> "     The home network could use User-Name(1) in the Access-Accept
>       message to convey the CUI to intermediaries and the=20
> NAS.  However,
>       as the Access-Accept packet is routed to the NAS, the=20
> User-Name(1)
>       attribute could be (completely) rewritten by an intermediary and
>       therefore the NAS or other intermediaries along the way will not
>       have access to the CUI.  Furthermore, the NAS may use=20
> the original
>       value of the User-Name(1) attribute (the one sent in the
>       Access-Request packet) in the Accounting-Request=20
> packets to ensure
>       the billing follows the same path as authentication packets."
>=20
> To my knowledge, existing implementations do not rewrite a User-Name
> attribute sent in an Access-Accept, since a proxy-state attribute
> can be used to enable routing of the Access-Accept back to the NAS
> without examining the User-Name attribute. So the issue is not
> rewriting so much as the potential impact on routing of accounting
> packets. For example, the original "privacy" NAI in the
> EAP-Response/Identity might have been:
> [email-masked].
>=20
> This is rewritten by isp.com to "@example.com". As a result,
> the example.com RADIUS server may not even be aware of isp.com
> as an intermediary, and might send a User-Name attribute in the
> Access-Accept of "[email-masked]". However, without
> decoration, the resulting Accounting-Request would be routed
> differently than the Access-Request, which might cause problems.
> Section 2.1
>=20
[FA] Based on our email exchanges on this thread, I agree your proposed
text (with some minor modification/editing):=20

"
The User-Name(1) attribute included in the Access-Request may be used
for the purpose of request routing, and in the process may be rewritten
by intermediaries.  As a result, a RADIUS server receiving an
Access-Request packet relayed by a proxy cannot assume that the
User-Name(1) attribute remained unmodified.

On the other hand, rewriting of a User-Name(1) attribute sent within an
Access-Accept packet occurs more rarely, since a Proxy-State(33)
attribute can be used to route the Access-Accept packet without parsing
the User-Name(1) attribute.  As a result, a RADIUS server cannot assume
that a proxy stripping routing information from a User-Name(1) attribute
within an Access-Request will add this information to a User-Name(1)
attribute included within an Access-Accept.  The result is that when a
User-Name(1) attribute is sent in an Access-Accept it is possible that
the Access-Request and Accounting-Request packets will follow different
paths.  Where this outcome is undesirable, the RADIUS client should use
the original User-Name(1) in accounting packets.  Therfore, another
mechanism is required to convey a CUI within an Access-Accept message to
the RADIUS client, so that the CUI can be included in the accounting
packets.
"

> "RADIUS clients (proxy or NAS) outside
> the home network MUST NOT modify the CUI attribute."
>=20
> I think you want to say that RADIUS proxies MUST NOT modify the CUI
> attribute, and that NAS devices that support CUI MUST include=20
> it in the
> Accounting-Request unmodified, no?

[FA] We mean both proxies and NAS.  And you are right about the
inclusion of the CUI in the accounting packets, and we mention that
couple of paragraphs below in section 2.1.  In summary, we are not
requesting some behavior *other* than having proxies leave the CUI alone
and having NAS devices include it in the Accounting-Request.

>=20
> "  RADIUS client (Proxy or NAS) that does not support the CUI=20
> attribute
>    MAY ignore this attribute or MAY treat the Access-Accept as
>    Access-Reject."
>=20
> Rather than including this paragraph, I would cite RFC 2865=20
> with respect
> to behavior on receipt of an unimplemented attribute in an=20
> Access-Accept.
> That way you are guaranteed not to be updating RFC 2865.
> For example, RFC 2865 only indicates that an Access-Accept
> is treated as an Access-Reject if the service cannot be provided.
> This would require a different value of the Service-Type attribute,
> which is not used here. So the statement above represents a major
> change to RFC 2865, which is already a Draft Standard.
>=20

[FA] Right.  The paragraph was reworked as below:
"
RFC 2865 includes the following statements about behaviors of RADIUS
client and server with respect to unsupported attributes:  "A RADIUS
client MAY ignore Attributes with an unknown Type." and "A RADIUS server
MAY ignore Attributes with an unknown Type.".  Therefore, RADIUS client
or server that does not support the CUI attribute MAY ignore this
attribute.
"

> "  If RADIUS client (Proxy or NAS) requires the presence of the CUI
>    attribute in the Access-Accept, it MUST indicate its requirement by
>    including this attribute with a nul character for its data field
>    (hereafter, it is also referred to as a nul CUI) in the
>    Access-Request message."
>=20
> A cleaner approach might be to include a Capabilities
> attribute including the Type codes of (standard) attributes
> that the NAS is advertising support for. That way a single
> attribute could be used to advertise support for up to 253
> attributes.
>=20

[FA]  I think we all agree on the benefit of having a capabilities
attribute.  There has been several solution proposals, that I hope we
can work together to come up with a reasonable solution.  In the mean
time, I will not make any changes to the document on this -- and I think
we should capture and track this as a separate issue.

> "  If the NAS supports CUI attribute then the CUI attribute=20
> MAY also be
>    used as one of the identity attribute in Disconnect Message and
>    Change of Authorization messages defined by [RFC3576]. =20
> Determination
>    of NAS support for the CUI is outside the scope of this document."
>=20
> I don't think this is a good idea. There is already an issue in
> translation of RFC 3576 messages into equivalent
> Diameter messages and this is going to make it harder.
> In retrospect, we probably should have been more
> strict with respect to identification in RFC 3576,
> such as requiring the Session-Id as a unique identifier.

[FA] As per our e-mail discussions, we agreed to remove this.  So, it
was removed.

>=20
> Section 3
>=20
>      0       0       0-1     0        0         101   Error-Cause
>=20
> This would seem to be updating RFC 3579 and RFC 3576.  Please=20
> delete this
> line.
>=20

[FA] Removed.

> Section 4
>=20
> "  In deployments with both RADIUS and Diameter interworking, a
>    translation agent will be deployed and operate in accordance to the
>    NASREQ specification."
>=20
> Why is translation required? Shouldn't Diameter just define=20
> an identical
> attribute with the same Type value? And isn't CUI used in applications
> other than NASREQ, such as EAP?
>=20
[FA]  See your point.  Maybe we should just say:

"Diameter needs to define an identical attribute with the same Type
value."   but which Diameter application??=20

> Section 5.2
>=20
> "  This document instructs IANA to assign a new Error-Cause attribute
>    [RFC3576],"
>=20
> Since the attribute already exists, I think you want a new Error-Cause
> value.
>=20
[FA]

"This document instructs IANA to assign a new value for Error-Cause
attribute [RFC3576], ..."

> Section 6
>=20
> "  The CUI attribute must be protected against Man-in-the-Middle
>    attacks.  The CUI appears in Access-Accept and Accounting-Requests
>    packets and is protected by the mechanisms that are defined for
>    RADIUS [RFC2865] and [RFC2866].  Therefore there are no additional
>    security considerations beyond those already identified in=20
> [RFC2865]
>    and [RFC2866].
>=20
>    Message-Authenticator(80) and Event-Timestamp(55) can be used to
>    further protect against Man-in-the-middle attacks.
>=20
>    It is strongly recommended that the CUI form used is such that the
>    real user identity is not revealed.  Furthermore, where a reference
>    is used to a real user identity, the binding lifetime of that
>    reference to the real user be kept as short as possible."
>=20
> I think you really mean that you would like to protect
> RADIUS packets including CUI against modification. Even
> though the draft prohibits modification of the CUI attribute
> by proxies, there is no way to prevent this, really.
>=20
> Message-Authenticator and Event-Timestamp attributes don't
> protect against man-in-the-middle (e.g. rogue proxies), they
> protect against modification and replay, respectively.
>=20
[FA] Okay, how about the revised text for the security section, as
below?

"
It is strongly recommended that the CUI form used is such that the real
user identity is not revealed.  Furthermore, where a reference is used
to a real user identity, the binding lifetime of that reference to the
real user be kept as short as possible.

The RADIUS entities (RADIUS proxies and clients) outside the home
network MUST NOT modify the CUI.  However, there is no way to detect or
prevent this.

If the NAS includes CUI in an Access-Request. A man in the middle may
remove the CUI attribute from the Access-Request.  The result is that
the Access-Accept will not have a CUI which will cause the NAS to reject
the session resulting in a DOS attack. To prevent this attack, the NAS
SHOULD include Message-Authenticator(80) in the Access-Request packets
that contain a CUI.
"

Please note that the last paragraph will change once we decide on using
capabilities attribute.

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

///---------------------------------------------
/// Issue 46
///---------------------------------------------

Based on our discussion so far, we have agreed to make the following
clarification on the use-case currently included in the document.=20

"
The CUI attribute serves as an alias to the user's real identity,
representing a chargeable identity as defined and provided by the home
network as a supplemental or alternative information to User-Name(1).
Typically the CUI represents the identity of the actual user but it may
also indicate other chargeable identities such as a group of users.=20
"

To best of my knowledge, there hasn't been any other use-cases proposed
to the list.  We are planning to submit an update this week -- please
let us know if you have any new use-cases in mind.

BR,
Farid

On Sun, 16 Jan 2005, Adrangi, Farid wrote:

> Background:
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> The CUI document define a new RADIUS attribute called a CUI.  The CUI
> functions as an handle or an alias to a user identity especially when
> the more traditional user identity attributes (username) do not convey
> the user identity.  The draft cites one example when this happens
mainly
> EAP methods that hide that hide the identity.
>
> As per the document, the CUI is assigned a value by the home network
so
> that entities outside the home network, can have a handle to the user
to
> fulfill certain business scenarios.  The document cites two cases: 1)
> when an intermediary requires to ensure that a user is only logged in
> once; and 2) For the purpose of billing mediation.
>
> To function as a handle to the user identity, it is suffice that the
CUI
> which is of type string contain an opaque value that is generated by
the
> home network.  This value is an assertion by the home network that
> represents a unique user in their network.  The only operation that is
> reasonably allowed to be performed by none home network entities on
this
> attribute therefore is a binary comparison.
>
> Are there other use-cases?
> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
-
>
> As instructed by David Nelson we are seeking any other use-case
> scenarios that would demonstrate the need to change the content of the
> CUI, that is would require non-opaqueness; Or ones that would require
> semantic changes to the current document.   We are not looking for use
> cases that will further support the current CUI document.
>
> If there are such use cases, can you please respond with: "[CUI
USECASE]
> some title" on the list. We will look for consensus to support this
> scenario.
>
> BR,
> Farid
>

--
to unsubscribe send 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, 04 Feb 2005 15:20:12 +0000
From: Avi Lior <[email-masked]>
To: [email-masked]
Cc: "[email-masked]'" <[email-masked]>, 'Bernard Aboba' <[email-masked]>
Subject: End-to-End Capability
Date: Fri, 4 Feb 2005 10:19:46 -0500 

Hi all,

Farid and I have submitted a draft for capability exchange. A copy can be
found here:
http://mng.ctgisp.com/IETF/RADIUSEXT/draft-lior-radext-end-to-end-caps-00.tx
t.

Background:
This work was originally presented in
draft-adrangi-radius-attributes-extension-01.txt
We have modified it based on email discussions and private conversation.

In essence, it uses bit-pair for capabilities (not attributes).

In the discussion section we also discuss Glen Zorn's question, on whether
or not it makes sense to have the capability exchange also come from the the
Server. Using Glen's own draft we show an example that shows that indeed
that does make sense.  This part is not in the draft yes -- we will wait for
consensus.

Here is a snippet of that from the draft.....

9.1  Bi-directional capability exchange

   Glen Zorn asked the question, why should the capability exchange
   should only come from the client? He is right!

   Using logoff as an example to illustrate why it makes sense.
   Supposing the NAS reports that it supports LOGOFF capability.  It
   would be nice for the Server to be able to tell the NAS that it wants
   to receive the LOGOFF message as decribed in the logoof document.
   The server could do this during Access-Accept or even mid-session
   using CoA.

   By allowing the Server to send the capability attribute back in an
   Access-Accept the server can signal what it supports and what it
   REQUIRES.

   Comments?

> -----Original Message-----
> From: Glen Zorn (gwz) [mailto:[email-masked]] 
> Sent: Wednesday, February 02, 2005 10:34 PM
> To: 'Bernard Aboba'
> Cc: [email-masked]
> Subject: RE: Proposal: Capabilities Attribute
> 
> 
> Bernard Aboba <mailto:[email-masked]> supposedly scribbled:
> 
> >>>       This Attribute includes a list of attribute types
> supported
> >>>       by the client.  One or more Capabilities attributes MAY be
> >>>       sent within an Access-Request packet.
> >> 
> >> Why only client & request?
> > 
> > The usage scenario I had in mind was a NAS announcing to a 
> server that 
> > it supported various attributes.  This could be useful, for 
> debugging 
> > purposes (oops, I forgot to upgrade that NAS!), or
> backward
> > compatibility (server won't send a new attribute to a NAS that
> > doesn't support it).    
> > 
> > Can you describe how a server could use a Capabilities attribute?
> 
> First, let me apologize for the tardiness of this response.  
> As it stands, by the time a client gets a response (if any) 
> from a server that doesn't support some necessary capability, 
> it's too late: either the request "succeeded" or it failed.  
> However, I don't see any reason to limit the new aspects of 
> the protocol based upon historical limitations.  
> 
> Hope this helps,
> 
> ~gwz
> 
> Why is it that most of the world's problems can't be solved by simply
>   listening to John Coltrane? -- Henry Gabriel
> 
> --
> to unsubscribe send a message to 
> [email-masked] with the word 'unsubscribe' in 
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

--
to unsubscribe send 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, 03 Feb 2005 03:34:41 +0000
Reply-To: <[email-masked]>
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "'Bernard Aboba'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Proposal: Capabilities Attribute
Date: Wed, 2 Feb 2005 19:33:56 -0800

Bernard Aboba <mailto:[email-masked]> supposedly scribbled:

>>>       This Attribute includes a list of attribute types
supported
>>>       by the client.  One or more Capabilities attributes MAY be
>>>       sent within an Access-Request packet.
>> 
>> Why only client & request?
> 
> The usage scenario I had in mind was a NAS announcing to a server
> that it supported various attributes.  This could be useful, for
> debugging purposes (oops, I forgot to upgrade that NAS!), or
backward
> compatibility (server won't send a new attribute to a NAS that
> doesn't support it).    
> 
> Can you describe how a server could use a Capabilities attribute?

First, let me apologize for the tardiness of this response.  As it
stands, by the time a client gets a response (if any) from a server
that doesn't support some necessary capability, it's too late:
either the request "succeeded" or it failed.  However, I don't see
any reason to limit the new aspects of the protocol based upon
historical limitations.  

Hope this helps,

~gwz

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

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

Delivery-date: Tue, 01 Feb 2005 18:01:33 +0000
Content-class: urn:content-classes:message
Subject: RE: Capabilities Proposals
Date: Tue, 1 Feb 2005 10:00:26 -0800
From: "Adrangi, Farid" <[email-masked]>
To: "Barney Wolff" <[email-masked]>
Cc: <[email-masked]>, "Bernard Aboba" <[email-masked]>

Hi Barney,
Yes, I agree with two-bits per attribute to indicate "not-supported",
"supported", and "required".
Farid

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Barney Wolff
> Sent: Monday, January 31, 2005 10:33 PM
> To: Bernard Aboba
> Cc: [email-masked]
> Subject: Re: Capabilities Proposals
>=20
>=20
> On Mon, Jan 31, 2005 at 10:24:58PM -0800, Bernard Aboba wrote:
> > > I don't believe a capabilities attribute is required for=20
> CUI.  The last
> > > scheme I'm aware of for CUI has the proxy or NAS that=20
> requires CUI signal
> > > that by including a NUL CUI attribute in its=20
> Access-Request.  Since CUI
> > > is never needed by the server, the server has no need to=20
> know whether
> > > the sender of an Access-Request that does not include the=20
> CUI does not
> > > support CUI or merely does not require it.
> >=20
> > I think this is different from the situation of=20
> NAS-Filter-Rule where the
> > NAS is not requiring its use, only the RADIUS server might=20
> need/want it.
> > So the difference is that with CUI the NAS is advertising=20
> that it REQUIRES
> > CUI, whereas with NAS-Filter-Rule the NAS would be=20
> advertising that it
> > SUPPORTS the attribute -- it is the RADIUS server that would require
> > support.
> >=20
> > Therefore I think that even if we had a Capabilities=20
> attribute it is not
> > clear that the semantics of that attribute would be=20
> appropriate for use
> > with CUI.
> >=20
> > Am I stating the case correctly?
>=20
> Yes, if the Capabilities attribute does not itself distinguish between
> supported and required attributes.  I had suggested that as possibly
> being worth two bits per attribute, but did not hear widespread
> enthusiasm in response.
>=20
> Regards,
> Barney
>=20
> --=20
> Barney Wolff         http://www.databus.com/bwresume.pdf
> I'm available by contract or FT, in the NYC metro area or via=20
> the 'Net.
>=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: Tue, 01 Feb 2005 15:47:42 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue 38 - Ordering of filter attributes
Date: Tue, 1 Feb 2005 10:46:38 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Avi Lior Writes...

> What I am trying to say is that: when a NAS receives multiple
> NAS-Filter-Rule attributes it has to reconstruct the list.  In doing
that
> task it has to be mindfull that some of the Filter-Rules may span more
> then one NAS-Filter-Rule attribute.

Why is that a requirement?  Wouldn't it be simpler to specify that a
single rule does not span more than one attribute?  In that scenario,
the software that packs the attributes would keep track of the remaining
space, and would start a new attribute instance if the next rule to be
packed was longer than the remaining space.  This avoids the need for
any form of fragmentation bit or continuation flag.

Yes, it may result in slightly lower efficiency in packing rules into an
Access-Accept packet.  I've heard the discussion about "huge sets of
rules".  I guess I'm not overly sympathetic.  That's one reason that the
original RADIUS WG devised the named rule scheme for Filter-ID, so that
arbitrarily complex sets of rules could be provisioned by out of band
means (FTP, TFTP, SNMP, HTTP, etc.).

I think the simplicity obtained in forcing individual (atomic) rules to
fit in their entirety within a single attribute (no fragmentation) is
worth the tradeoff of having a larger number of rules, or a larger
number of attributes, in the Access-Accept packet.=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, 01 Feb 2005 15:16:28 +0000
Content-class: urn:content-classes:message
Subject: RE: Capabilities Proposals
Date: Tue, 1 Feb 2005 10:15:29 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Barney Wolff writes...
=20
> I don't believe a capabilities attribute is required for CUI.  The
last
> scheme I'm aware of for CUI has the proxy or NAS that requires CUI
signal
> that by including a NUL CUI attribute in its Access-Request.

If we generalize the concept to "capabilities signaling", then I think
that both notions are covered.  The existence of a capability can be
signaled to a peer by either (a) sending a pre-agreed value of the
attribute in question that denotes support (e.g. the NULL CUI value), or
(b) setting one (or more) bits in a special capabilities attribute,
indicating support for one (or more) attributes (presumably other than
the capabilities attribute itself).

The assertion that method (a) is preferable for CUI does not indicate
that capabilities signaling, per se, is not a requirement for CUI.  I
think what's being debated is whether the WG wants to adopt method (a)
or method (b) as the form of capabilities signaling.  Alternately we
could do this in an ad-hoc fashion with some attributes using method (a)
and some using method (b), but that would seem to me, at least, to be
more complicated.

--
to unsubscribe send 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, 01 Feb 2005 15:16:21 +0000
From: Avi Lior <[email-masked]>
To: "Sanchez, Mauricio (PNB Roseville)" <[email-masked]>,  Avi Lior <[email-masked]>, [email-masked]
Subject: RE: Issue 38 - Ordering of filter attributes
Date: Tue, 1 Feb 2005 10:15:29 -0500 

Hi,

Perhaps I didn't make myself clear.

What I am trying to say is that: when a NAS receives multiple
NAS-Filter-Rule attributes it has to reconstruct the list.  In doing that
task it has to be mindfull that some of the Filter-Rules may span more then
one NAS-Filter-Rule attribute.

> How often do you forsee generating a single NAS-Filter-Rule that would
> blow out a single RADIUS attribute? 

I don't know how often.  The question is can it happen?

> Even so, why couldn't you spread
> out the rule over multiple attributes with the same net effect?

Yes you would.  And that is my point.

> If
> anything, I do see an issue in running out of space for multiple rules
> (i.e. multiple NAS-Filter-Rule attributes) within a single
> Access-Accept.  

I don't disagree.  That could happen.

> -----Original Message-----
> From: Sanchez, Mauricio (PNB Roseville) 
> [mailto:[email-masked]] 
> Sent: Monday, January 31, 2005 7:01 PM
> To: Avi Lior; [email-masked]
> Subject: RE: Issue 38 - Ordering of filter attributes
> 
> 
> 
> 
> Avi writes...
> 
> > 
> > There are two issues that need to be addressed.
> > 
> > One is that one NAS-Filter-Rule maybe too large to fit a
> > single RADIUS attribute; and A session may require several of 
> > these NAS attributes.
> > 
> > Ordering is a given in RADIUS (as already described in the mail)
> > 
> > Therefore receipient of the Access-Accept must be able to
> > reconstruct a single NAS-Filter-Rule that extends over two or 
> > more attributes.  And then you need to build the list of 
> > NAS-Filter-Rules.
> > 
> > Note that there is no specific hint to help detect a
> > Filter-Rule that spans over more then one attribute.  For 
> > example a key word at the end that indicates that the rule is 
> > extended over the next attribute.  
> > 
> 
> How often do you forsee generating a single NAS-Filter-Rule that would
> blow out a single RADIUS attribute?  Even so, why couldn't you spread
> out the rule over multiple attributes with the same net effect?  If
> anything, I do see an issue in running out of space for multiple rules
> (i.e. multiple NAS-Filter-Rule attributes) within a single
> Access-Accept.  
> 
> MS
> 

--
to unsubscribe send 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, 01 Feb 2005 06:33:05 +0000
Date: Tue, 1 Feb 2005 01:32:43 -0500
From: Barney Wolff <[email-masked]>
To: Bernard Aboba <[email-masked]>
Cc: [email-masked]
Subject: Re: Capabilities Proposals

On Mon, Jan 31, 2005 at 10:24:58PM -0800, Bernard Aboba wrote:
> > I don't believe a capabilities attribute is required for CUI.  The last
> > scheme I'm aware of for CUI has the proxy or NAS that requires CUI signal
> > that by including a NUL CUI attribute in its Access-Request.  Since CUI
> > is never needed by the server, the server has no need to know whether
> > the sender of an Access-Request that does not include the CUI does not
> > support CUI or merely does not require it.
> 
> I think this is different from the situation of NAS-Filter-Rule where the
> NAS is not requiring its use, only the RADIUS server might need/want it.
> So the difference is that with CUI the NAS is advertising that it REQUIRES
> CUI, whereas with NAS-Filter-Rule the NAS would be advertising that it
> SUPPORTS the attribute -- it is the RADIUS server that would require
> support.
> 
> Therefore I think that even if we had a Capabilities attribute it is not
> clear that the semantics of that attribute would be appropriate for use
> with CUI.
> 
> Am I stating the case correctly?

Yes, if the Capabilities attribute does not itself distinguish between
supported and required attributes.  I had suggested that as possibly
being worth two bits per attribute, but did not hear widespread
enthusiasm in response.

Regards,
Barney

-- 
Barney Wolff         http://www.databus.com/bwresume.pdf
I'm available by contract or FT, in the NYC metro area or via the 'Net.

--
to unsubscribe send 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, 01 Feb 2005 06:25:10 +0000
Date: Mon, 31 Jan 2005 22:24:58 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: Barney Wolff <[email-masked]>
cc: [email-masked]
Subject: Re: Capabilities Proposals

> I don't believe a capabilities attribute is required for CUI.  The last
> scheme I'm aware of for CUI has the proxy or NAS that requires CUI signal
> that by including a NUL CUI attribute in its Access-Request.  Since CUI
> is never needed by the server, the server has no need to know whether
> the sender of an Access-Request that does not include the CUI does not
> support CUI or merely does not require it.

I think this is different from the situation of NAS-Filter-Rule where the
NAS is not requiring its use, only the RADIUS server might need/want it.
So the difference is that with CUI the NAS is advertising that it REQUIRES
CUI, whereas with NAS-Filter-Rule the NAS would be advertising that it
SUPPORTS the attribute -- it is the RADIUS server that would require
support.

Therefore I think that even if we had a Capabilities attribute it is not
clear that the semantics of that attribute would be appropriate for use
with CUI.

Am I stating the case correctly?

--
to unsubscribe send 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, 01 Feb 2005 06:17:45 +0000
Date: Tue, 1 Feb 2005 01:17:03 -0500
From: Barney Wolff <[email-masked]>
To: Bernard Aboba <[email-masked]>
Cc: [email-masked]
Subject: Re: Capabilities Proposals

On Mon, Jan 31, 2005 at 06:47:55PM -0800, Bernard Aboba wrote:
> 
> Since a capabilities attribute appears to be required for both the CUI and
> IEEE 802 drafts, as well others (Pre-paid?) we are going to need to figure
> out how this works to get these documents done.

I don't believe a capabilities attribute is required for CUI.  The last
scheme I'm aware of for CUI has the proxy or NAS that requires CUI signal
that by including a NUL CUI attribute in its Access-Request.  Since CUI
is never needed by the server, the server has no need to know whether
the sender of an Access-Request that does not include the CUI does not
support CUI or merely does not require it.

My only reason for raising this is to suggest that CUI does not need to
wait for Capabilities to be thrashed out.

Regards,
Barney

-- 
Barney Wolff         http://www.databus.com/bwresume.pdf
I'm available by contract or FT, in the NYC metro area or via the 'Net.

--
to unsubscribe send 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, 01 Feb 2005 02:48:15 +0000
Date: Mon, 31 Jan 2005 18:47:55 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Capabilities Proposals

>From looking at the mailing list discussion, it would appear that we have
at least 3 (maybe 4) distinct capabilities proposals.  Some of these were
discussed at IETF 60.

In order to track comments on the proposals, I've created 3 new issues on
the Issue list.

Issue 56 is for comments on the original Capabilities Attribute proposal I
posted to the list.

Issue 57 is for Avi's "Sub-capabilities" proposal.

Issue 58 is for Jari's "End-to-End Capabilities" proposal.

Since a capabilities attribute appears to be required for both the CUI and
IEEE 802 drafts, as well others (Pre-paid?) we are going to need to figure
out how this works to get these documents done.

Feel free to send email to the list with comments on the proposals,
including the Issue # in the subject line.

Also, it seems sensible to devote some time to discussion of the proposals
at IETF 62.

--
to unsubscribe send 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, 01 Feb 2005 02:34:54 +0000
Date: Mon, 31 Jan 2005 18:34:47 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Issue 60: RADIUS Accounting

Issue 60: RADIUS Accounting
Submitter name: David Nelson
Submitter email address: [email-masked]
Date first submitted: January 31, 2005
Reference: http://ops.ietf.org/lists/radiusext/2005/msg00013.html
Document: Issues and Fixes
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:

RFC 2866 has the following text (or similar):

"...can only be present in Accounting-Request records where
the Acct-Status-Type is set to Stop."

contained in the description of the following RADIUS Accounting
Attributes:

5.3.  Acct-Input-Octets
5.4.  Acct-Output-Octets
5.7.  Acct-Session-Time
5.8.  Acct-Input-Packets
5.9.  Acct-Output-Packets
5.10. Acct-Terminate-Cause

With the exception of Acct-Terminate-Cause, do folks in think that RFC
2866 intended to prohibit these attributes from also appearing in
Accounting-Request messages where the Acct-Status-Type is set to
Interim-Update?

My research shows that the text in question first appears in RFC 2059.
RFC 2059 is obsoleted by RFC 2139, which in turn is obsoleted by RFC
2866.  The Interim-Update value of Acct-Status-Type is *not* included in
RFC 2059, just Start and Stop.  One possible scenario is that when the
Interim-Update type was added, no one bothered to notice the sections of
text that indicate this "Stop only" text and updated them to read "Stop
or Interim-Update".

Since the purpose of the Interim-Update is to provide a snap-shot of the
accounting statistics at that moment in time, I see no reason why the
octet counts and session time attributes ought not to be included.  Is
this potentially an erratum in RFC 2866? Or was there a good reason to
omit these accounting statistics from the Interim-Update messages?

[Barney Wolff]

I believe you are correct, and this was simply an oversight.

[Glen Zorn]

I tend to agree, but I think that the oversight (and error) was
actually in RFC 2869, which defines the semantics of the
Interim-Update Acct-Status-Type.  I think that the problem could
have been avoided but just including "Updates: RFC 2866" in the
header...

[Avi Lior]

Actually 2869 says the following:

"It is envisioned that an Interim Accounting record (with Acct-
Status-Type = Interim-Update (3)) would contain all of the attributes
normally found in an Accounting Stop message with the exception of
the Acct-Term-Cause attribute."

[Glen Zorn]

I'm quite aware of that; what's missing is the reverse pointer to
2866 that would allow people to discover (without the use of ESP :-)
that they need to read 2869 to understand interim accounting.

[David Nelson]

So it seems clear that this is the intent.

As Glen Zorn points out, RFC 2869 does not indicate that it updates RFC
2866, and RFC 2866 *does* include the code-id for Interim-Update (3),
but did not pick up any of the other related text from RFC 2869.  RFC
2869 also says:

  "This memo suggests several additional Attributes that can be added to
   RADIUS to perform various useful functions.  These Attributes do not
   have extensive field experience yet and should therefore be
   considered experimental."

While the RFC status is Informational, it indicates that the Attribute
status is Experimental?  Odd.

Perhaps we should consider adding a clarification in our RADIUS Issues
and Fixes document, once we actually start work on that 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: Tue, 01 Feb 2005 02:33:58 +0000
Date: Mon, 31 Jan 2005 18:33:48 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Issue 61: Multiple Filter-ID Attributes

Issue 61: Multiple Filter-ID Attributes
Submitter name: David Nelson
Submitter email address: [email-masked]
Date first submitted: January 25, 2005
Reference: http://ops.ietf.org/lists/radiusext/2005/msg00077.html
Document: Issues and Fixes
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:

Does this issue exist in "merging" two or more instances of Filter-ID?

[Bernard Aboba]

RFC 2865 doesn't have much to say on this subject, other than that zero
or more instances of Filter-Id can be included in an Access-Accept.  In
my experience, implementations merge the filters in the order they are
specified.  But perhaps there are implementations that do not do this?

[David Nelson]

That is why this subject might be fodder for the Issues and Fixes
document.  To clarify, or at least highlight, an inadequate
specification in RFC 2865 of what to do with multiple instances of
Filter-ID.

We have implementations that treat multiple instances as Filter-ID as
alternative filters, rather than cumulative filters.  The first
Filter-ID attribute having a name matching a locally defined filter is
used.  The remaining ones are ignored.

In the absence of guidance to the contrary, this is a permissible
interpretation, and I presume there might be others.

[Glen Zorn]

I don't actually think that this is a discovery.  As I recall, at
least two interpretations were discussed in the RADIUS WG, David's
among them and the interpretation of multiple Filter-Id Attributes
was purposely left undefined.

--
to unsubscribe send 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, 01 Feb 2005 02:32:52 +0000
Date: Mon, 31 Jan 2005 18:32:45 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Issue 63: Request-ID Supplementation

Issue 63: Request-ID Supplementation
Submitter name: David Nelson
Submitter email address: [email-masked]
Date first submitted: August 5, 2004
Reference:
http://www.ietf.org/proceedings/04aug/slides/radextt-1/index.html
Document: Issues and Fixes
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:

In RFC 3579, the recommended practices to supplement the Request-ID are
described:

"In EAP, each session has its own unique Identifier space. RADIUS server
implementations  MUST be able to distinguish between EAP packets with the
same Identifier existing within distinct sessions, originating on the
same NAS. For this purpose, sessions can be distinguished based  on NAS
and session identification attributes. NAS identification
attributes include NAS-Identifier, NAS-IPv6-Address and NAS-IPv4-Address.
Session identification attributes include User-Name, NAS-Port,
NAS-Port-Type, NAS-Port-Id,  Called-Station-Id, Calling-Station-Id and
Originating-Line-Info."

This practice applies to other types of RADIUS requests, other than those
involving EAP.

It is commonly a problem on high port density devices.
Is this practice clearly defined?
Is it commonly implemented?
Is it sufficient to address the Request-ID number space "wrap-around"
issue?

[BA] Also see Issue 242 (related 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/>

Delivery-date: Tue, 01 Feb 2005 02:31:17 +0000
Date: Mon, 31 Jan 2005 18:31:07 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Issue 62: Service-Type Issues

Issue 62: Service-Type Issues
Submitter name: David Nelson
Submitter email address: [email-masked]
Date first submitted: August 5, 2004
Reference:
http://www.ietf.org/proceedings/04aug/slides/radextt-1/index.html
Document: Issues and Fixes
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:

RADIUS does not have any explicit attribute tagging as to optional or
mandatory

RFC2865 does say (text "A"):

"A RADIUS server MAY ignore Attributes with an unknown Type."
"A RADIUS client MAY ignore Attributes with an unknown Type."
"Servers not equipped to interpret the vendor-specific information sent by
a client MUST ignore it (although it may be reported). Clients which do not receive
desired vendor-specific information SHOULD make an attempt to operate
without it, although they may do so (and report they are doing so) in a degraded mode."

RFC2586 also says (text "B"):

"This Attribute indicates the type of service the user has requested,
or the type of service to be provided. It MAY be used in both
Access-Request  and Access-Accept packets. A NAS is not required to
implement all of these service types, and MUST treat unknown or
unsupported Service-Types as though an Access-Reject had been received instead."

This text applies only to the Service-Type attribute.

However, RFC2865 also says (text "C"):

"A NAS that does not implement a given service MUST NOT implement the
RADIUS attributes for that service. For example, a NAS that is unable to
offer ARAP service MUST NOT implement the RADIUS attributes for ARAP. A NAS MUST
treat a RADIUS access-accept authorizing an unavailable service as an
access-reject instead."

In this case it is more clear that the "treat as a reject" action applies
to any collection of attributes that constitute a service definition.

It is apparent, therefore, that RADIUS has a general category of optional
attributes (i.e. ones that MAY be ignored)

RADIUS also has a general category of attributes that are mandatory
(i.e. ones that MUST not be ignored)

There seems to be an internal inconsistency between the text of (A) and
the text of (B) and (C).

The text of (A) and (B) dates back to RFC2058.

The text of (C) appears in RFC2865.

It would seem that the "MAY ignore" text applies to any attributes that
the NAS does not recognize except for those defining services.

Attributes defining services are implicitly mandatory attributes.
This clarification should probably be added to a RADIUS 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: Tue, 01 Feb 2005 02:29:32 +0000
Date: Mon, 31 Jan 2005 18:29:19 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Tracking Issues & Fixes items 

A number of issues have come up recently that relate to interoperability
issues with existing RADIUS RFCs.  In order to track these, we will be
including them on the RADEXT WG Issues list:

http://www.drizzle.com/~aboba/RADEXT/

In the next few posts, I am going to file issues that have come up.  These
include issues that David Nelson brought up at IETF 60.  If you want to
comment on them, please hit 'R'eply so that your response will become part
of the 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, 01 Feb 2005 01:48:20 +0000
Date: Mon, 31 Jan 2005 17:47:41 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Issue 59:  Unicode Proposal and Stringprep

Issue 59: Unicode Proposal and Stringprep
Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: January 31, 2005
Reference:
Document: RFC 2486bis-03
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:

Does this affect RFC 2486bis?

-------- Original Message --------
Subject: FYI: Unicode proposal to break NFKC backwards compatibility
Date: Tue, 25 Jan 2005 00:14:15 +0100
From: Simon Josefsson <[email-masked]>
To: [email-masked]

I have not seen this apparently IETF related Unicode news mentioned
here, so FYI:

If anyone is interested in Unicode normalization issues, especially
wrt to Stringprep or Internationalized Domain Names (IDN), you might
be interested in a current public review issue in the UTC:

Issue #61 Proposed Update UAX #15 Unicode Normalization Forms
A proposed update to UAX #15 for Unicode 4.1.0 is available at the
link above. The proposed changes are listed in the Modifications
section of the document.

The UTC accept comments from the public until January 31th. The above
abstract isn't informative, but when you look at the proposed changes:

http://www.unicode.org/reports/tr15/tr15-24.html

It is clear that this is the next step of the backwards incompatible
NFC/NFKC normalization change first discussed in:

http://www.unicode.org/review/pr-29.html

That change affect all StringPrep profile that uses NFKC
normalization. The change may imply interoperability problems, or at
worst security problems, when/if IETF wants to use Unicode 4.1 or
later in StringPrep. As far as I am aware, the IETF has not given
implementors advice on whether to follow the proposed UTC change or
not. My experience is that deployed IDN implementations are not
implemented the same way.

Regards,
Simon

--
to unsubscribe send 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, 01 Feb 2005 00:38:39 +0000
Date: Mon, 31 Jan 2005 16:38:23 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: "Glen Zorn (gwz)" <[email-masked]>
cc: [email-masked]
Subject: RE: [Issue] RFC 3576 Usage of Message-Authenticator

> > and Accounting-Response messages, because these messages do not
> > contain a random Request Authenticator, as specified in RFC 3579:
>
> >
> >       Message-Authenticator = HMAC-MD5 (Type, Identifier, Length,
> >       Request Authenticator, Attributes)
>
> The word "random" is not present in RFC 3579; therefore it's hard to
> see how one can claim that a random Request Authenticator is
> "specified" thereby.  Maybe a better phrase would be "tacitly
> assumed by the authors"?  In any case, however, I agree that the use
> of the accounting-style Request Authenticator in the generation of
> the Message-Authenticator Attribute is probably inappropriate.

The term is used in RFC 2865, though.  For example, in Section 5.2:

      Call the shared secret S and the pseudo-random 128-bit Request
      Authenticator RA.

In this particular case, I think the issue was not so much whether the
Request Authenticator from RFC 2866 is pseudo-random but rather the
circular dependency:  Message-Authenticator, Tunnel-Password, etc. depend
on the RA, but the RA depends on the attributes.

If the issue were merely pseudo-randomness, then perhaps it might be
solved by including a pseudo-random attribute (e.g. a Nonce) in the
Request, in order to introduce entropy into the calculated RA.

> For example, the usage of the
> Event-Timestamp for replay detection in 3576 would seem to be
> weakened.

Can you elaborate?  Is this because the RA calculation involves MD5,
rather than HMAC-MD5?  From RFC 2866:

      The NAS and RADIUS accounting server share a secret.  The Request
      Authenticator field in Accounting-Request packets contains a one-
      way MD5 hash calculated over a stream of octets consisting of the
      Code + Identifier + Length + 16 zero octets + request attributes +
      shared secret (where + indicates concatenation).  The 16 octet MD5
      hash value is stored in the Authenticator field of the
      Accounting-Request packet.

> I really think that the assumption in RFC 3579 needs to
> be laid bare; I'm not sure whether an erratum is sufficient for this
> or if an applicability statement needs to be published.

I'm not sure how RFC 3579 comes into play here, since it only
defines usage of Message-Authenticator in
Access-Request, Challenge, Accept and Reject packets, not in
Accounting-Request/Response or CoA/Disconnect messages.
Here is the text from Section 3.2:

      When present in an Access-Request packet, Message-Authenticator is
      an HMAC-MD5 [RFC2104] hash of the entire Access-Request packet,
      including Type, ID, Length and Authenticator, using the shared
      secret as the key, as follows.

      Message-Authenticator = HMAC-MD5 (Type, Identifier, Length,
      Request Authenticator, Attributes)

      When the message integrity check is calculated the signature
      string should be considered to be sixteen octets of zero.

      For Access-Challenge, Access-Accept, and Access-Reject packets,
      the Message-Authenticator is calculated as follows, using the
      Request-Authenticator from the Access-Request this packet is in
      reply to:

      Message-Authenticator = HMAC-MD5 (Type, Identifier, Length,
      Request Authenticator, Attributes)

      When the message integrity check is calculated the signature
      string should be considered to be sixteen octets of zero.  The
      shared secret is used as the key for the HMAC-MD5 message
      integrity check.  The Message-Authenticator is calculated and
      inserted in the packet before the Response Authenticator is
      calculated.

--
to unsubscribe send 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, 01 Feb 2005 00:30:42 +0000
Content-class: urn:content-classes:message
Subject: Issue 42: Are the Attributes Really Mandatory?
Date: Mon, 31 Jan 2005 16:30:31 -0800
From: "Sanchez, Mauricio (PNB Roseville)" <[email-masked]>
To: <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C507F5.3DB0AF47
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Nagi writes...

>Issue 42: Are the Attributes Really Mandatory?
>Submitter: Nagi Reddy Jonnala
>Submitter email address: [email-masked]
>Date first submitted: December 14, 2004
>Reference: http://ops.ietf.org/lists/radiusext/2004/msg00989.html
>Document: Congdon-02
>Comment type: T
>Priority: 1
>Section: Various
>Rationale/Explanation of issue:
>All the AVPs have the "M" bit enabled which means that the  NAS MUST
>understand the given attribute. I disagree with this. Having the
default
>value/action in case the RADIUS server doesn't return is already in
>practice (for example locally configured interim interval, session
>timeout). It is also true with some/all of the attributes mentioned in
>this draft.  For instance, understanding Egress-VLANID should never be
>mandatory because the system might already have a default allowed set
of
>VLANIDs.
>
>Requested change:
>
>First alternative is:
>
>Use the idea suggested by Bernard to advertise the Capabilities of
"new"
>attributes in Access-Request and I like this idea.
>
>Second alternative is:
>
>Don't make the AVP mandatory always. Let the RADIUS server (or
>implementation) decide whether to enable/disable the "M" bit.
>[Bernard Aboba] Personally, I like alternative 1 better.=20

This should have a similar outcome to issue 39, in that 'M-bit'
references are removed in favor of the capabilities attribute.

Cheers,
MS

--------------------------------------------
Mauricio Sanchez, CISSP
Network Security Architect
Procurve Networking Business
Hewlett Packard
8000 Foothills Boulevard, ms 5555
Roseville CA, 95747-5557

916.785.1910 Tel
916.785.1815 Fax
[email-masked]
--------------------------------------------  =20

------_=_NextPart_001_01C507F5.3DB0AF47
Content-Type: text/html;
	charset="US-ASCII"
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 =
6.5.7226.0">
<TITLE>Issue 42: Are the Attributes Really Mandatory?</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">Nagi writes...</FONT>
</P>

<P><B><FONT SIZE=3D2 FACE=3D"Courier New">&gt;Issue 42: Are the =
Attributes Really Mandatory?</FONT></B><BR>
<FONT SIZE=3D2 FACE=3D"Courier New">&gt;Submitter: Nagi Reddy =
Jonnala<BR>
&gt;Submitter email address: </FONT><A =
HREF=3D"mailto:[email-masked]"><U><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Courier New">[email-masked]</FONT></U></A><BR>
<FONT SIZE=3D2 FACE=3D"Courier New">&gt;Date first submitted: December =
14, 2004</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;Reference: </FONT><A =
HREF=3D"http://ops.ietf.org/lists/radiusext/2004/msg00989.html"><U><FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier =
New">http://ops.ietf.org/lists/radiusext/2004/msg00989.html</FONT></U></A=
><BR>
<FONT SIZE=3D2 FACE=3D"Courier New">&gt;Document: Congdon-02<BR>
&gt;Comment type: T<BR>
&gt;Priority: 1<BR>
&gt;Section: Various<BR>
&gt;Rationale/Explanation of issue:</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;All the AVPs have the =
&quot;M&quot; bit enabled which means that the&nbsp; NAS MUST</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;understand the given =
attribute. I disagree with this. Having the default</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;value/action in case the =
RADIUS server doesn't return is already in</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;practice (for example =
locally configured interim interval, session</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;timeout). It is also true =
with some/all of the attributes mentioned in</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;this draft.&nbsp; For =
instance, understanding Egress-VLANID should never be</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;mandatory because the system =
might already have a default allowed set of</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;VLANIDs.</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;Requested change:</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;First alternative is:</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;Use the idea suggested by =
Bernard to advertise the Capabilities of &quot;new&quot;</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;attributes in Access-Request =
and I like this idea.</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;Second alternative =
is:</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;Don't make the AVP mandatory =
always. Let the RADIUS server (or</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;implementation) decide =
whether to enable/disable the &quot;M&quot; bit.</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;[Bernard Aboba] Personally, =
I like alternative 1 better. </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">This should have a similar outcome to =
issue 39, in that 'M-bit' references are removed in favor of the =
capabilities attribute.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Cheers,</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">MS</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 =
FACE=3D"Arial">--------------------------------------------</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Mauricio Sanchez</FONT><FONT SIZE=3D2 =
FACE=3D"Arial">, CISSP</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Network Security Architect</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Procurve Networking Business</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Hewlett Packard</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">8000 Foothills Boulevard, ms =
5555</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Roseville CA, 95747-5557</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">916.785.1910 Tel</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">916.785.1815 Fax</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">[email-masked]</FONT>

<BR><FONT SIZE=3D2 =
FACE=3D"Arial">--------------------------------------------&nbsp;&nbsp; =
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C507F5.3DB0AF47--

--
to unsubscribe send 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, 01 Feb 2005 00:27:48 +0000
Content-class: urn:content-classes:message
Subject: Issue 39: Backward Compatibility of Filter Attributes
Date: Mon, 31 Jan 2005 16:26:23 -0800
From: "Sanchez, Mauricio (PNB Roseville)" <[email-masked]>
To: <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C507F4.A985FF4D
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Either Bernard or Dave attest..

>Issue 39: Backward Compatibility of Filter Attributes
>Submitter name: Bernard Aboba
>Submitter email address: mailto:[email-masked]
>I am not sure that use of a "M" andatory bit is the right way to
vgo for this document. This requires substantial changes
>to RADIUS and will make it more difficult to deploy the IEEE 802
>Extensions.=20
>
>In the CUI document, it has been suggested that an empty CUI
>attribute be used for the NAS to advertise CUI support within
>the Access-Request.=20
>
>This approach does not seem to work for this document, which=20
>includes multiple attributes that might be considered mandatory,
>such as security-related attributes such (e.g. NAS-Filter-Rule).=20
>
>A simpler way to handle backward compatibility would be to define a
>"Capabilities" attribute that would contain the Type values
>for all new attributes that the NAS supports. Since one
>Capabilities attribute can be 253 octets in size, up to 253
>attributes could be advertised by the NAS in a single attribute.=20
>That RADIUS server would then only include a NAS-Filter-Rule attribute
>in an Access-Accept if support was advertised in the Capabilities
>attribute.=20

Paul and I have come to agree that the 'M' bit does not work very well
in this instance.  I propose striking all references to the 'M' bit from
the document and defer to the outcome of the capabilities attribute
discussion.=20

Cheers,
MS

--------------------------------------------
Mauricio Sanchez, CISSP
Network Security Architect
Procurve Networking Business
Hewlett Packard
8000 Foothills Boulevard, ms 5555
Roseville CA, 95747-5557

916.785.1910 Tel
916.785.1815 Fax
[email-masked]
--------------------------------------------  =20

------_=_NextPart_001_01C507F4.A985FF4D
Content-Type: text/html;
	charset="US-ASCII"
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 =
6.5.7226.0">
<TITLE>Issue 39: Backward Compatibility of Filter Attributes</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">Either Bernard or Dave attest..</FONT>
</P>

<P><B><FONT SIZE=3D2 FACE=3D"Courier New">&gt;Issue 39: Backward =
Compatibility of Filter Attributes</FONT></B>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;Submitter name: Bernard =
Aboba</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;Submitter email address: =
</FONT><A HREF=3D"mailto:[email-masked]"><U><FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier =
New">mailto:[email-masked]</FONT></U></A>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;I am not sure that use of a =
&quot;M&quot; andatory bit is the right way to</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">vgo for this document. This =
requires substantial changes</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;to RADIUS and will make it =
more difficult to deploy the IEEE 802</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;Extensions. </FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;In the CUI document, it has =
been suggested that an empty CUI</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;attribute be used for the =
NAS to advertise CUI support within</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;the Access-Request. </FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;This approach does not seem =
to work for this document, which </FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;includes multiple attributes =
that might be considered mandatory,</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;such as security-related =
attributes such (e.g. NAS-Filter-Rule). </FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;A simpler way to handle =
backward compatibility would be to define a</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;&quot;Capabilities&quot; =
attribute that would contain the Type values</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;for all new attributes that =
the NAS supports. Since one</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;Capabilities attribute can =
be 253 octets in size, up to 253</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;attributes could be =
advertised by the NAS in a single attribute. </FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;That RADIUS server would =
then only include a NAS-Filter-Rule attribute</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;in an Access-Accept if =
support was advertised in the Capabilities</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt;attribute. </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Paul and I have come to agree that the =
'M' bit does not work very well in this instance.&nbsp; I propose =
striking all references to the 'M' bit from the document and defer to =
the outcome of the capabilities attribute discussion. </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Cheers,</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">MS</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 =
FACE=3D"Arial">--------------------------------------------</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Mauricio Sanchez</FONT><FONT SIZE=3D2 =
FACE=3D"Arial">, CISSP</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Network Security Architect</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Procurve Networking Business</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Hewlett Packard</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">8000 Foothills Boulevard, ms =
5555</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Roseville CA, 95747-5557</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">916.785.1910 Tel</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">916.785.1815 Fax</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">[email-masked]</FONT>

<BR><FONT SIZE=3D2 =
FACE=3D"Arial">--------------------------------------------&nbsp;&nbsp; =
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C507F4.A985FF4D--

--
to unsubscribe send 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, 01 Feb 2005 00:15:05 +0000
Date: Mon, 31 Jan 2005 16:14:54 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: "Sanchez, Mauricio (PNB Roseville)" <[email-masked]>
cc: Avi Lior <[email-masked]>, [email-masked]
Subject: RE: Issue 38 - Ordering of filter attributes

> How often do you forsee generating a single NAS-Filter-Rule that would
> blow out a single RADIUS attribute?  Even so, why couldn't you spread
> out the rule over multiple attributes with the same net effect?  If
> anything, I do see an issue in running out of space for multiple rules
> (i.e. multiple NAS-Filter-Rule attributes) within a single
> Access-Accept.

Today's enterprise networks frequently involve many devices and prefixes.
It is not uncommon to see networks with 200 prefixes or thousands of
servers.

As a result, filters can easily become very large.  I have encountered a
situation with a customer where NAS-Filter-Rule attributes would be
unlikely to fit within a single RADIUS Access-Accept, even though each
rule would probably fit within a single attribute.

The question is what we do about it.  I asked about mixing Filter-Id
with NAS-Filter-Rule because it is compact.  Might there be a way of
supporting "named" filters where a subsequent Access-Accept could refer
back to a name?

--
to unsubscribe send 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, 01 Feb 2005 00:01:11 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue 38 - Ordering of filter attributes
Date: Mon, 31 Jan 2005 16:00:38 -0800
From: "Sanchez, Mauricio (PNB Roseville)" <[email-masked]>
To: "Avi Lior" <[email-masked]>, <[email-masked]>

Avi writes...

>=20
> There are two issues that need to be addressed.
>=20
> One is that one NAS-Filter-Rule maybe too large to fit a=20
> single RADIUS attribute; and A session may require several of=20
> these NAS attributes.
>=20
> Ordering is a given in RADIUS (as already described in the mail)
>=20
> Therefore receipient of the Access-Accept must be able to=20
> reconstruct a single NAS-Filter-Rule that extends over two or=20
> more attributes.  And then you need to build the list of=20
> NAS-Filter-Rules.
>=20
> Note that there is no specific hint to help detect a=20
> Filter-Rule that spans over more then one attribute.  For=20
> example a key word at the end that indicates that the rule is=20
> extended over the next attribute. =20
>=20

How often do you forsee generating a single NAS-Filter-Rule that would
blow out a single RADIUS attribute?  Even so, why couldn't you spread
out the rule over multiple attributes with the same net effect?  If
anything, I do see an issue in running out of space for multiple rules
(i.e. multiple NAS-Filter-Rule attributes) within a single
Access-Accept. =20

MS

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