Subject: Re: Issue 63: Request-ID Supplementation
From: "Alan DeKok" <[email-masked]>
To: Bernard Aboba <[email-masked]>
Cc: [email-masked]
Date: Tue, 24 May 2005 13:53:39 -0400

Bernard Aboba <[email-masked]> wrote:
> The RADIUS Request-ID shouldn't affect this algorithm.  However, once the
> Request-ID wraps you've got potentially more serious problems since the
> key stream used in encrypting "hidden" RADIUS attributes should be
> considered compromised.

  I agree.  And as you noted in your RADIUS security presentation,
this attack is not possible if the Message-Authenticator attribute is
required.  This says to me that if we can't deprecate PAP, we should
at least mandate the use of Message-Authenticator.

  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, 24 May 2005 04:47:54 +0000
Date: Mon, 23 May 2005 21:46:45 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Alan DeKok <[email-masked]>
cc: [email-masked]
Subject: Re: Issue 63: Request-ID Supplementation 

> Not in FreeRADIUS.  Our implementation does not track EAP
> identifiers by NAS-IP-Address or other attribute sent by the NAS.
> Instead, it uses the EAP identifier, source IP address, and the State
> attribute.  Since the State attribute is under the control of the
> RADIUS server, this means that the "uniqueness" of each session is
> under the control of the server, and not the NAS.
>
>   Since proxies may play games with NAS-IP-Address (e.g. translating
> private IP's to their own), depending on any attribute under control
> of the NAS may result in deployment problems.

I think this meets the requirements of RFC 3579.  The goal was for a
RADIUS server to be able to distinguish between EAP sessions regardless of
which NAS they came from.

>   A rough description of the algorithm used is as follows:
>
>   if (EAP start, or EAP identity) {
>      allocate unique State Attribute
>      insert into "active" queue, with key (EAP identifier, State, source IP)
>   } else {
>      look up active session in queue, with above key
>   }
>
>   The algorithm appears to work in deployment, including home servers
> which receive EAP sessions via intermediate RADIUS proxies.
>
> > Is it sufficient to address the Request-ID number space
> > "wrap-around" issue?
>
>   For RADIUS Request ID's?  I'm unclear.

The RADIUS Request-ID shouldn't affect this algorithm.  However, once the
Request-ID wraps you've got potentially more serious problems since the
key stream used in encrypting "hidden" RADIUS attributes should be
considered compromised.

--
to unsubscribe send a message 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, 21 May 2005 02:32:36 +0000
Date: Fri, 20 May 2005 19:31:42 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
cc: "Nelson, David" <[email-masked]>, [email-masked], [email-masked]
Subject: Consideration of draft-ietf-radext-chargeable-user-id-05.txt as a Proposed Standard

The RADEXT WG has completed its review of the "Chargeable User Identity"
specification (draft-ietf-radext-chargeable-user-id-05.txt) and recommends
to the IESG that it be considered as a Proposed Standard.

The document is available for inspection here:
http://www.ietf.org/internet-drafts/draft-ietf-radext-chargeable-user-id-05.txt

The issues discussed during development of the document are available here:
http://www.drizzle.com/~aboba/RADEXT/

The -05 version of the document resolves all open issues.

The CUI document describes a RADIUS attribute that enables a local
operator to obtain assurance that it has obtained a chargeable user
identity, even in cases where user privacy has been invoked, preventing
the local operator from learning the user identity.

While initial discussions of the document envisaged usage in a wide
variety of scenarios,  eventually the WG converged on only a single usage
scenario, which usage of the CUI attribute was requested by the NAS
device.  This enables resolution of issues relating to backward
compatibility.

Since the WG converged on the usage scenario, the document has not been
controversial.  An appeal is not expected.

--
to unsubscribe send a message 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, 19 May 2005 22:13:42 +0000
Date: Fri, 20 May 2005 00:13:07 +0200
From: [email-masked]
To: [email-masked]
Subject: draft-ietf-radext-dynauth-xxx-mib-00.txt

Hi,

The new drafts on the dynauth MIBs are available at

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

and

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

Only a few changes compared to the previous versions:
1) The syntax of radiusDynAuthServerClientPortNumber changed from 
Integer32 to InetPortNumber to line up with the other Radius MIB drafts
2) Some extra clarrification in the description of 
radiusDynAuthServDisconUserSessRemoved and 
radiusDynAuthServCoAUserSessChanged on what a dynauth server has to do 
if it does not know how many user sessions are impacted by a request 
(e.g., in case of a proxy).
3) some typos corrected.

All comments would be very welcome!

Thanks,

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

Envelope-to: [email-masked]
Delivery-date: Thu, 19 May 2005 17:30:59 +0000
From: "Alan DeKok" <[email-masked]>
To: Bernard Aboba <[email-masked]>
Subject: Re: Issue 63: Request-ID Supplementation 
Cc: [email-masked]
Date: Thu, 19 May 2005 13:28:27 -0400
Message-Id: <[email-masked]>

A long time ago, Bernard Aboba <[email-masked]> wrote:
> [ request Id supplementation ]
>
> 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?

  Yes.

> Is it commonly implemented?

  Not in FreeRADIUS.  Our implementation does not track EAP
identifiers by NAS-IP-Address or other attribute sent by the NAS.
Instead, it uses the EAP identifier, source IP address, and the State
attribute.  Since the State attribute is under the control of the
RADIUS server, this means that the "uniqueness" of each session is
under the control of the server, and not the NAS.

  Since proxies may play games with NAS-IP-Address (e.g. translating
private IP's to their own), depending on any attribute under control
of the NAS may result in deployment problems.

  A rough description of the algorithm used is as follows:

  if (EAP start, or EAP identity) {
     allocate unique State Attribute
     insert into "active" queue, with key (EAP identifier, State, source IP)
  } else {
     look up active session in queue, with above key
  }

  The algorithm appears to work in deployment, including home servers
which receive EAP sessions via intermediate RADIUS proxies.

> Is it sufficient to address the Request-ID number space
> "wrap-around" issue?

  For RADIUS Request ID's?  I'm unclear.

  Alan DeKok.

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

Delivery-date: Thu, 19 May 2005 03:42:32 +0000
Content-class: urn:content-classes:message
Subject: RE: REMINDER: Final Review of CUI-05
Date: Thu, 19 May 2005 06:42:10 +0300
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Hi,

> > I just realized that the first page needs to be updated with the =
latest
> > statement on intellectual property
> > rights (IPR).  Should I go ahead and submit an updated version (-06) =
or
> > wait till May 20th?
> > Thanks,
> > Farid
>=20
> Actually, I don't think you need to do anything until you need to =
submit
> an -06 for some other reason (e.g. IETF last call comment, etc.).

Agreed.

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: Thu, 19 May 2005 03:39:25 +0000
Date: Wed, 18 May 2005 20:38:40 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: "Adrangi, Farid" <[email-masked]>
cc: [email-masked]
Subject: RE: REMINDER: Final Review of CUI-05

> I just realized that the first page needs to be updated with the latest
> statement on intellectual property
> rights (IPR).  Should I go ahead and submit an updated version (-06) or
> wait till May 20th?
> Thanks,
> Farid

Actually, I don't think you need to do anything until you need to submit
an -06 for some other reason (e.g. IETF last call comment, etc.).

--
to unsubscribe send a message 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, 19 May 2005 01:47:59 +0000
Content-class: urn:content-classes:message
Subject: RE: REMINDER: Final Review of CUI-05
Date: Wed, 18 May 2005 18:47:24 -0700
From: "Adrangi, Farid" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>

I just realized that the first page needs to be updated with the latest
statement on intellectual property
rights (IPR).  Should I go ahead and submit an updated version (-06) or
wait till May 20th?
Thanks,
Farid

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Wednesday, May 18, 2005 5:02 PM
> To: [email-masked]
> Subject: REMINDER: Final Review of CUI-05
>=20
>=20
> WG Last Call has completed on the Chargeable User Identity=20
> document, and a
> new version (CUI-05) has been submitted that the author has indicated
> closes all the open issues (82 & 83).
>=20
> The revised document is available for inspection here:
> http://www.ietf.org/internet-drafts/draft-ietf-radext-chargeab
le-user-id-05.txt

The RADEXT Issues list is available here:
http://www.drizzle.com/~aboba/RADEXT/

If you have filed an open issue against the document, or if you have an
opinion about the resolution of Issues 82 or 83, or if you have any
other
last minute comments about this document, please post your Issue to the
RADEXT WG mailing list ASAP.

Assuming we do not hear anything by May 20, 2005 we will forward the
document on to the IESG for consideration as a proposed standard.

--
to unsubscribe send 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, 19 May 2005 00:03:28 +0000
Date: Wed, 18 May 2005 17:02:16 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: REMINDER: Final Review of CUI-05

WG Last Call has completed on the Chargeable User Identity document, and a
new version (CUI-05) has been submitted that the author has indicated
closes all the open issues (82 & 83).

The revised document is available for inspection here:
http://www.ietf.org/internet-drafts/draft-ietf-radext-chargeable-user-id-05.txt

The RADEXT Issues list is available here:
http://www.drizzle.com/~aboba/RADEXT/

If you have filed an open issue against the document, or if you have an
opinion about the resolution of Issues 82 or 83, or if you have any other
last minute comments about this document, please post your Issue to the
RADEXT WG mailing list ASAP.

Assuming we do not hear anything by May 20, 2005 we will forward the
document on to the IESG for consideration as a proposed standard.

--
to unsubscribe send 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, 13 May 2005 22:02:09 +0000
From: "Alan DeKok" <[email-masked]>
To: "Sanchez, Mauricio (PNB Roseville)" <[email-masked]>
Subject: Proposed Resolution to Issue 25: Issues with IEEE 802 Extensions Draft 
Cc: [email-masked]
Date: Fri, 13 May 2005 17:59:14 -0400
Message-Id: <[email-masked]>

  Once the proposed text included below is added to the draft, and my
one-sentence comment added[1], I agree that the issues is resolved.

   Alan DeKok.
[1] See the last line of this message.

"Sanchez, Mauricio (PNB Roseville)" <[email-masked]> wrote:
> > > 2.1.  Egress-VLANID
> >
> >   The text following this doesn't define the attribute
> > format, or where the VLANID goes.  ASCII art would be appreciated.
> 
> Propose following text:
> 
> "The Integer field is four octets in length.  The format of the Integer
> field consists of two parts, the first consuming high-order octet and
> the second consuming the remaining three lower-order octets.  The
> high-order octet field indicates if the VLANID is allowed for tagged or
> untagged packets.  The second part is the 12-bit 802.1Q VLAN VID value
> that has been padded out to consume the remaining three lower-order
> octets.  A sample encoding follows:
> 
> 	 0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |  Tag Option   |      Pad (12-bit)     |       VLANID (12-bit) |
> 
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>     Values for the Tag Option part include:
> 	      1 = Tagged
>    	   2 = Untagged
> 
> 		Padding bits SHOULD be 0 (zero).
> 
> 		VLANID is the 12-bit 802.1Q-2003 VID value. "
> 
> > 
> >   Section 1.2 talks about possibly using the "extended attribute"
> > format, and says that the following lengths are calculated 
> > using the short form.  If so, for consistency, ASCII art of 
> > the attributes showing the short form would be good, even if 
> > there isn't consensus that it's the proper format to use.
> 
> 
> All usage of extended attributes have been completely removed from
> draft. 
> 
> > 
> >   Also, the data types are "Integer32" and "UInt32".  Are 
> > these RADIUS types, or new types?  It should be clarified as 
> > to where these types come from.
> 
> All non-traditional datatypes have been removed and replaced with a
> traditional RFC2865 datatypes.
> 
> > 
> > >2.3.  VLAN-Name
> > >
> > >   Description
> > ...
> > >      The VLAN-Name attribute contains two parts; the first 
> > part is the
> > >      VLAN name, the second part indicates if frames on the VLAN for
> > >      this port are to be represented in tagged or untagged format.
> > 
> >   I suggest arranging the attribute so that the "tagged/untagged"
> > information is at the same offset in the attribute as the 
> > Egress-VLANID attribute.  Putting the value after 
> > variable-length "String" data makes it harder to parse.  
> > Putting the value in a different place than in the 
> > Egress-VLANID attribute creates more "special-case" 
> > considerations in the code.
> 
> Suggestion taken. Propose following format:
> 
> "The first octet of this string indicates whether the frames on the VLAN
> are tagged 0x01 or Untagged 0x02.  The remaining octets represent the
> VLAN Name as defined in 802.1Q-2003 clause 12.10.2.1.3 (a).  UTF-8
> encoded 10646 characters are recommended, but a robust implementation
> SHOULD support the field as undistinguished octets."
> 
> 
> > 
> > > 2.4.  User-Priority-Table
> > ...
> > > Data-Type
> > >
> > >      UInt64
> > 
> >   Q: Is this the first proposed 64-bit integer data type in RADIUS?
> 
> Would have been, but as mentioned above, all usage of non-traditional
> RADIUS datatypes have been removed.  Therefore, 64-bit integer no longer
> proposed.  
> 
> > 
> > >2.12.  Origin-Realm
> > 
> >   Add missing text: This attribute is defined as an Extended 
> > RADIUS attribute.
> 
> This attribute has been removed from draft. 
> 
> > 
> > > 3.1.  Accounting-EAP-Auth-Method
> > ...
> > >Value
> > >
> > >      The Value field is eight octets.  In case of expanded types
> > >      defined in [RFC3748] Section 5.7, the least significant 32 bits
> > >      contain the Vendor-Type field, and the next 24 bits contain the
> > >      Vendor-Id field.
> > 
> >   Leaving 8 bits of... what?
> > 
> >   Again, ASCII art, even using the proposed format from 
> > Appendix A would help clarify the attribute.
> 
> Propose following clarifying text:
> 
> "The Value field is eight octets.  In case of expanded types
> defined in [RFC3748] Section 5.7, the least significant 32 bits
> contain the Vendor-Type field, and the next 24 bits contain the
> Vendor-Id field.:

  And 8 bits reserved bits, which SHOULD be zero.

--
to unsubscribe send a message 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, 12 May 2005 09:19:50 +0000
Date: Thu, 12 May 2005 12:19:05 +0300
From: Jari Arkko <[email-masked]>
To: "Sanchez, Mauricio (PNB Roseville)" <[email-masked]>
CC:  [email-masked]
Subject: Re: Issue 56: Capabilities Attribute

I agree that cutting functionality is a good way to
achieve a deadline. Are there any remaining issues
wrt. the security properties of unknown support for
filters etc?

--Jari

Sanchez, Mauricio (PNB Roseville) wrote:

>Bernard pointed out...
>
>
>  
>
>>Issue 56: Capabilities Attribute
>>Submitter name: Bernard Aboba
>>Submitter email address: [email-masked] Date first 
>>submitted: January 28, 2005
>>Reference: http://ops.ietf.org/lists/radiusext/2005/msg00034.html
>>Document: CUI, IEEE 802
>>Comment type: T
>>Priority: S
>>Section: Various
>>Rationale/Explanation of issue:
>>Farid mentioned in his last message that we might want to 
>>move ahead on defining a general Capabilities attribute.  
>>Here is a strawman proposal:
>>
>>    
>>
><...strawman proposal removed for brevity...>
>  
>
>>   String2
>>
>>      The String2 field is one or more octets.  The actual 
>>format of the
>>      information is site or application specific as described in
>>      [RFC2865] Section 5.26.
>>[Glen Zorn]
>>Why only client & request?
>>[Bernard Aboba]
>>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?
>>Proposed Resolution: Discuss
>>    
>>
>
>The question of a capability attribute is one that puts the timeliness
>for completion of the ieee802 draft in jeopardy.  The design team has
>decided to punt in the short-term and not have a direct dependence on a
>capability attribute.  Proposed text follows:
>
>"2.1. Capability Advertisement
>
>RADIUS does not currently define a method by which a NAS can advertise
>its capabilities and in many instances, it would be desirable for the
>home network to know what capabilities are supported by the NAS to
>ensure proper operational behavior. The attributes defined in this
>document are intended to be used to enforce policy by the NAS. If a NAS
>does not recognize these attributes it will most likely ignore them and
>the desired policy will not be enforced. A method for the NAS
>advertising the capability to support these attributes would help the
>AAA server understand if the intended policies can be enforced.
>Inasmuch, we expect this lack of generalized capability advertisement to
>be rectified and when available, should minimally be used in conjunction
>with the NAS-Filter-Rule(TBD) attribute. "
>
>
>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/>
>
>
>  
>

--
to unsubscribe send a message 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, 12 May 2005 00:27:30 +0000
Content-class: urn:content-classes:message
Subject: Issue 58: End-to-End Capabilities
Date: Wed, 11 May 2005 17:27:04 -0700
From: "Sanchez, Mauricio (PNB Roseville)" <[email-masked]>
To: <[email-masked]>

Jari chimed in...
=20
> Issue 58: End-to-End Capabilities
> Submitter name: Jari Arkko
> Submitter email address: [email-masked] Date first=20
> submitted: January 20, 2005
> Reference: http://ops.ietf.org/lists/radiusext/2005/msg00062.html
> Document: CUI, IEEE 802
> Comment type: T
> Priority: S
> Section: Various
> Rationale/Explanation of issue:
> I agree that we need a capabilities function. But I would=20
> like to see a relatively coarse granularity facility, rather=20
> than something that sends data about individual attributes.=20
> For instance, I liked the list that someone made up about=20
> prepaid, filtering capability, redirection, etc. The right=20
> granularity to me appears to roughly one RFC. I say roughly=20
> because I do want to prepare for the possibility that, say,=20
> prepaid has a small number of different profiles*.
> And yes, there can be capabilities that don't map nicely to=20
> new attributes.
> There seems to be a few different kinds of capabilities=20
> negotiation, by the way. In Diameter, for instance, we have=20
> hop-by-hop negotiation. The primary purpose of this scheme is=20
> to ensure to provide information for routing purposes.
> But another type of negotiation is something that occurs=20
> end-to-end with a specific home system, and this is what we=20
> attempt to address in the various proposals right now. The=20
> primary purpose of this is to ensure whether we can send an=20
> attribute or command or expect a behavior relating to this=20
> specific user's session.
> =20
> The difference between the two approaches is that even if you=20
> know next-hop wise that FOO is supported, you don't know if=20
> FOO is supported for the particular user's session at a=20
> particular home domain. Note that the end-to-end negotiation=20
> is typically limited to the capabilities of the server that=20
> you currently talk to; it may well be that even if FOO=20
> doesn't exist on the authentication server it might exist on=20
> the accounting server at the same domain. This part is harder=20
> to solve, so I presume we are not going to require it.
> Anyway, here's my strawman approach to capabilities
> negotiation:
> 1. End-to-end Capability Attribute
>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |     Type      |    Length     |     Capabilities string ...
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    Type
>      TBD for end-to-end capability attribute.
>    Length
>      The length.
>    Capabilities string
>      This field contains a variable length bit string. Each
>      bit position, if set to 1, indicates full compliance
>      with the respective feature specification.
>      An initial allocation of bits for different features
>      is listed below:
>      Bit 0 (NASREQ) Support for basic authentication and
>                     authorization service [RFC 2865, I-D.NASREQ].
>                     Mandatory in RADIUS.
>      Bit 1 (MOBILE IPv4) Support for Mobile IPv4 [I-D.MIPv4].
>      Bit 2 (PREPAID) Support for prepaid services [I-D.Prepaid-R,
>                      I-D.Prepaid-D].
>      Bit 3 (ACCOUNTING) Support for accounting [RFC 2866, RFC 3855].
>      Bit 4 (FILTER-RULE) Support for generalized filters (mandatory
>                          in Diameter nodes and optional for RADIUS
>                          nodes).
>      Bit 5 (REDIRECT) Support for user-session redirection
>                       feature (I-D.redirect).
>      Bit 6 (CUI) Support for the CUI functionality (I-D.CUI).
>      Bit 7 (LOCATION) Support for the location attributes (I-D.LOC).
>      Bit 128 (CX) Support for the 3GPP CX application.
>      Bit 129 (Sh) Support for the 3GPP Sh application.
>      Bit 130 (Rf/Ro) Support for the 3GPP Rf/Ro application.
> 2. Diameter Compatibility
>    This attribute functions in an equivalent manner in both
>    RADIUS and Diameter. In Diameter, the base protocol layer
>    may fill in the attribute values automatically based on its
>    knowledge of applications running on top of it.
>    Note that a single bit has been allocated for a feature
>    if it is expected that it is supported in the same manner
>    in RADIUS and Diameter and that translation rules exist.
>    In this situation the peer does not care whether Diameter
>    or RADIUS is used on the other side. Otherwise, separate
>    bits have been allocated.
> 3. IANA Considerations
>    IANA should create a new name space, Capabilities Bit.
>    The initial values in this name space include those
>    listed in Section 1. New values in the 0-128 range can
>    be allocated through IETF Consensus. Other values (upto
>    2023 i.e. 253 bytes times 8 bits) can be allocated
>    on a First-Come First Served basis with Specification
>    Required.
> --Jari

As with issue 57, the question of a capability attribute is one that
puts the timeliness for completion of the ieee802 draft in jeopardy.
The design team has decided to punt in the short-term and not have a
direct dependence on a capability attribute.  Proposed text follows:

"2.1. Capability Advertisement

RADIUS does not currently define a method by which a NAS can advertise
its capabilities and in many instances, it would be desirable for the
home network to know what capabilities are supported by the NAS to
ensure proper operational behavior. The attributes defined in this
document are intended to be used to enforce policy by the NAS. If a NAS
does not recognize these attributes it will most likely ignore them and
the desired policy will not be enforced. A method for the NAS
advertising the capability to support these attributes would help the
AAA server understand if the intended policies can be enforced.
Inasmuch, we expect this lack of generalized capability advertisement to
be rectified and when available, should minimally be used in conjunction
with the NAS-Filter-Rule(TBD) attribute. "

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: Thu, 12 May 2005 00:24:24 +0000
Content-class: urn:content-classes:message
Subject: Issue 56: Capabilities Attribute
Date: Wed, 11 May 2005 17:23:47 -0700
From: "Sanchez, Mauricio (PNB Roseville)" <[email-masked]>
To: <[email-masked]>

Bernard pointed out...

> Issue 56: Capabilities Attribute
> Submitter name: Bernard Aboba
> Submitter email address: [email-masked] Date first=20
> submitted: January 28, 2005
> Reference: http://ops.ietf.org/lists/radiusext/2005/msg00034.html
> Document: CUI, IEEE 802
> Comment type: T
> Priority: S
> Section: Various
> Rationale/Explanation of issue:
> Farid mentioned in his last message that we might want to=20
> move ahead on defining a general Capabilities attribute. =20
> Here is a strawman proposal:
>=20
<...strawman proposal removed for brevity...>
>    String2
>=20
>       The String2 field is one or more octets.  The actual=20
> format of the
>       information is site or application specific as described in
>       [RFC2865] Section 5.26.
> [Glen Zorn]
> Why only client & request?
> [Bernard Aboba]
> The usage scenario I had in mind was a NAS announcing to a=20
> server that it supported various attributes.  This could be=20
> useful, for debugging purposes (oops, I forgot to upgrade=20
> that NAS!), or backward compatibility (server won't send a=20
> new attribute to a NAS that doesn't support it).
>=20
> Can you describe how a server could use a Capabilities attribute?
> Proposed Resolution: Discuss

The question of a capability attribute is one that puts the timeliness
for completion of the ieee802 draft in jeopardy.  The design team has
decided to punt in the short-term and not have a direct dependence on a
capability attribute.  Proposed text follows:

"2.1. Capability Advertisement

RADIUS does not currently define a method by which a NAS can advertise
its capabilities and in many instances, it would be desirable for the
home network to know what capabilities are supported by the NAS to
ensure proper operational behavior. The attributes defined in this
document are intended to be used to enforce policy by the NAS. If a NAS
does not recognize these attributes it will most likely ignore them and
the desired policy will not be enforced. A method for the NAS
advertising the capability to support these attributes would help the
AAA server understand if the intended policies can be enforced.
Inasmuch, we expect this lack of generalized capability advertisement to
be rectified and when available, should minimally be used in conjunction
with the NAS-Filter-Rule(TBD) attribute. "

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: Thu, 12 May 2005 00:11:17 +0000
Content-class: urn:content-classes:message
Subject: Issue 25: Issues with IEEE 802 Extensions Draft
Date: Wed, 11 May 2005 17:09:52 -0700
From: "Sanchez, Mauricio (PNB Roseville)" <[email-masked]>
To: <[email-masked]>

Alan wrote a very long time ago...
=20

> -----Original Message-----
> *	Subject: Re: New version of IEEE 802 Attributes Draft Available=20
> *	From: "Alan DeKok" <[email-masked] <mailto:aland%40ox.org> >=20
> *	Date: Sun, 07 Nov 2004 20:03:11 -0500=20
> http://www.drizzle.com/~aboba/RADEXT/draft-congdon-radext-ieee
> 802-02.txt
> > 2.1.  Egress-VLANID
>=20
>   The text following this doesn't define the attribute=20
> format, or where the VLANID goes.  ASCII art would be appreciated.

Propose following text:

"The Integer field is four octets in length.  The format of the Integer
field consists of two parts, the first consuming high-order octet and
the second consuming the remaining three lower-order octets.  The
high-order octet field indicates if the VLANID is allowed for tagged or
untagged packets.  The second part is the 12-bit 802.1Q VLAN VID value
that has been padded out to consume the remaining three lower-order
octets.  A sample encoding follows:=20

	 0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Tag Option   |      Pad (12-bit)     |       VLANID (12-bit) |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Values for the Tag Option part include:
	      1 =3D Tagged
   	   2 =3D Untagged
	=09
		Padding bits SHOULD be 0 (zero).

		VLANID is the 12-bit 802.1Q-2003 VID value. "

>=20
>   Section 1.2 talks about possibly using the "extended attribute"
> format, and says that the following lengths are calculated=20
> using the short form.  If so, for consistency, ASCII art of=20
> the attributes showing the short form would be good, even if=20
> there isn't consensus that it's the proper format to use.

All usage of extended attributes have been completely removed from
draft.=20

>=20
>   Also, the data types are "Integer32" and "UInt32".  Are=20
> these RADIUS types, or new types?  It should be clarified as=20
> to where these types come from.

All non-traditional datatypes have been removed and replaced with a
traditional RFC2865 datatypes.

>=20
> >2.3.  VLAN-Name
> >
> >   Description
> ...
> >      The VLAN-Name attribute contains two parts; the first=20
> part is the
> >      VLAN name, the second part indicates if frames on the VLAN for
> >      this port are to be represented in tagged or untagged format.
>=20
>   I suggest arranging the attribute so that the "tagged/untagged"
> information is at the same offset in the attribute as the=20
> Egress-VLANID attribute.  Putting the value after=20
> variable-length "String" data makes it harder to parse. =20
> Putting the value in a different place than in the=20
> Egress-VLANID attribute creates more "special-case"=20
> considerations in the code.

Suggestion taken. Propose following format:

"The first octet of this string indicates whether the frames on the VLAN
are tagged 0x01 or Untagged 0x02.  The remaining octets represent the
VLAN Name as defined in 802.1Q-2003 clause 12.10.2.1.3 (a).  UTF-8
encoded 10646 characters are recommended, but a robust implementation
SHOULD support the field as undistinguished octets."

>=20
> > 2.4.  User-Priority-Table
> ...
> > Data-Type
> >
> >      UInt64
>=20
>   Q: Is this the first proposed 64-bit integer data type in RADIUS?

Would have been, but as mentioned above, all usage of non-traditional
RADIUS datatypes have been removed.  Therefore, 64-bit integer no longer
proposed. =20

>=20
> >2.12.  Origin-Realm
>=20
>   Add missing text: This attribute is defined as an Extended=20
> RADIUS attribute.

This attribute has been removed from draft.=20

>=20
> > 3.1.  Accounting-EAP-Auth-Method
> ...
> >Value
> >
> >      The Value field is eight octets.  In case of expanded types
> >      defined in [RFC3748] Section 5.7, the least significant 32 bits
> >      contain the Vendor-Type field, and the next 24 bits contain the
> >      Vendor-Id field.
>=20
>   Leaving 8 bits of... what?
>=20
>   Again, ASCII art, even using the proposed format from=20
> Appendix A would help clarify the attribute.

Propose following clarifying text:

"The Value field is eight octets.  In case of expanded types
defined in [RFC3748] Section 5.7, the least significant 32 bits
contain the Vendor-Type field, and the next 24 bits contain the
Vendor-Id field.:

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

Envelope-to: [email-masked]
Delivery-date: Wed, 11 May 2005 22:27:42 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Cc: 
Subject: RFC 2866 nit
Message-Id: <[email-masked]>
Date: Wed, 11 May 2005 18:25:28 -0400 (EDT)

  I don't think this is serious enough to warrant an ISSUE, but I just
noticed that RFC 2866 describes Acct-Session-Id as "text" in the ASCII
art, and as "string" in the description following.  RFC 2865 uses
either "text" and "text", or "string" and "string".

  Alan DeKok.

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

Envelope-to: [email-masked]
Delivery-date: Wed, 11 May 2005 22:15:50 +0000
From: "Alan DeKok" <[email-masked]>
To: Jari Arkko <[email-masked]>
Subject: Re: Implementation Survey: How does your EAP peer/RADIUS proxy handle internationalization? 
Cc: [email-masked]
Date: Wed, 11 May 2005 18:13:16 -0400
Message-Id: <[email-masked]>

Jari Arkko <[email-masked]> wrote:
> >  Years of deployment without complaints is a strong indicator that a
> >problem doesn't exist.  Let's let sleeping dogs lie.
> >
> Ok. But I'd still like to understand this better. Or I really
> need to, because we need to decide whether to
>   (a) strip i18n out of the bis draft altogether
>   (b) keep current utf-8 + plain-old-dns-name-but-as-idnunaware-
>         name-slot scheme
>   (c) change to utf-8 altogether

  I would say (b).

> Also, before you answer the above lets try to get some
> understanding on whether "no complaints" means
>   (i) no one is using i18n dns names yet. i have some sense
>       that this might be the case, as at least here in Finland
>       I think they allowed the new types of allocations
>       very recently.

  Mosrly.  i18n domain names have historically been rare.

>   (ii) existing support (just let utf-8 through) is working
>        well

  Definitely.

>   (iii) solutions from a single vendor work well, but
>         not a lot of interop has been attempted with this
>         particular case

  I would say that interoperability hasn't been *reported* on.  But
the deployments of RADIUS are so varied that I would be surprised if
interoperability isn't already being tested in live situations.

  I haven't heard of i18n problems with interoperability.  My guess,
therefore, is that such problems are rare.

  Alan DeKok.

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

Delivery-date: Wed, 11 May 2005 19:56:51 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposed Resolution to Issue 87 (RADIUS MIB Updates)
Date: Wed, 11 May 2005 15:56:34 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

> Question:  How does this work for NASes that support both IPv4 and
IPv6?
> Which objects would such devices use?

Here's some additional advice on this question, from David Harrington,
MIB Doctor.  Below is a portion of Dave's reply to my informal query, of
today, on how to handle the details of this issue.  This does not
constitute formal MIB Doctor review.

<quote>

I think you would also need to specify that an implementation MUST NOT
have different addresses in radiusAuthServerAddress [old object] and
radiusAuthServerInetAddress [new object]. It would probably be
acceptable to have an IPv6-formatted IPv4 address in the InetAddress and
the IPv4 format of the same address in the IPAddress object.

Note from RFC3291:
   "A single host system may be configured with multiple addresses (IPv4
   or IPv6), and possibly with multiple DNS names.  Thus it is possible
   for a single host system to be accessible by multiple
   InetAddressType/InetAddress pairs.

   If this could be an implementation or usage issue, the DESCRIPTION
   clause of the relevant objects must fully describe which address is
   reported in a given InetAddressType/InetAddress pair."

So it is possible that there is an IPv6 InetAddress, and
radiusAuthServerAddress COULD be used to store the IPv4 address of the
same server; I feel uneasy about doing this, because it would tend to
prolong the use of the deprecated radiusAuthServerAddress object, and
would have forward-compatibility issues for applications that only
supported the InetAddress objects, and only supported IPv4
communications; it could not retrieve the IPv4 address of the server.  I
would prefer to see one row for the IPv6 InetAddress, and another row
for the IPv4 InetAddress.

In any case, the MIB module (when separated from the surrounding text)
should be clear on how this should be handled.

</quote>

So, I guess we need to clarify the issues around multi-version IP stacks
on RADIUS servers (and clients) and include that guidance in the
relevant DESCRIPTION clauses of the MIB modules.

I would interpret this advice to suggest that a dual-stack RADIUS server
would need to have (at least) two row entries in the client's table of
servers, such that the IPv4 address was never confused with the IPv6
address.  Bernard has already indicated that robust client
implementations might not want to fail over from the IPv6 address of one
server host to the IPv4 address of the same host.

Dave H. also recommends:

<quote>

Write a compliance clause that calls for use of the new object, not the
old. Deal with backwards compatibility by deprecating the old compliance
clause and add a new compliance clause that includes the new address
objects and does not include the deprecated object.  Implementations can
always support both compliance clauses if they choose.

</quote>

If there are no objections, I will proceed to revise the drafts based on
the collected MIB Doctor suggestions.

--
to unsubscribe send a message 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, 11 May 2005 19:37:59 +0000
Date: Wed, 11 May 2005 22:37:37 +0300
From: Jari Arkko <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: "Nelson, David" <[email-masked]>,  [email-masked]
Subject: Re: Implementation Survey: How does your EAP peer/RADIUS proxy handle internationalization?

Bernard Aboba wrote:

>>I concur with the sentiment, but I wonder if the text in the NAIbis
>>draft, that purports to add internationalization support, has already
>>awakened that particular canine?  :-)
>>    
>>
>
>Based on the responses, sending NAIs in UTF-8 within the
>EAP-Response/Identity will not awaken the canine.
>  
>
But I'm still concerned that we are not doing any of
the normalization and mapping stuff that seems to
be necessary in order to get comparisons right.
I agree that it should not be done by proxies. But it
should be done at  the time you enter the stuff to the
db, or type the NAI to the client machine. But it seemed
like implementations are not doing that either.

>>From what we've heard it sounds like RADIUS proxy implementations handle
>the User-Name attribute as opaque octets, and that may be all we should
>assume.
>
>Avi's Issue 75 (leave the NAI in UTF-8) seems to be compatible with that
>perspective.
>  
>
I suppose the other alternative, assuming the realms are
idn-unaware name slots could also be argued to be compatible
with that. Except in the ! case but there we are not treating
the attribute as opaque octets anyway.

--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: Wed, 11 May 2005 19:37:53 +0000
Date: Wed, 11 May 2005 22:37:34 +0300
From: Jari Arkko <[email-masked]>
To: Alan DeKok <[email-masked]>
CC: Bernard Aboba <[email-masked]>,  [email-masked]
Subject: Re: Implementation Survey: How does your EAP peer/RADIUS proxy handle internationalization?

Hi Alan,

>  Years of deployment without complaints is a strong indicator that a
>problem doesn't exist.  Let's let sleeping dogs lie.
>  
>
Ok. But I'd still like to understand this better. Or I really
need to, because we need to decide whether to
  (a) strip i18n out of the bis draft altogether
  (b) keep current utf-8 + plain-old-dns-name-but-as-idnunaware-
        name-slot scheme
  (c) change to utf-8 altogether

In some sense all of these approaches can be argued
to be doing as little as possible. Which one do you want?

Also, before you answer the above lets try to get some
understanding on whether "no complaints" means
  (i) no one is using i18n dns names yet. i have some sense
      that this might be the case, as at least here in Finland
      I think they allowed the new types of allocations
      very recently.
  (ii) existing support (just let utf-8 through) is working
       well
  (iii) solutions from a single vendor work well, but
        not a lot of interop has been attempted with this
        particular case

--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: Wed, 11 May 2005 18:41:44 +0000
Date: Wed, 11 May 2005 11:41:30 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Update on the IEEE 802 extensions document?

Could the authors please post proposed resolutions (or at least updates)
on the open issues?

I'd like to get this document cleaned up and accepted as a WG work item by
the end of this month.

--
to unsubscribe send a message 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, 11 May 2005 18:33:59 +0000
Date: Wed, 11 May 2005 11:33:21 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: "Nelson, David" <[email-masked]>
cc: [email-masked]
Subject: RE: Implementation Survey: How does your EAP peer/RADIUS proxy handle internationalization? 

> I concur with the sentiment, but I wonder if the text in the NAIbis
> draft, that purports to add internationalization support, has already
> awakened that particular canine?  :-)

Based on the responses, sending NAIs in UTF-8 within the
EAP-Response/Identity will not awaken the canine.

>From what we've heard it sounds like RADIUS proxy implementations handle
the User-Name attribute as opaque octets, and that may be all we should
assume.

Avi's Issue 75 (leave the NAI in UTF-8) seems to be compatible with that
perspective.

--
to unsubscribe send a message 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, 11 May 2005 18:21:40 +0000
Content-class: urn:content-classes:message
Subject: RE: Implementation Survey: How does your EAP peer/RADIUS proxy handle internationalization? 
Date: Wed, 11 May 2005 14:21:24 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Alan DeKok writes...

> Let's let sleeping dogs lie.

I concur with the sentiment, but I wonder if the text in the NAIbis
draft, that purports to add internationalization support, has already
awakened that particular canine?  :-)

--
to unsubscribe send a message 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, 11 May 2005 18:13:56 +0000
Date: Wed, 11 May 2005 11:13:47 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: "Beck01, Wolfgang" <[email-masked]>
cc: [email-masked]
Subject: Re: Issue:

Assigned Issue 91.

Are there any objections to these changes?

Otherwise, I propose that this Issue be accepted.

On Wed, 11 May 2005, Beck01, Wolfgang wrote:

> typos in section 'RADIUS server behaviour'
>
> Submitter name: Wolfgang Beck
> Submitter email address: [email-masked]
> Date first submitted: 11 May 2005
> Document: draft-ietf-radext-digest-auth-02.txt
> Comment type: E
> Priority: S
> Section: 2.2
> Rationale/Explanation of issue:
> missing verb in
>   'The RADIUS server Digest-Realm, Message-Authenticator (see
>    [RFC3579]), SHOULD add Digest-Algorithm, one or more Digest-Qop and
>    MAY add Digest-Domain, Digest-Opaque attributes to the Access-
>    Challenge message.'
>
> and
>
>    'A RADIUS MUST check if the RADIUS client is authorized to serve users
>    of the realm mentioned in the Digest-Realm attribute.'
>
> Requested change:
>   'The RADIUS server MUST add Digest-Realm, Message-Authenticator (see
>    [RFC3579]), SHOULD add Digest-Algorithm, one or more Digest-Qop and
>    MAY add Digest-Domain, Digest-Opaque attributes to the Access-
>    Challenge message.'
>
>    'A RADIUS server MUST check if the RADIUS client is authorized to
>    serve users of the realm mentioned in the Digest-Realm 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/>
>

--
to unsubscribe send a message 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, 11 May 2005 18:09:02 +0000
Date: Wed, 11 May 2005 11:08:49 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: "Beck01, Wolfgang" <[email-masked]>
cc: [email-masked]
Subject: Re: Proposed Resolution to Issue 7:

If there are no objections, I propose we accept this resolution.

On Wed, 11 May 2005, Beck01, Wolfgang wrote:

> 2.  Detailed Description
>
> 2.1  RADIUS Client Behavior
>
> [..]
>    To do the latter, it sends an Access-Request containing a Digest-Method
>    and a Digest-URI attribute but without a Digest-Nonce attribute.
>    It adds a Message-Authenticator (see [RFC3579]) attribute to the
>    Access-Request message.  The RADIUS server chooses a nonce and responds
>    with an Access-Challenge containing a Digest-Nonce attribute.
> [..]
>
> 2.2  RADIUS Server Behavior
>
>    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.  It puts the nonce into a Digest-Nonce
>    attribute and sends it in an Access-Challenge message to the RADIUS
>    client.  The RADIUS server MUST add Digest-Realm, Message-Authenticator
>    (see [RFC3579]), SHOULD add Digest-Algorithm, one or more Digest-Qop and
>    MAY add Digest-Domain, Digest-Opaque attributes to the Access-
>    Challenge message.
> [..]
>    RADIUS servers issuing nonces MAY construct a Digest-Nextnonce
>    attribute and add it to the Access-Accept message.  This is useful to
>    limit the lifetime of a nonce and to save a round-trip in future
>    requests (see nextnonce discussion in [RFC2617], section 3.2.3).  The
>    RADIUS server adds a Message-Authenticator attribute (see [RFC3579])
>    and sends the Access-Accept message to the RADIUS client.
>
>
> 4.  Table of Attributes
>
>    The following table provides a guide to which attributes may be found
>    in which kinds of packets, and in what quantity.
>
>    +-------------------------+-----+-----+--------+--------+-----------+
>    | Attribute               | #   | Req | Accept | Reject | Challenge |
>    +-------------------------+-----+-----+--------+--------+-----------+
>    | User-Name               | TBD | 1   | 0      | 0      | 0         |
>    | Message-Authenticator   | TBD | 1   | 1      | 1      | 1         |
>
> [..]
>
> Wolfgang
>
> --
> T-Systems
> Next Generation IP Services and Systems
> +49 6151 937 2863
> Am Kavalleriesand 3
> 64295 Darmstadt
> Germany
>
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>

--
to unsubscribe send a message 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, 11 May 2005 18:04:45 +0000
Date: Wed, 11 May 2005 11:04:32 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: "Beck01, Wolfgang" <[email-masked]>
cc: [email-masked]
Subject: Re: Proposed Resolution to Issue 77:

This looks ok to me.

On Wed, 11 May 2005, Beck01, Wolfgang wrote:

> 3.14  Digest-Opaque attribute
>
>    Description
>          This attribute holds the opaque parameter that is passed to the
>          HTTP-style client.  The HTTP-style client will pass this value
>          back to the server (ie the RADIUS client) without modification.
>          This attribute is only used when the RADIUS server chooses
>          nonces and MUST only be used in Access-Request and Access-
>          Challenge messages.
>
> [..]
>    +-------------------------+-----+-----+--------+--------+-----------+
>    | Attribute               | #   | Req | Accept | Reject | Challenge |
>    +-------------------------+-----+-----+--------+--------+-----------+
> [..]
>    | Digest-Auth-Param       | TBD | 0+  | 0+     | 0      | 0+        |
> [..]
>
>
>
> Wolfgang Beck
>
> --
> T-Systems
> Next Generation IP Services and Systems
> +49 6151 937 2863
> Am Kavalleriesand 3
> 64295 Darmstadt
> Germany
>
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>

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

Envelope-to: [email-masked]
Delivery-date: Wed, 11 May 2005 17:53:11 +0000
From: "Alan DeKok" <[email-masked]>
To: Bernard Aboba <[email-masked]>
Subject: Re: Implementation Survey: How does your EAP peer/RADIUS proxy handle internationalization? 
Cc: [email-masked]
Date: Wed, 11 May 2005 13:50:55 -0400
Message-Id: <[email-masked]>

Bernard Aboba <[email-masked]> wrote:
> Right.  Is this something we should try to fix, or just leave alone?

  My opinion would be to leave it alone.

> I don't recall hearing complaints about Microsoft IAS either.

  Years of deployment without complaints is a strong indicator that a
problem doesn't exist.  Let's let sleeping dogs lie.

  Alan DeKok.

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

Delivery-date: Wed, 11 May 2005 17:31:46 +0000
Date: Wed, 11 May 2005 10:31:39 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Alan DeKok <[email-masked]>
cc: [email-masked]
Subject: Re: Implementation Survey: How does your EAP peer/RADIUS proxy handle internationalization? 

> Which is difficult, especially since the locale information isn't
> sent in the RADIUS packet.  Without that, I'm not sure how to use
> stringprep properly to get better string comparisons.

Right.  Is this something we should try to fix, or just leave alone?

>   As an implementor, my inclination is to avoid the whole issue as it
> relates to software, and push it back to the users and administrators.
>
>   That is, get them to type in the strings (names, realms, etc.) as
> opaque tokens which have to be entered in one "normal" form.

I guess this makes sense.  The user has to know how the administrator set
up their account if they hope to be able to authenticate successfully.
This includes understanding exactly how the NAI was internationalized.

> Precedent exists for this request, in the Windows warning messages
> about "you must have capslock off...", which tells the user that what
> *they* think of as equivalent strings are not, and the strings must
> always be entered as exactly the same set of characters.
>
>   I don't recall hearing that this was an issue for FreeRADIUS, and
> it's used in many, many internationalized configurations.

I don't recall hearing complaints about Microsoft IAS either.

--
to unsubscribe send a message 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, 11 May 2005 17:30:07 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposed Resolution to Issue 87 (RADIUS MIB Updates)
Date: Wed, 11 May 2005 13:29:19 -0400
From: "Nelson, David" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>

> Sounds like yet another problem for "Issues and Fixes".

And perhaps an update to RFC 3162, "RADIUS and IPv6"?

--
to unsubscribe send a message 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, 11 May 2005 17:26:21 +0000
Date: Wed, 11 May 2005 10:26:07 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: "Nelson, David" <[email-masked]>
cc: [email-masked]
Subject: RE: Proposed Resolution to Issue 87 (RADIUS MIB Updates)

> A potential conflict would appear to exist if RADIUS servers are
> configured on a NAS with a mixture of IPv4 and IPv6 addresses.  Do we
> have a notion of a single RADIUS server that could be addressed by
> either IPv4 or IPv6?  If the NAS has a dual-mode stack, with both IPv4
> and IPv6 addresses, RADIUS servers would see these as separate NASes,
> based on the shared secret lookup.  Is that right?

Certainly there will be two different shared secret entries, one with the
IPv6 address/shared secret and another with the IPv4 address/shared
secret.  Hopefully the RADIUS client will be a bit more intelligent in not
doing things like failing over from the IPv4 address to the IPv6 address
when the RADIUS server doesn't answer.

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

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

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

> I agree that the WG needs to consider all the semantics and operational
> issues of IPv6 support, and document that somewhere, even if the MIB
> isn't the best place.

Sounds like yet another problem for "Issues and Fixes".

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

Envelope-to: [email-masked]
Delivery-date: Wed, 11 May 2005 17:22:49 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Subject: Re: Implementation Survey: How does your EAP peer/RADIUS proxy handle internationalization? 
Date: Wed, 11 May 2005 13:20:27 -0400
Message-Id: <[email-masked]>

Jari Arkko <[email-masked]> wrote:
> It looks like implementations may actually be capable of
> accepting non-ASCII input. However, there does not appear
> to be any specific support for character set aware comparisons,
> normalization, etc.

  Which is difficult, especially since the locale information isn't
sent in the RADIUS packet.  Without that, I'm not sure how to use
stringprep properly to get better string comparisons.

> What does this imply? I'm not quite sure... and the input
> is too small to make any definite conclusions. But it could
> be that alternative #1 for NAIbis issue resolution is preferrable,
> given that it better ensures correctness of lookups and
> comparisons. Comments?

  As an implementor, my inclination is to avoid the whole issue as it
relates to software, and push it back to the users and administrators.

  That is, get them to type in the strings (names, realms, etc.) as
opaque tokens which have to be entered in one "normal" form.
Precedent exists for this request, in the Windows warning messages
about "you must have capslock off...", which tells the user that what
*they* think of as equivalent strings are not, and the strings must
always be entered as exactly the same set of characters.

  I don't recall hearing that this was an issue for FreeRADIUS, and
it's used in many, many internationalized configurations.

  Alan DeKok.

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

Delivery-date: Wed, 11 May 2005 17:19:27 +0000
Date: Wed, 11 May 2005 10:19:20 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Jari Arkko <[email-masked]>
cc: [email-masked]
Subject: Re: Implementation Survey:  How does your EAP peer/RADIUS proxy handle internationalization?

> Attempting to summarize: (I hope you Bernard posted all the
> responses you got privately, I've only seen two.)

I will look through my email but I don't think I got any private
responses.  I think we have three responses.

> It looks like implementations may actually be capable of
> accepting non-ASCII input. However, there does not appear
> to be any specific support for character set aware comparisons,
> normalization, etc.

Yes.  UTF-8 can be sent in the NAI, but the RADIUS proxies are doing
exact string matches against the realm table.  This makes me
wonder if we don't need to provide guidance on what the proxies *should*
do.

> What does this imply? I'm not quite sure...

I think it implies that proxy implementations may have problems with
internationalization.

> and the input
> is too small to make any definite conclusions. But it could
> be that alternative #1 for NAIbis issue resolution is preferrable,
> given that it better ensures correctness of lookups and
> comparisons. Comments?

Given the feedback we have received, it would appear to me that
implementations are doing good to be correctly processing UTF-8, let alone
IDNA.

--
to unsubscribe send a message 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, 11 May 2005 17:15:05 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposed Resolution to Issue 87 (RADIUS MIB Updates)
Date: Wed, 11 May 2005 13:14:54 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Bernard Aboba writes...

> Question:  How does this work for NASes that support both IPv4 and
IPv6?
> Which objects would such devices use?

This begs the operational question of how RADIUS clients might support
IPv4/IPv6 co-existence.  I suppose that this issue might extend beyond
the scope of the MIB itself.

A potential conflict would appear to exist if RADIUS servers are
configured on a NAS with a mixture of IPv4 and IPv6 addresses.  Do we
have a notion of a single RADIUS server that could be addressed by
either IPv4 or IPv6?  If the NAS has a dual-mode stack, with both IPv4
and IPv6 addresses, RADIUS servers would see these as separate NASES,
based on the shared secret lookup.  Is that right?

I agree that the WG needs to consider all the semantics and operational
issues of IPv6 support, and document that somewhere, even if the MIB
isn't the best place.

--
to unsubscribe send a message 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, 11 May 2005 17:07:16 +0000
Date: Wed, 11 May 2005 10:06:59 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Re: Implementation Survey:  How does your EAP peer/RADIUS proxy handle internationalization?

On Mon, 25 Apr 2005, Bernard Aboba wrote:

> RFC 2486bis specifies how the NAI is internationalized.  In the
> development of this document, some questions have arisen about the
> behavior of existing EAP peers and RADIUS proxies.  In order to understand
> how existing implementations function, we need implementers to volunteer
> the answer to several questions:
>
> 1. How is internationalization supported on your EAP peer implementation?
> Does your EAP peer implementation support formating of the realm
> portion in IDN, or does it enable entering of UTF-8, or perhaps just plain
> ASCII?

For use with PPP, only ASCII is supported.  In EAP over IEEE 802, UTF-8 is
supported.  IDN is not supported (e.g. the realm part is not translated to
IDN or checked for compatibility with it).

> 2. How is internationalization supported on your RADIUS proxy
> implementation?.
>
> How does your implementation support internationalization within the realm
> table?  Are realm table entries stored in IDN, UTF-8, or something else?

They are stored in UTF-8.

> How are comparisons done between the realm in the NAI and the realm stored
> in the realm table?

Stringprep is not used in comparing the NAI realm to the realm in the realm table,
just an ordinary match.

--
to unsubscribe send a message 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, 11 May 2005 16:24:32 +0000
Date: Wed, 11 May 2005 09:23:53 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: "Nelson, David" <[email-masked]>
cc: [email-masked]
Subject: Re: Proposed Resolution to Issue 87 (RADIUS MIB Updates)

Question:  How does this work for NASes that support both IPv4 and IPv6?
Which objects would such devices use?

On Wed, 11 May 2005, Nelson, David wrote:

> Since the discussion of this issue has subsided, with no WG members
> dissenting from the MIB Doctor's recommendations, I propose to
> incorporate those recommendations into the next revision of the drafts.
>
> In summary, the drafts will contain the tables from RFCs 2618-2621 with
> the IPv4-only format address objects changed from "current" to
> "deprecated".  New tables will be added (in parallel) with IPv4/IPv6
> format address objects.  To promote backwards compatibility, the
> compliance statements will require both old and new tables to be
> instantiated when IPv4 addresses are in use, and only the new tables
> when IPv4 addresses are not in use (i.e. IPv6 only).
>
> The new RFCs, when issued, will either Update or Obsolete RFCs
> 2618-2621, as appropriate.
>
>
>
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>

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

Delivery-date: Wed, 11 May 2005 15:07:42 +0000
Content-class: urn:content-classes:message
Subject: Proposed Resolution to Issue 87 (RADIUS MIB Updates)
Date: Wed, 11 May 2005 11:07:05 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Since the discussion of this issue has subsided, with no WG members
dissenting from the MIB Doctor's recommendations, I propose to
incorporate those recommendations into the next revision of the drafts.

In summary, the drafts will contain the tables from RFCs 2618-2621 with
the IPv4-only format address objects changed from "current" to
"deprecated".  New tables will be added (in parallel) with IPv4/IPv6
format address objects.  To promote backwards compatibility, the
compliance statements will require both old and new tables to be
instantiated when IPv4 addresses are in use, and only the new tables
when IPv4 addresses are not in use (i.e. IPv6 only).

The new RFCs, when issued, will either Update or Obsolete RFCs
2618-2621, as appropriate.

--
to unsubscribe send a message 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, 11 May 2005 13:36:43 +0000
From: "Beck01, Wolfgang" <[email-masked]>
To: [email-masked]
Subject: Proposed Resolution to Issue 79:
Date: Wed, 11 May 2005 15:14:40 +0200

2.2  RADIUS Server Behavior
[..]
   A RADIUS MUST check if the RADIUS client is authorized to serve users
   of the realm mentioned in the Digest-Realm attribute.  If the RADIUS
   client is not authorized, the RADIUS server silently discards the
   Access-Request message.  Other actions taken by the RADIUS server are
   out of scope of this document.  However, the RADIUS server should
   notify the operator and may take additional action such as discarding
   all future requests from this client, until some management action
   tells it to do so again.

7.  Security Considerations
[..]
   The RADIUS server MUST check the Digest-Realm attribute it has
   received from a client.  If the RADIUS client is not authorized to
   serve HTTP-style clients of that realm, it might be compromised.

Wolfgang Beck

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

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

Delivery-date: Wed, 11 May 2005 13:36:12 +0000
From: "Beck01, Wolfgang" <[email-masked]>
To: [email-masked]
Subject: Proposed Resolution to Issue 78:
Date: Wed, 11 May 2005 15:13:49 +0200

1.3 Overview
[..]
   RADIUS clients and servers can support one, or both nonce generation
   modes.

   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.  The nonce generation mode is a configurable
   parameter

   The operator MUST make sure that the RADIUS client software uses the
   correct nonce generation mode when accessing a specific RADIUS
   server.  RADIUS clients implementing both modes MUST offer respective
   configuration options.

[For new formatting, see to draft-ietf-radext-digest-auth-02.txt]

3.1  Digest-Response attribute

   Description
         If this attribute is present in an Access-Request message, the
         RADIUS server MUST view the Access-Request as a Digest one.
[..]

   Length
         >= 3
   Text
         When using HTTP digest, the text field is 32 octets long and
         contains hexadecimal representation of 16 octet digest value as
         it was calculated by the authenticated client.  Other digest
         algorithms MAY define different digest lengths.  The text field
         MUST be copied from request-digest of digest-response
         ([RFC2617]) without quotes.

[..]
3.10  Digest-Entity-Body-Hash attribute

   Description
         When using the qop level 'auth-int', a hash of the HTTP-style
         message body's contents is required for digest calculation.
         Instead of sending the complete body of the message, only its
         hash value is sent.  This hash value can be used directly in
         the digest calculation.

         The clarifications described in section 22.4 of [RFC2617] about
         the hash of empty entity bodies apply to the Digest-Entity-
         Body-Hash attribute.  This attribute MUST only be sent in
         Access-Request packets.
   Type
         [IANA: use 111 if possible] for Digest-Entity-Body-Hash
   Length
         >=3
   Text
         The attribute holds the hexadecimal representation of H(entity-
         body).  This hash is required by certain authentication
         mechanisms, such as HTTP Digest with quality of protection set
         to "auth-int".  RADIUS clients MUST use this attribute to
         transport the hash of the entity body when HTTP Digest is the
         authentication mechanism and the RADIUS server requires to
         verify the integrity of the entity body (e.g., qop parameter
         set to "auth-int").  Extensions to this document may define
         support for authentication mechanisms other than HTTP Digest.

wb: extension would be indicated by Digest-Algorithm or Digest-Qop, of
course.

Migration Path to Diameter:

still left in -02, as there is no diameter-sip-app draft describing the
functionality yet.

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

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

Delivery-date: Wed, 11 May 2005 13:32:56 +0000
From: "Beck01, Wolfgang" <[email-masked]>
To: [email-masked]
Subject: Issue:
Date: Wed, 11 May 2005 15:10:49 +0200

typos in section 'RADIUS server behaviour'

Submitter name: Wolfgang Beck
Submitter email address: [email-masked]
Date first submitted: 11 May 2005
Document: draft-ietf-radext-digest-auth-02.txt
Comment type: E
Priority: S
Section: 2.2
Rationale/Explanation of issue:
missing verb in
  'The RADIUS server Digest-Realm, Message-Authenticator (see
   [RFC3579]), SHOULD add Digest-Algorithm, one or more Digest-Qop and
   MAY add Digest-Domain, Digest-Opaque attributes to the Access-
   Challenge message.'

and

   'A RADIUS MUST check if the RADIUS client is authorized to serve users
   of the realm mentioned in the Digest-Realm attribute.'

Requested change:
  'The RADIUS server MUST add Digest-Realm, Message-Authenticator (see
   [RFC3579]), SHOULD add Digest-Algorithm, one or more Digest-Qop and
   MAY add Digest-Domain, Digest-Opaque attributes to the Access-
   Challenge message.'

   'A RADIUS server MUST check if the RADIUS client is authorized to
   serve users of the realm mentioned in the Digest-Realm 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: Wed, 11 May 2005 13:32:45 +0000
From: "Beck01, Wolfgang" <[email-masked]>
To: [email-masked]
Subject: Proposed Resolution to Issue 7:
Date: Wed, 11 May 2005 15:09:54 +0200

2.  Detailed Description

2.1  RADIUS Client Behavior

[..]
   To do the latter, it sends an Access-Request containing a Digest-Method
   and a Digest-URI attribute but without a Digest-Nonce attribute.
   It adds a Message-Authenticator (see [RFC3579]) attribute to the
   Access-Request message.  The RADIUS server chooses a nonce and responds
   with an Access-Challenge containing a Digest-Nonce attribute.
[..]

2.2  RADIUS Server Behavior

   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.  It puts the nonce into a Digest-Nonce
   attribute and sends it in an Access-Challenge message to the RADIUS
   client.  The RADIUS server MUST add Digest-Realm, Message-Authenticator
   (see [RFC3579]), SHOULD add Digest-Algorithm, one or more Digest-Qop and
   MAY add Digest-Domain, Digest-Opaque attributes to the Access-
   Challenge message.
[..]
   RADIUS servers issuing nonces MAY construct a Digest-Nextnonce
   attribute and add it to the Access-Accept message.  This is useful to
   limit the lifetime of a nonce and to save a round-trip in future
   requests (see nextnonce discussion in [RFC2617], section 3.2.3).  The
   RADIUS server adds a Message-Authenticator attribute (see [RFC3579])
   and sends the Access-Accept message to the RADIUS client.

4.  Table of Attributes

   The following table provides a guide to which attributes may be found
   in which kinds of packets, and in what quantity.

   +-------------------------+-----+-----+--------+--------+-----------+
   | Attribute               | #   | Req | Accept | Reject | Challenge |
   +-------------------------+-----+-----+--------+--------+-----------+
   | User-Name               | TBD | 1   | 0      | 0      | 0         |
   | Message-Authenticator   | TBD | 1   | 1      | 1      | 1         |

[..]

Wolfgang

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

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

Delivery-date: Wed, 11 May 2005 13:30:26 +0000
Date: Wed, 11 May 2005 16:30:27 +0300
From: Jari Arkko <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC:  [email-masked]
Subject: Re: Implementation Survey:  How does your EAP peer/RADIUS proxy handle internationalization?

Attempting to summarize: (I hope you Bernard posted all the
responses you got privately, I've only seen two.)

It looks like implementations may actually be capable of
accepting non-ASCII input. However, there does not appear
to be any specific support for character set aware comparisons,
normalization, etc.

What does this imply? I'm not quite sure... and the input
is too small to make any definite conclusions. But it could
be that alternative #1 for NAIbis issue resolution is preferrable,
given that it better ensures correctness of lookups and
comparisons. Comments?

--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: Wed, 11 May 2005 13:23:16 +0000
Date: Wed, 11 May 2005 16:23:14 +0300
From: Jari Arkko <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC:  [email-masked]
Subject: Re: Implementation Survey:  How does your EAP peer/RADIUS proxy handle internationalization?

Bernard Aboba wrote:

>RFC 2486bis specifies how the NAI is internationalized.  In the
>development of this document, some questions have arisen about the
>behavior of existing EAP peers and RADIUS proxies.  In order to understand
>how existing implementations function, we need implementers to volunteer
>the answer to several questions:
>
>1. How is internationalization supported on your EAP peer implementation?
>
>Does your EAP peer implementation support formating of the realm
>portion in IDN, or does it enable entering of UTF-8, or perhaps just plain
>ASCII?
>
Note that many protocols work with IDNs as "IDN unaware domain
name slots". That is, an IDN may look like a regular ASCII DNS name.
The only question is if an implementation actually can take a
UTF-8 string also, directly.

--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: Wed, 11 May 2005 13:13:21 +0000
From: "Beck01, Wolfgang" <[email-masked]>
To: [email-masked]
Subject: Proposed Resolution to Issue 77:
Date: Wed, 11 May 2005 15:12:39 +0200

3.14  Digest-Opaque attribute

   Description
         This attribute holds the opaque parameter that is passed to the
         HTTP-style client.  The HTTP-style client will pass this value
         back to the server (ie the RADIUS client) without modification.
         This attribute is only used when the RADIUS server chooses
         nonces and MUST only be used in Access-Request and Access-
         Challenge messages.

[..]
   +-------------------------+-----+-----+--------+--------+-----------+
   | Attribute               | #   | Req | Accept | Reject | Challenge |
   +-------------------------+-----+-----+--------+--------+-----------+
[..]
   | Digest-Auth-Param       | TBD | 0+  | 0+     | 0      | 0+        |
[..]

Wolfgang Beck

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

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

Delivery-date: Wed, 11 May 2005 05:20:48 +0000
Date: Tue, 10 May 2005 22:20:12 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Issue tracking

The RADIUS Issues web page is located here:
http://www.drizzle.com/~aboba/RADEXT/

The Issues list describes the process by which Issues are submitted and
tracked in the RADEXT WG.  I've been working on updating the Issues list
and have run into a number of problems with the way people are posting to
the list, which has made it difficult to figure out the status of issues
on current documents.  To get this figured out, I'd like to request help
from WG participants so that the process can work more smoothly.

Here is a summary of the process:

Issue Submission

Any Working Group (WG) participant can at any time submit an Issue
relating to any draft  that is a WG work item, or in pre-work item review.
All Issues should be posted to the WG mailing list
([email-masked]) in the format described on the Issues list,  with
Issue: in the subject line.  In trying to update the Issues list, it
appears that Issues were submitted without an Issue: in the subject line,
and as a result, these Issues are not being tracked.  Also, it is not
clear to me that all postings with Issue: in the subject line correspond
to new issues, rather than proposed resolutions of old issues.

Please use the Issue: subject line without an Issue number *only* when
submitting a new issue.  If the posting is a proposed resolution to an
existing issue, please refer to the issue by the Issue #.

If you have submitted an Issue that hasn't ended up on the Issue list or
if you have found a new Issue being incorrectly created, please contact me
so that I can get it fixed.

Issue Resolution

In order to resolve an Issue, the editor needs to post a resolution to the
Issue to the mailing list.  The resolution posting should include the
following Subject line:  "Proposed Resolution to Issue X:" in the subject
line, where X is the Issue #.  The resolution posting should include the
text of the proposed resolution in its entirety, not just a summary.

Note that editors can proposed a resolution to an Issue, but resolution
requires a response from the original poster of the Issue, to confirm that
the resolution is ok with them.  If you have posted an Issue for which the
editor has proposed a resolution, please respond to that posting with your
opinion on whether the proposed resolution is satisfactory or not.  If
not, please proposed alternative text so as to move the discussion along.

Documents in WG Last Call

The above process is particularly important for documents in WG last call.
Before a document can be sent to the IESG for consideration, we need to
confirm that all open issues are closed, but unless the above process is
followed, we will be unable to do that.  So as to avoid unnecessary
delays, please help us in accurately tracking Issue status so that we can
complete documents in a timely way.

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

Delivery-date: Wed, 11 May 2005 03:05:22 +0000
Date: Tue, 10 May 2005 20:05:08 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Final Review of CUI-05

WG Last Call has completed on the Chargeable User Identity document, and a
new version (CUI-05) has been submitted that the author has indicated
closes all the open issues (82 & 83).

The revised document is available for inspection here:
http://www.ietf.org/internet-drafts/draft-ietf-radext-chargeable-user-id-05.txt

The RADEXT Issues list is available here:
http://www.drizzle.com/~aboba/RADEXT/

If you have filed an open issue against the document, or if you have an
opinion about the resolution of Issues 82 or 83, or if you have any other
last minute comments about this document, please post your Issue to the
RADEXT WG mailing list ASAP.

Assuming we do not hear anything by May 20, 2005 we will forward the
document on to the IESG for consideration as a proposed standard.

--
to unsubscribe send a message 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, 11 May 2005 02:36:34 +0000
Date: Tue, 10 May 2005 19:35:39 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Acceptance as WG work items

A clarification on the status of several documents.

Based on the response to the following posting:
http://ops.ietf.org/lists/radiusext/2005/msg00270.html

there appears to be sufficient interest to adopt the RADIUS MIB revisions,
RFC 3576 MNIBs and RADIUS Extensions for IEEE 802 as RADEXT WG work items.

These documents can now be submitted with draft-ietf-radext-* titles (with
the new boilerplate, please) once the pre-work item review issues have
been addressed.

-----------------------------------------------------------------------
As discussed at today's meeting, we are looking to gauge WG interest in
making the following documents WG work items:

RADIUS MIB Revision
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
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

RADIUS Extensions for IEEE 802
http://www.ietf.org/internet-drafts/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/>

Envelope-to: [email-masked]
Delivery-date: Thu, 05 May 2005 17:18:58 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Subject: Re: Comments on RADIUS MIB documents - MIB Doctor Review 
Date: Thu, 05 May 2005 13:16:19 -0400
Message-Id: <[email-masked]>

"Nelson, David" <[email-masked]> wrote:
> My personal assumption was that implementers of IPv4-only products
> didn't want to see the existing MIBs obsoleted or deprecated,
> because someone (a customer or a marketing manager) might request
> the successor MIBs to be implemented in the next release.  The real
> reason might be something altogether different, of course.

  Laziness?  Open source products are notorious for ignoring customer
requests, and implementing only the "fun" things. :)

> In any event, we have expert review comments on the proposed MIBs that
> indicate that this novel augmentation approach is undesirable.  The
> suggestion is to update all of the MIBs, deprecating the tables in RFC
> 2618-2621.

  Products will still have to implement them, though, in order to be
backwards compatible with the people who haven't updated.

> I'm asking that the WG members proactively respond, indicating
> acceptance of the MIB Doctors recommendations, or rejection of the
> recommendations together with a rationale for doing so.  Once we have
> determined consensus on this, then I will be able to issue the next
> draft version. I'd like to keep this task on schedule.

  I accept the MIB Doctors recommendations.  Having new MIBs is better
than trying to augment the old ones.

  Alan DeKok.

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

Delivery-date: Thu, 05 May 2005 17:07:09 +0000
Content-class: urn:content-classes:message
Subject: RE: Comments on RADIUS MIB documents -  MIB Doctor Review
Date: Thu, 5 May 2005 13:06:43 -0400
From: "Nelson, David" <[email-masked]>
To: "Romascanu, Dan \(Dan\)" <[email-masked]>, <[email-masked]>

> > OK, so no one's interested in discussing this.  :-(
>=20
> taking offense - I did comment on this actually :-)

Yes, I know.  I'd had considered your response as "unofficial" MIB
Doctor commentary (note that I wrote MIB Doctors [plural]).  Sorry to be
unclear or to cause offense.

I was seeking response from our "silent majority".

--
to unsubscribe send a message 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, 05 May 2005 17:01:47 +0000
content-class: urn:content-classes:message
Subject: RE: Comments on RADIUS MIB documents -  MIB Doctor Review
Date: Thu, 5 May 2005 19:59:14 +0300
From: "Romascanu, Dan \(Dan\)" <[email-masked]>
To: "Nelson, David" <[email-masked]>, <[email-masked]>

> OK, so no one's interested in discussing this.  :-(

taking offense - I did comment on this actually :-)

> I'm asking that the WG members proactively respond, indicating
> acceptance of the MIB Doctors recommendations, or rejection of the
> recommendations together with a rationale for doing so.  Once we have
> determined consensus on this, then I will be able to issue the next
> draft version. I'd like to keep this task on schedule.

Better prepare a strong argument to reject the MIB Doctor =
recommendations. It's not that the WG does not have this option, but =
both the MIB Doctor reviewer and the Area Director came with clear =
arguments IMO that demonstrated that the path that was taken by the WG =
creates an interoperability problem between existing implementations of =
the previous set of RFCs and 2618-2621.=20

I am in favor of following the recommendations.=20

Regards,

Dan

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]]On Behalf Of Nelson, David
> Sent: 05 May, 2005 6:52 PM
> To: [email-masked]
> Subject: RE: Comments on RADIUS MIB documents - MIB Doctor Review
>=20
>=20
> > I am forwarding some RADIUS MIB comments to the WG list, with the
> > author's permission.
> >=20
> > I'd like to solicit the WG's opinion on structuring of IPv6 address
> > support in the RADIUS MIBs, based on the attached comments.
>=20
> OK, so no one's interested in discussing this.  :-(
>=20
> The WG chose, during a couple of IETF meetings, to pursue the slightly
> novel approach of augmenting the existing MIB tables with a set of
> IPV4/IPv6 address types, and leaving RFC 2618-2621 untouched, and
> un-deprecated.  There was not much explicit discussion on=20
> *why* this was
> the WG's preference.  My personal assumption was that implementers of
> IPv4-only products didn't want to see the existing MIBs obsoleted or
> deprecated, because someone (a customer or a marketing manager) might
> request the successor MIBs to be implemented in the next release.  The
> real reason might be something altogether different, of course.
>=20
> In any event, we have expert review comments on the proposed MIBs that
> indicate that this novel augmentation approach is undesirable.  The
> suggestion is to update all of the MIBs, deprecating the tables in RFC
> 2618-2621.
>=20
> I'm asking that the WG members proactively respond, indicating
> acceptance of the MIB Doctors recommendations, or rejection of the
> recommendations together with a rationale for doing so.  Once we have
> determined consensus on this, then I will be able to issue the next
> draft version. I'd like to keep this task on schedule.
>=20
> Thanks!
>=20
>=20
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

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

Delivery-date: Thu, 05 May 2005 15:53:48 +0000
Content-class: urn:content-classes:message
Subject: RE: Comments on RADIUS MIB documents -  MIB Doctor Review
Date: Thu, 5 May 2005 11:52:26 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

> I am forwarding some RADIUS MIB comments to the WG list, with the
> author's permission.
>=20
> I'd like to solicit the WG's opinion on structuring of IPv6 address
> support in the RADIUS MIBs, based on the attached comments.

OK, so no one's interested in discussing this.  :-(

The WG chose, during a couple of IETF meetings, to pursue the slightly
novel approach of augmenting the existing MIB tables with a set of
IPV4/IPv6 address types, and leaving RFC 2618-2621 untouched, and
un-deprecated.  There was not much explicit discussion on *why* this was
the WG's preference.  My personal assumption was that implementers of
IPv4-only products didn't want to see the existing MIBs obsoleted or
deprecated, because someone (a customer or a marketing manager) might
request the successor MIBs to be implemented in the next release.  The
real reason might be something altogether different, of course.

In any event, we have expert review comments on the proposed MIBs that
indicate that this novel augmentation approach is undesirable.  The
suggestion is to update all of the MIBs, deprecating the tables in RFC
2618-2621.

I'm asking that the WG members proactively respond, indicating
acceptance of the MIB Doctors recommendations, or rejection of the
recommendations together with a rationale for doing so.  Once we have
determined consensus on this, then I will be able to issue the next
draft version. I'd like to keep this task on schedule.

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, 03 May 2005 14:45:17 +0000
content-class: urn:content-classes:message
Subject: RE: Comments on RADIUS MIB documents -  MIB Doctor Review
Date: Tue, 3 May 2005 17:42:47 +0300
From: "Romascanu, Dan \(Dan\)" <[email-masked]>
To: "Nelson, David" <[email-masked]>, <[email-masked]>

I believe that we need to redefine the tables in the new MIB modules in =
any case.

- if backwards compatibility with existing management applications is =
required this can be achieved only by defining new tables, as =
demonstrated by Bert
- if backwards compatibility is not required,  why bother AUGMENT-ing? =
The AUGMENTS would not work because there can be no one-to-one =
relationship with the rows pointing to ipv6 objects.=20

IMHO the 'clean way' is to deprecate 2618 to 2621, replace the address =
objects with the new TCs, and place all under new root OIDs.=20

Are there many IPv4 only implementations out there that would need to be =
replaced in deployment?

Regards,

Dan

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]]On Behalf Of Nelson, David
> Sent: 02 May, 2005 8:24 PM
> To: [email-masked]
> Subject: Comments on RADIUS MIB documents - MIB Doctor Review
>=20
>=20
> I am forwarding some RADIUS MIB comments to the WG list, with the
> author's permission.
>=20
> I'd like to solicit the WG's opinion on structuring of IPv6 address
> support in the RADIUS MIBs, based on the attached comments.
>=20
> ------------------------ Comment 1 -------------------------
>=20
> > 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
>=20
> Unfortunately, I do not have the time to be able to commit to doing
> a full MIB Doctor review.  However I did have a brief look at the
> documents and I have a serious concern about the approach.
>=20
> Specifically, each document contains a MIB module that AUGMENTS a
> conceptual row entry in an existing table.  The augmenting row
> contains IP-version-neutral columns that are intended to replace
> some IPv4-specific columns in the augmented row.  There is a
> statement in the narrative part of the documents that those
> IPv4-specific columns are deprecated -- see Sections 4, 5, and 6 of
> the drafts -- but documents do not contain a revised version of the
> original MIB module with the status value of the IPv4-specific
> objects changed from 'current' to 'deprecated'.
>=20
> There are two things that bother me about this approach.
>=20
> First, it is customary when the status of an object in an IETF MIB
> module is changed for that MIB module to be reissued with an updated
> definition of that object.  The above-mentioned drafts would leave
> it up to the user of the MIB module to perform that update.  I don't
> think that is wise.  Note that if new revisions of the existing MIB
> modules are published, there is little reason not to put the new
> objects into the existing tables, rather than making augmenting rows
> in new modules.
>=20
> Second, and more seriously, there is no discussion of what happens
> when an agent that implements the new/updated MIB module interacts
> with a management application that is built expect the old
> definitions.  It is not actually clear to me how to avoid breaking
> such applications except by definining an entirely new table (as was
> done in draft-ietf-ipv6-rfc2096-update-07.txt, to give one example),
> and stipulating in the compliance statements for the new/updated MIB
> module that the existing IPv4-specific tables are to be populated
> when the address type is IPv4.
>=20
> If it has already not done so, I would suggest that the RADEXT WG
> should explicitly discuss whether or not they want to preserve
> backard compatibility with management applications that implement
> RFCs 2618 through 2621, since that has a big impact on the design of
> the MIB module.
>=20
> Regards,
>=20
> Mike Heard
>=20
> ----------------------- Comment 2 ------------------------------
>=20
> > The specific approach was taken at the request of the WG members. =20
> > Folks wanted to specifically avoid obsoleting the existing=20
> RFCs.  I'd=20
> > like to get some WG comment on your concerns with that approach.
>=20
> That sounds fair.  One way to do that -- which I hinted at in=20
> my earlier
> e-mail -- would be to make new tables to parallel the old, but using
> InetAddressType/InetAddress pairs in place of IpAddress (as you did in
> the augmentation tables).  The compliance statements for the new MIB
> module could then require that both the old table and new table be
> instantiated when the address type is IPv4, but not otherwise.  The
> downside, obviously, is that there are a lot of extra objects; it is
> more efficient for the agent to implement only one set of tables.  The
> upside is that management apps that used to work before continue to
> work, although they are limited to just the IPv4-related entries, and
> the old specs don't have to be revised.
>=20
> //cmh
>=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, 02 May 2005 17:24:54 +0000
Content-class: urn:content-classes:message
Subject: Comments on RADIUS MIB documents -  MIB Doctor Review
Date: Mon, 2 May 2005 13:23:55 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

I am forwarding some RADIUS MIB comments to the WG list, with the
author's permission.

I'd like to solicit the WG's opinion on structuring of IPv6 address
support in the RADIUS MIBs, based on the attached comments.

------------------------ Comment 1 -------------------------

> 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

Unfortunately, I do not have the time to be able to commit to doing
a full MIB Doctor review.  However I did have a brief look at the
documents and I have a serious concern about the approach.

Specifically, each document contains a MIB module that AUGMENTS a
conceptual row entry in an existing table.  The augmenting row
contains IP-version-neutral columns that are intended to replace
some IPv4-specific columns in the augmented row.  There is a
statement in the narrative part of the documents that those
IPv4-specific columns are deprecated -- see Sections 4, 5, and 6 of
the drafts -- but documents do not contain a revised version of the
original MIB module with the status value of the IPv4-specific
objects changed from 'current' to 'deprecated'.

There are two things that bother me about this approach.

First, it is customary when the status of an object in an IETF MIB
module is changed for that MIB module to be reissued with an updated
definition of that object.  The above-mentioned drafts would leave
it up to the user of the MIB module to perform that update.  I don't
think that is wise.  Note that if new revisions of the existing MIB
modules are published, there is little reason not to put the new
objects into the existing tables, rather than making augmenting rows
in new modules.

Second, and more seriously, there is no discussion of what happens
when an agent that implements the new/updated MIB module interacts
with a management application that is built expect the old
definitions.  It is not actually clear to me how to avoid breaking
such applications except by definining an entirely new table (as was
done in draft-ietf-ipv6-rfc2096-update-07.txt, to give one example),
and stipulating in the compliance statements for the new/updated MIB
module that the existing IPv4-specific tables are to be populated
when the address type is IPv4.

If it has already not done so, I would suggest that the RADEXT WG
should explicitly discuss whether or not they want to preserve
backard compatibility with management applications that implement
RFCs 2618 through 2621, since that has a big impact on the design of
the MIB module.

Regards,

Mike Heard

----------------------- Comment 2 ------------------------------

> The specific approach was taken at the request of the WG members. =20
> Folks wanted to specifically avoid obsoleting the existing RFCs.  I'd=20
> like to get some WG comment on your concerns with that approach.

That sounds fair.  One way to do that -- which I hinted at in my earlier
e-mail -- would be to make new tables to parallel the old, but using
InetAddressType/InetAddress pairs in place of IpAddress (as you did in
the augmentation tables).  The compliance statements for the new MIB
module could then require that both the old table and new table be
instantiated when the address type is IPv4, but not otherwise.  The
downside, obviously, is that there are a lot of extra objects; it is
more efficient for the agent to implement only one set of tables.  The
upside is that management apps that used to work before continue to
work, although they are limited to just the IPv4-related entries, and
the old specs don't have to be revised.

//cmh

--
to unsubscribe send a message 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, 02 May 2005 06:27:33 +0000
Content-class: urn:content-classes:message
Subject: CUI version -05
Date: Sun, 1 May 2005 23:26:28 -0700
From: "Adrangi, Farid" <[email-masked]>
To: <[email-masked]>
Cc: "Bernard Aboba" <[email-masked]>, "Nelson, David" <[email-masked]>, "Greg Weber" <[email-masked]>

Hi all,
I have submitted version -05 of the CUI draft that addresses issues 82
and 83.  The draft does not yet appear in I-D, but you can view the
draft here:
http://mng.ctgisp.com/IETF/RADIUSEXT/draft-ietf-radext-chargeable-user-i
d-05.txt

The suggested editorial in issue 82 (submitted by Greg Weber) was done
in -05 draft.  And the issue 83 (submitted by Bernard) was addressed as
below:

Text in -04
"
If a home RADIUS server that supports the CUI attribute receives an
Access-Request packet containing a CUI (set to nul or otherwise), it
MUST include the CUI attribute in the Access-Accept packet.  Otherwise,
if the Access-Request packet does not contain a CUI, the home RADIUS
server MUST NOT include the CUI attribute in the
Access-Accept packet.
"
=20
Rewrite it to=20
=20
"
If a home RADIUS server that supports the CUI attribute receives an
Access-Request packet containing a CUI (set to nul or otherwise), it
MUST include the CUI attribute in the Access-Accept packet.  Otherwise,
if the Access-Request packet does not contain a CUI, the home RADIUS
server SHOULD NOT include the CUI attribute in the Access-Accept packet.
The Access-Request may be sent either in the initial authentication or
durig re-authentication.
"

Text in -04
"
A RADIUS client requesting the CUI attribute in an  Access-Accept packet
MUST include within the Access-Request=20
packet a CUI attribute with a single NUL character (referred  to as a
nul CUI). "
=20
Rewrite it to:
"
A RADIUS client requesting the CUI attribute in an Access-Accept packet
MUST include within the Access-Request packet a CUI attribute.  For the
initial authentication, the CUI attribute will include a single NUL
character (referred to as a nul CUI).  And, during re-authentication,
the CUI attribute will include a previously received=20
CUI value (referred to as a non-nul CUI value) in the Access-Accept.=20

Upon receiving a non-nul CUI value in an Access-Request the home RADIUS
server MAY verify that the value of CUI matches the CUI from the
previous Access-Accept. If the verification fails, then the RADIUS
server SHOULD respond with an Access-Reject message.=20
"

And finally, added the following text to the end of section 2.1:

"
A NAS that requested the CUI during reauthentication by including the
CUI in the Access-Request, will receive the CUI in the Access-Accept.
The NAS MUST include the value of that CUI in all Accounting Messages."
"

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