Subject: Request for NAS-Port-Type Allocation

From: Bernard Aboba <[email-masked]>
Date: Fri, 1 Aug 2008 01:14:29 -0700 (PDT)

The IANA has received a request for a new NAS-Port-Type allocation.  As 
stated in RFC 3575, Section 2.1:

   Certain attributes (for example, NAS-Port-Type) in RADIUS define a
   list of values to correspond with various meanings.  There can be 4
   billion (2^32) values for each attribute.  Additional values can be
   allocated by the Designated Expert.  The exception to this policy is
   the Service-Type attribute (6), whose values define new modes of
   operation for RADIUS.  Values 1-16 of the Service-Type attribute have
   been allocated.  Allocation of new Service-Type values are by IETF
   Consensus.  The intention is that any allocation will be accompanied
   by a published RFC.

Are there any objections to granting the allocation as requested below?

Contact Name :
Tomohiro Ichida

Contact Email :
[email-masked]

Type of Assignment :
I request the allocation of new NAS-Port-TYPE.

http://www.iana.org/assignments/radius-types
Values for RADIUS Attribute 61, NAS-Port-Type [RFC2865]:

Registry :
The value is "Wireless - XGP"

Description :
There is a standardization organization as PHS-MOU.
We'd like to prescribe the new number in NAS-PORT-TYPE.
And We'd like to use its number by the next generation PHS system.
it is same as "Wireless - CDMA2000","Wireless - IEEE 802.16"

PHS-MOU is explained as follows this URL
 http://www.phsmou.org/

Additional Info :
 The "Next Generation PHS" specification is is being made.
 A document is not open to the public,sorry.

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

---

From: Alan DeKok <[email-masked]>
Date: Fri, 01 Aug 2008 10:35:02 +0200

> Are there any objections to granting the allocation as requested below?

  It looks fine to me.

  Alan DeKok.

Delivery-date: Wed, 30 Jul 2008 13:19:03 +0000
Date: Wed, 30 Jul 2008 06:17:37 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Request for Minutes, Slides

If you took minutes at the RADEXT WG meeting at IETF 72, please send them 
to me ([email-masked]) and/or Dave Nelson. 

Also, if you presented and did not send slides, please do so. 

Delivery-date: Wed, 30 Jul 2008 11:32:23 +0000
Date: Wed, 30 Jul 2008 13:30:41 +0200
From: [email-masked]
To: [email-masked]
Subject: RadSec slides

This message is in MIME format.

--=_43n2rxr3njeo
Content-Type: text/plain;
	charset=ISO-8859-1;
	DelSp="Yes";
	format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

Hi,

we had some problems shipping the slides, so they are now attached to  
this mail.

Have fun,

Stefan

--=_43n2rxr3njeo
Content-Type: application/pdf;
	name="ietf-72-radext-radsec.pdf"
Content-Disposition: attachment;
	filename="ietf-72-radext-radsec.pdf"
Content-Transfer-Encoding: base64

--=_43n2rxr3njeo--

Delivery-date: Wed, 30 Jul 2008 11:32:16 +0000
Date: Wed, 30 Jul 2008 13:30:43 +0200
From: [email-masked]
To: [email-masked]
Subject: RadSec slides

This message is in MIME format.

--=_4ee9yxyk2800
Content-Type: text/plain;
	charset=ISO-8859-1;
	DelSp="Yes";
	format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

Hi,

we had some problems shipping the slides, so they are now attached to  
this mail.

Have fun,

Stefan

--=_4ee9yxyk2800
Content-Type: application/pdf;
	name="ietf-72-radext-radsec.pdf"
Content-Disposition: attachment;
	filename="ietf-72-radext-radsec.pdf"
Content-Transfer-Encoding: base64

--=_4ee9yxyk2800--

Delivery-date: Mon, 28 Jul 2008 15:47:37 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Cc: "'Bernard Aboba'" <[email-masked]>
Subject: RE: IETF 72: Request for Slides
Date: Mon, 28 Jul 2008 11:46:42 -0400
Organization: Elbrys Networks, Inc.

> If you have slides to present at IETF 72, please send them to me
> ([email-masked]> ASAP, so we can get them loaded on the 
> server.

Please copy the slides to Dave Nelson, ([email-masked]) as well.
Thanks!

Regards,

Dave

Delivery-date: Mon, 28 Jul 2008 15:40:56 +0000
Date: Mon, 28 Jul 2008 08:40:04 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: IETF 72: Request for Slides

If you have slides to present at IETF 72, please send them to me 
([email-masked]> ASAP, so we can get them loaded on the server. 

Delivery-date: Mon, 28 Jul 2008 15:37:15 +0000
Date: Mon, 28 Jul 2008 08:36:18 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: REMINDER: RADEXT WG Last call on "Extended RADIUS Attributes"

This is a reminder of the RADEXT WG Last Call on "Extended 
RADIUS Attributes", prior to requesting that the IESG publish it as a Proposed Standard. 
 
The document is available here:
http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-attributes-04.txt
 
WG Last Call was originally to have completed on July 24, 2008.   
However, due to lack of response to the RADEXT WG last call, 
we will be extending the WG last call to August 10, 2008.  Please 
review the document and post your comments to the RADEXT WG mailing list 
([email-masked]) in the format described on the RADEXT WG Issues 
list (http://www.drizzle.com/~aboba/RADEXT/).   
 
If you have read the document and approve of its publication, but have no
comments, please also post this to the list. 

Delivery-date: Mon, 28 Jul 2008 15:33:47 +0000
Date: Mon, 28 Jul 2008 08:32:49 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: REMINDER: RADEXT WG Last Call on "Crypto-Agility Requirements for RADIUS"

This is a reminder of the ongoing RADEXT WG Last Call on "Crypto-Agility 
Requirements for RADIUS" prior to requesting that the IESG publish it as 
an Informational RFC. 
 
The document is available here:
http://www.ietf.org/internet-drafts/draft-ietf-radext-crypto-agility-requirements-00.txt
 
WG Last Call will last until August 10, 2008.   Please review the document 
and post your comments to the RADEXT WG mailing list 
([email-masked]) in the format described on the RADEXT WG Issues 
list (http://www.drizzle.com/~aboba/RADEXT/).   
 
If you have read the document and approve of its publication, but have no
comments, please also post this to the list. 

Delivery-date: Mon, 28 Jul 2008 15:33:07 +0000
Date: Mon, 28 Jul 2008 08:31:35 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Take Three: RADEXT WG Agenda at IETF 72

9:00 - 9:10  Preliminaries
 Blue Sheets
 Note Takers
 Jabber Scribe
 Agenda bashing
 Document Status

Completed WG Last Call (20 minutes)

Extended RADIUS Attributes, Glen Zorn, 10 minutes
http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-attributes-04.txt

RADIUS Design Guidelines, Alan DeKok, 10 minutes
http://www.ietf.org/internet-drafts/draft-ietf-radext-design-04.txt

Transport Documents (40 minutes)

TCP Transport, Alan DeKok, 10 minutes
http://www.ietf.org/internet-drafts/draft-dekok-radext-tcp-transport-00.txt

Status Server, Alan DeKok, 10 minutes
http://www.ietf.org/internet-drafts/draft-ietf-radext-status-server-00.txt

RADIUS over DTLS, Alan DeKok, 10 minutes
http://www.ietf.org/internet-drafts/draft-dekok-radext-dtls-01.txt

RADSEC, Stefan Winter, 10 minutes
http://www.ietf.org/internet-drafts/draft-ietf-radext-radsec-00.txt

RADIUS Cryptoagility (20 minutes)

RADIUS Cryptoagility requirements, David Nelson, 10 minutes
http://www.ietf.org/internet-drafts/draft-ietf-radext-crypto-agility-requirements-00.txt

RADIUS Confidentiality, Glen Zorn, 10 minutes
http://www.ietf.org/internet-drafts/draft-zorn-radius-encattr-11.txt

Additional Documents (30 minutes)

RADIUS Attributes for IEEE 802 Networks, Bernard Aboba, 10 minutes
http://www.ietf.org/internet-drafts/draft-aboba-radext-wlan-08.txt

Problem Statement and Requirements for Diameter/Radius Prefix 
Authorization Application, B. Sarikaya, 10 minutes
http://www.ietf.org/internet-drafts/draft-sarikaya-dimeradext-prefix-auth-ps-00.txt

IPv6 Attributes for DHCP Networks, B. Lourdelet, 10 minutes
http://www.ietf.org/internet-drafts/draft-lourdelet-radext-ipv6-dhcp-00.txt

Delivery-date: Mon, 21 Jul 2008 02:49:55 +0000
Date: Sun, 20 Jul 2008 19:48:39 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Take Two: RADEXT WG Agenda at IETF 72

9:00 - 9:10  Preliminaries
 Blue Sheets
 Note Takers
 Jabber Scribe
 Agenda bashing
 Document Status

Completed WG Last Call (20 minutes)

Extended RADIUS Attributes, Glen Zorn, 10 minutes
http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-attributes-04.txt

RADIUS Design Guidelines, Alan DeKok, 10 minutes
http://www.ietf.org/internet-drafts/draft-ietf-radext-design-04.txt

Transport Documents (40 minutes)

TCP Transport, Alan DeKok, 10 minutes
http://www.ietf.org/internet-drafts/draft-dekok-radext-tcp-transport-00.txt

Status Server, Alan DeKok, 10 minutes
http://www.ietf.org/internet-drafts/draft-ietf-radext-status-server-00.txt

RADIUS over DTLS, Alan DeKok, 10 minutes
http://www.ietf.org/internet-drafts/draft-dekok-radext-dtls-01.txt

RADSEC, Stefan Winter, 10 minutes
http://www.ietf.org/internet-drafts/draft-ietf-radext-radsec-00.txt

RADIUS Cryptoagility (20 minutes)

RADIUS Cryptoagility requirements, David Nelson, 10 minutes
http://www.ietf.org/internet-drafts/draft-ietf-radext-crypto-agility-requirements-00.txt

RADIUS Confidentiality, Glen Zorn, 10 minutes
http://www.ietf.org/internet-drafts/draft-zorn-radius-encattr-11.txt

Additional Documents (20 minutes)

RADIUS Attributes for IEEE 802 Networks, Bernard Aboba, 10 minutes
http://www.ietf.org/internet-drafts/draft-aboba-radext-wlan-08.txt

IPv6 Attributes for DHCP Networks, B. Lourdelet, 10 minutes
http://www.ietf.org/internet-drafts/draft-lourdelet-radext-ipv6-dhcp-00.txt

Delivery-date: Sun, 20 Jul 2008 19:36:35 +0000
Date: Sun, 20 Jul 2008 12:35:44 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: REMINDER: RADEXT WG Last Call on "Crypto-Agility Requirements for RADIUS"

This is a reminder of the ongoing RADEXT WG Last Call on "Crypto-Agility 
Requirements for RADIUS" prior to requesting that the IESG publish it as 
an Informational RFC. 
 
The document is available here:
http://www.ietf.org/internet-drafts/draft-ietf-radext-crypto-agility-requirements-00.txt
 
WG Last Call will last until August 10, 2008.   Please review the document 
and post your comments to the RADEXT WG mailing list 
([email-masked]) in the format described on the RADEXT WG Issues 
list (http://www.drizzle.com/~aboba/RADEXT/).   
 
If you have read the document and approve of its publication, but have no
comments, please also post this to the list. 

Delivery-date: Sun, 20 Jul 2008 19:35:25 +0000
Date: Sun, 20 Jul 2008 12:34:28 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: REMINDER: RADEXT WG Last call on "Extended RADIUS Attributes" 

This is a reminder of the ongoing RADEXT WG Last Call on "Extended RADIUS 
Attributes" prior to requesting that the IESG publish it as a Proposed 
Standard. 
 
The document is available here:
http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-attributes-04.txt
 
WG Last Call will last until July 24, 2008.   Please review the document 
and post your comments to the RADEXT WG mailing list 
([email-masked]) in the format described on the RADEXT WG Issues 
list (http://www.drizzle.com/~aboba/RADEXT/).   
 
If you have read the document and approve of its publication, but have no
comments, please also post this to the list. 

Delivery-date: Sun, 20 Jul 2008 19:33:41 +0000
Date: Sun, 20 Jul 2008 12:32:11 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Issue 271:  IETF Last Call Comments on RADIUS GEOPRIV Document

In order to make forward progress on resolving the RADIUS GEOPRIV IETF 
Last Call comments, I am reposting Glen's original review to the RADEXT WG 
list. 

Suggested text changes to resolve these comments are welcome.  

=======================================================================
Issue 271: Review
Submitter name: Glen Zorn
Submitter email address: [email-masked]
Date first submitted: April 27, 2008
Reference: http://www.ietf.org/mail-archive/web/ietf/current/msg51649.html
Document: LOCATION-09
Comment type:  Technical
Priority: S
Section:  Various
Rationale/Explanation of issue:

In the description of the Operator-Name Attribute (section 3.1), the
discussion of the encoding of a name in the "REALM" namespace is
incomplete, at best. First, there is no discussion of the steps (if
any) to be taken if the toASCII conversion fails in the case of a realm
name containing non-ASCII characters. In any case, however, it is not
possible to encapsulate a maximum-length FQDN in a RADIUS attribute
because the maximum length of a RADIUS Attribute data payload is 253
octets, while the maximum length of an ASCII FQDN is 255 octets.
Furthermore, due to the addition of the ACE prefix(es) as a result of
the toASCII conversion process, the actual length of a converted realm
name may be considerably less than 253 octets. The conventional way to
deal with type of problem in RADIUS would be to split the offending
string up into multiple attributes; however, the formatting of the
Operator-Name attribute into distinct sub-fields would seem to preclude
the use of that technique. I suggest that (in order of preference)
a) the Operator-Name Attribute be split into separate
Operator-Namespace and Operator-Name Attributes with instructions
included on handling too-long FQDNs
b) the attribute be redefined in terms of the new Extended
RADIUS Attributes
(http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-attribut
es-03.txt)
or at the least
c) text be added noting the actual restrictions on realm name
length

Section 3.3, paragraph 2 doesn't make a lot of sense to me: suggest
rewriting it in less florid if more precise language. For example,
something like this: "In order to enable the on-demand mid-session
location delivery method, the RADIUS server MUST return an instance of
the Requested-Location-Info Attribute with the 'FUTURE_REQUESTS' flag
set and instances of the Basic-Location-Policy-Rules and
Extended-Location-Policy-Rules Attributes in the Access-Accept message
for the session. Upon receipt of a CoA-Request message containing a
Service-Type Attribute with value "Authorize Only" for the same session,
the NAS MUST include location information and echo the previously
received Basic-Location-Policy-Rules and Extended-Location-Policy-Rules
Attributes in the subsequent Access-Request message."

Section 4.2 says:

Length:

>= 21

String:

This field is at least two octets in length, and the format
is shown below. The data type of this field is string.

Suggestion: change "at least two" to "at least 19". Later in the same
section, it says:

Method (variable):

Describes the way that the location information was
determined. The values are registered with the 'method' Tokens
registry by RFC 4119. The data type of this
field is a string.

Does "registered with the 'method' tokens" mean "along with the token
values in the same registry" or something else? I _think_ that what the
authors are trying to say is "This field MUST contain the value of
exactly one IANA-registered 'method' token [RFC4119]." If so, maybe
they should.

Section 4.2.1 says "The location format is based on the encoding format
defined in Section 3.1 of [RFC4776] whereby the first 3 octets (i.e.,
the code for this DHCP option, the length of the DHCP option, and the
'what' element are not included) are not put into the Location field of
the above-described RADIUS Location-Data Attribute." I don't really
understand: does this mean that 'the location format is identical to
that defined in RFC 4776 with the exception that the first three octets
are omitted'? In any case, RFC 4776 say in the last paragraph of
section 1:

The DHCPv4 long-options mechanism described in RFC 3396 [8] MUST be
used if the civic address option exceeds the maximum DHCPv4 option
size of 255 octets.

My comments on are similar to those on the Operator-Name Attribute
above; this case is a little more complicated, due to the use of the
Index field to associate this attribute with the corresponding
Location-Information attribute (there seems to be an implicit assumption
that these always come in pairs).

Section 4.3 says: "Implementations SHOULD treat this attribute as
undistinguished octets." In context, this statement doesn't make sense
in at least two ways. First, I have no idea how any implementation can
treat an entire attribute as undistinguished octets, since at least the
Type and Length fields have to be distinguished. Maybe the authors mean
that the String field of the attribute should be treated in this way,
but that doesn't seem reasonable, either, because that field is itself
formatted into two distinct fields.

Section 4.4 says "The Basic-Location-Policy-Rules Attribute MAY be sent
in an Access-Request, Access-Accept, an Access-Challenge, an
Access-Reject, a Change-of-Authorization and in an Accounting-Request
message." but RFC 2865 says (section 2, paragraph 7) "If any condition
is not met, the RADIUS server sends an "Access-Reject" response
indicating that this user request is invalid. If desired, the server
MAY include a text message in the Access-Reject which MAY be displayed
by the client to the user. No other Attributes (except Proxy-State) are
permitted in an Access-Reject." This being the case, it seems like
there should be an "Updates: 2865" in the first page header of the
draft.

The Location-Capable (section 4.6) attribute can take only a "True"
value (presumably the lack of client ability would be signified by the
absence of the Location-Capable Attribute in the Access-Request). This
puzzles me a bit: isn't it possible that a NAS might be capable of
discovering (& therefore, communicating) one or a few type of location
data and not others? For example, it seems rather likely that a dial-up
NAS might be capable of conveying its own civic location but not the
geospatial location of the remote node. I guess what I'm asking is if
there isn't a need for a little greater granularity here.

The discussion of the Requested-Location-Info Attribute in section 4.7
is remarkably soft and fluffy, attributing such things as "wants" and
"desires" to servers and clients. To the best of my knowledge, software
does not (yet) display needs, let alone desires. This would just be a
little annoying except that the warm fuzziness spills over into the
actual specification of what are presumably requirements. For example:

If the RADIUS server wants to dynamically decide on a per-request
basis to ask for location information from the RADIUS client then the
following cases need to be differentiated. If the RADIUS client and
the RADIUS server have agreed out-of-band to mandate the transfer of
location information for every network access authentication request
then the processing listed below is not applicable.

o If the RADIUS server requires location information for computing
the authorization decision and the RADIUS client does not provide
it with the Access-Request message then the Requested-Location-
Info Attribute is attached to the Access-Challenge with a hint
about what is required. Two cases can be differentiated:

1. If the RADIUS client sends the requested information then the
RADIUS server can process the location-based attributes.

2. If the RADIUS server does not receive the requested
information in response to the Access-Challenge (including the
Requested-Location-Info Attribute) then the RADIUS server may
respond with an Access-Reject message with an Error-Cause
Attribute (including the "Location-Info-Required" value).

In the case of #1, "the RADIUS server can process the location-based
attributes". This seems fairly obvious, but just because it _can_
doesn't mean that it _will_; it might not (presumably based upon its
"desires" ;-). Must the server process the location information? If
so, the document should say so. Similarly in case #2, "the RADIUS
server may respond with an Access-Reject message with an Error-Cause
Attribute (including the "Location-Info-Required" value)." If it "may"
then it may also not; just guessing (since there are supposedly only two
cases and the information is stated to be required in order to process
the authorization request) it seems to me that the authors really mean
"MUST" in both cases but that is not clear at all.

o If the RADIUS server would like location information in the
Accounting-Request message but does not require it for computing
an authorization decision then the Access-Accept message MUST
include a Required-Info Attribute. This is typically the case
when location information is used only for billing. The RADIUS
client SHOULD attach location information, if available, to the
Accounting-Request (unless authorization policies dictate
something different).

Once again the server exhibits desire, but this paragraph begs another
question: if the data referred to by the Requested-Location-Info
Attribute is actually required and the Required-Info Attribute signifies
data that is optional, why are they named the way they are?

Change "8.3. New Registry: Location Capable Attribute" to "8.3. New
Registry: Location-Capable Attribute".

Many references are out of date or incorrect.
Given that Bernard is a co-author, it may be a bit excessive to mention
him (thrice!) in the Acknowledgements section _and_ in the Contributors
section as well ;-).

In section A.1, paragraph 1 change "This section discusses the privacy
implication for making location information available to other
entities." to "This section discusses the privacy implications of making
location information available to other entities."

Last but not least, this draft fairly universally violates several of
the guidelines given in
http://www.ietf.org/internet-drafts/draft-ietf-radext-design-02.txt, in
particular those regarding the use of tags to associate different
attributes (called "Index" in this document) and the creation of
"complex" attributes. I realize that the RADIUS design guidelines
document is just an Internet-Draft, but it is a radext WG document & has
been under construction for some period of time. More important than
the standardization status of the document is the question of whether
the guidelines make sense; if so, then it may not be such a good idea to
so completely ignore them; if not, then maybe radext should rethink this
work item (especially since a co-chair of that WG is also a co-author of
the document under review).

[BA] Can you provide specific instances in which this
document violates "Design Guidelines" (applying the tests in
Appendix A?.

OK. As you noted above, the Design Guidelines say

If the RADIUS Server simply passes the contents of an attribute to
some non-RADIUS portion of the network, then the data is opaque, and
SHOULD be defined to be of type String. A concrete way of judging
this requirement is whether or not the attribute definition in the
RADIUS document contains delineated fields for sub-parts of the data.
If those fields need to be delineated in RADIUS, then the data is not
opaque, and it SHOULD be separated into individual RADIUS attributes.

But section 4.7 of the draft under review says

o If the RADIUS server requires location information for computing
the authorization decision and the RADIUS client does not provide
it with the Access-Request message then the Requested-Location-
Info Attribute is attached to the Access-Challenge with a hint
about what is required. Two cases can be differentiated:

1. If the RADIUS client sends the requested information then the
RADIUS server can process the location-based attributes.

2. If the RADIUS server does not receive the requested
information in response to the Access-Challenge (including the
Requested-Location-Info Attribute) then the RADIUS server may
respond with an Access-Reject message with an Error-Cause
Attribute (including the "Location-Info-Required" value).

The RADIUS server "requires location information for computing the
authorization decision". How can it make a decision based upon data
that it cannot understand? It doesn't have to because "[i]f the RADIUS
client sends the requested information then the RADIUS server can
process the location-based attributes". Of course, "process" can mean
many things and if these attributes are opaque then "process" might mean
just writing the data to a file or forwarding it over some unspecified
interface to another entity. So maybe the RADIUS server is making the
decision based just upon the fact that it received a
Location-Information/Location-Data pair in the new Access-Request (along
with the echoed Attributes). The problem is that the RADIUS server
didn't request just any old location data; it requested a very specific
set of data (in the example later in section 4.7 it is the civic
location of the user). AFAICT, the only way that the RADIUS server can
tell if it has actually received the information it requested is to
examine the Code and Entity sub-fields of the returned
Location-Information Attribute and check that there is an associated
instance of the Location-Data Attribute by matching the Index fields of
the Attributes. Remember that this check for the requested information
takes place before the RADIUS server processes the data; this suggests
to me that these fields "need to be delineated in RADIUS" and therefore
"the data is not opaque, and it SHOULD be separated into individual
RADIUS attributes". Further, section A.2.2 of the Design Guidelines
asks the (how I wish it was a musical ;-) question:

Does the attribute define a complex data type for purposes other than
authentication or security? If so, this data type SHOULD be replaced
with simpler types, as discussed above in Section A.2.1.

Neither the Location-Information nor the Location-Data Attributes seem
to be used for authentication (authorization != authentication) or
security. Section A.1.3 of the same document says (WRT Attributes
encapsulating complex data types):

Does the attribute encapsulate an existing data structure defined
outside of the RADIUS specifications? Can the attribute be treated
as opaque data by RADIUS servers (including proxies?) If both
questions can be answered affirmatively, a complex structure MAY be
used in a RADIUS specification.

The specification of the attribute SHOULD define the encapsulating
attribute to be of type String. The specification SHOULD refer to an
external document defining the structure. The specification SHOULD
NOT define or describe the structure[...]

However, section 4.2 of draft-ietf-geopriv-radius-lo describes the
structure of the Location-Information Attribute in detail; the question
of opacity was dealt with above.

WRT the Index fields of the Location-Information and Location-Data
Attributes, the fact that they are both mandatory and large avoids many
of the drawbacks mentioned WRT tags in the Design Guidelines document,
nevertheless that document does state 'new attributes SHOULD use the
grouping method described in
http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-attributes-03.txt'.

Additional discussion is available here:
http://www.ietf.org/mail-archive/web/ietf/current/msg51657.html
http://www.ietf.org/mail-archive/web/ietf/current/msg51686.html
http://www.ietf.org/mail-archive/web/ietf/current/msg51691.html

Delivery-date: Mon, 14 Jul 2008 15:18:55 +0000
Date: Mon, 14 Jul 2008 08:17:54 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: PROTO WRITEUP: RADIUS Authorization for NAS Management

Title:  RADIUS Authorization for NAS Management
I-D:
http://www.ietf.org/internet-drafts/draft-ietf-radext-management-authorization-05.txt
 
Status: Proposed Standard
 
Response to template:
 
1) Have the chairs personally reviewed this version of the ID and do
   they believe this ID is sufficiently baked to forward to the IESG
   for publication?
 
Yes.
 
2) Has the document had adequate review from both key WG members and
   key non-WG members? Do you have any concerns about the depth or
   breadth of the reviews that have been performed?
 
Yes. The ID has had 2 working group last calls.
 
3) Do you have concerns that the document needs more review from a
   particular (broader) perspective (e.g., security, operational
   complexity, someone familiar with AAA, etc.)?
 
No concerns.  The document has been reviewed both by the ISMS WG
as well as by RADEXT WG. 
 
4) Do you have any specific concerns/issues with this document that
   you believe the ADs and/or IESG should be aware of? For example,
   perhaps you are uncomfortable with certain parts of the document,
   or whether there really is a need for it, etc., but at the same
   time these issues have been discussed in the WG and the WG has
   indicated it wishes to advance the document anyway.
 
No.
 
5) How solid is the WG consensus behind this document?  Does it
   represent the strong concurrence of a few individuals, with others
   being silent, or does the WG as a whole understand and agree with
   it?
 
There is solid consensus behind this document.  7 people other 
than the author have commented on various aspects of the 
document. The issues raised, available for inspection at
http://www.drizzle.com/~aboba/RADEXT/, were resolved in the -04
version of the document.
 
6) Has anyone threatened an appeal or otherwise indicated extreme
   discontent?  If so, please summarize what are they upset about.
 
No.
 
7) Have the chairs verified that the document adheres to _all_ of the
   ID nits?  (see http://www.ietf.org/ID-nits.html).
 
Yes. An output of the run on this revision of the ID by the online nits
checker:
 
idnits 2.08.10 
 
tmp/draft-ietf-radext-management-authorization-05.txt:
 
  Checking boilerplate required by RFC 3978 and 3979, updated by RFC 4748:
----------------------------------------------------------------------------
     No issues found here.
  Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:
----------------------------------------------------------------------------
     No issues found here.
  Checking nits according to http://www.ietf.org/ID-Checklist.html:
----------------------------------------------------------------------------
     No issues found here.
  Miscellaneous warnings:
----------------------------------------------------------------------------
     No issues found here.
  Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
     (See RFCs 3967 and 4897 for information about using normative 
references
     to lower-maturity documents in RFCs)
 
     No issues found here.
     No nits found.
--------------------------------------------------------------------------------
 
8) Does the document a) split references into normative/informative,
   and b) are there normative references to IDs, where the IDs are not
   also ready for advancement or are otherwise in an unclear state?
   (Note: the RFC editor will not publish an RFC with normative
   references to IDs, it will delay publication until all such IDs are
   also ready for publication as RFCs.)
 
The document splits references into normative and informative ones.
There are no normative references to IDs.
 
9) For Standards Track and BCP documents, the IESG approval
   announcement includes a writeup section with the following
   sections:
 
   - Technical Summary
 
   This document specifies RADIUS attributes for authorization and
   service provisioning of Network Access Server (NAS) management.
   Both local and remote management are supported, with granular access 
   rights and management privileges.  Specific provisions are made for 
   remote management via framed management protocols, and for 
   specification of a protected transport protocol.  
 
    - Working Group Summary
 
    There have been 2 WGLCs on the document.  Much of the discussion on
    the document has centered around the model for provisioning of 
    protected transports, as well as the different remote administration
    mechanisms (secure and insecure) to be supported.  There has also
    been discussion of the relationship between Framed Management 
    (introduced in this draft) and the pseudo-TTY management model 
    supported in RFC 2865.

Delivery-date: Mon, 14 Jul 2008 14:46:59 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-radext-management-authorization-05.txt 
Date: Mon, 14 Jul 2008 07:45:01 -0700 (PDT)

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the RADIUS EXTensions Working Group of the IETF.

	Title           : Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) Management
	Author(s)       : D. Nelson, G. Weber
	Filename        : draft-ietf-radext-management-authorization-05.txt
	Pages           : 24
	Date            : 2008-07-14

This document specifies Remote Authentication Dial-In User Service
(RADIUS) attributes for authorizing management access to a Network
Access Server (NAS).  Both local and remote management are supported,
with granular access rights and management privileges.  Specific
provisions are made for remote management via framed management
protocols, and for management access over a secure transport
protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-management-authorization-05.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-radext-management-authorization-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[email-masked]>

--NextPart--

Delivery-date: Sun, 13 Jul 2008 21:37:44 +0000
Date: Sun, 13 Jul 2008 14:36:09 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Comment on draft-ietf-radext-design-04.txt, Appendix A

There are a few cases where the text in Appendix A is not backed by 
discussion in the rest of the document, and vice versa.  

A.4

      * Extending the RADIUS packet length limitation past 4096 octets.
        A multi-packet sequence of Access-Request / Access-Challenge
        SHOULD be used instead.  If that is not possible, then a method
        other than RADIUS SHOULD be used to transport the data.

[BA] Generally, the Design Guidelines in Appendix A are supported by text 
elsewhere in the document.  This one has no corresponding discussion, and 
it seems to me that there are enough issues so  that adding a section for 
such a discussion could be beneficial.  For example:

* Discussion of the length restriction.  As far as I can tell, the length 
restriction is mentioned only in RFC 2865 Section 3.  However, there 
is no normative language or even discussion on how receivers behave 
on encountering larger packets.  Based on this, one thing we can say is 
that a sender cannot by default assume that a receiver will be able to 
handle a RADIUS packet longer than 4096 octets.  So my suggestion 
would be to rephrase the first sentence to state that attribute designers 
SHOULD NOT assume that receivers can handle packets larger than 4096 
octets.  In the discussion section, you can then talk about potential 
alternatives for designers. 

* Support for Access-Challenge.  In looking back at the WG discussion on 
attribute length, the most frequently discussed cases where large 
attributes (and hence large packets) might be required are filter rules 
(e.g. NAS-Filter-Rule).  Unfortunately, Section 3 of RFC 4849 does not 
permit this attribute to be placed in an Access-Challenge.  There are 
quite a few other attributes that also do not permit this usage (although 
most are not large enough to be an issue).   Even if this were to be 
fixed, using a multi-packet sequence would imply that RADIUS attributes in 
a subsequent packet would be concatenated to those in a new packet, as 
opposed to replacing them.  So it seems to me that the attribute would 
need to be specially designed for fragmentation across multi-packet 
sequences.  I don't think we can see that even the Extended Attributes are 
designed for such a use. 

Also, as we discussed in the RADIUS location work, not all NASes are going 
to be "Challenge capable" for a access mechanism.  Does this imply wider 
use of the Challenge-Capable Attribute than what is implied in the RADIUS 
location draft? 

Given all of this, it is not clear to me that the suggestion in the rest 
of the paragraph will be workable in all situations.  

My suggestion is to change A.4 to the following:

A.4. Changes to the RADIUS Protocol

   Does the attribute specification change the RADIUS operational model?
   If so, then another mmethod of achieving the design objectives SHOULD 
   be used.  Potential problems include: 

      * Defining new commands in RADIUS using attributes.  
        The addition of new commands to RADIUS should be handled 
        via allocation of a new command Code, not by use of an attribute.  
        This includes new commands created by overloading attributes such 
        as the Service-Type attribute to define new values that modify
        the functionality of Access-Request packets.
      * Using RADIUS as a transport protocol for data unrelated to
        authentication, authorization or accounting.  Using RADIUS
        to transport authentication methods such as EAP is explicitly
        permited, even if those methods require the transport of 
        relatively large amounts of data.  Transport of opaque
        data relating to AAA is also permitted, as discussed in
        Section 2.1.3.  However, if the specification does not
        relate to AAA, then RADIUS SHOULD NOT be used.  
      * Assuming support for packet lengths greater than 4096 octets.
        Attribute designers cannot assume that RADIUS implementations 
        can successfully handle packets larger than 4096 octets.  
        If a specification could lead to a RADIUS packet larger than
        4096 octets, then alternatives described in Section 3.3 
        SHOULD be considered. 
      * Stateless operation.  The RADIUS protocol is stateless, and 
        documents which require stateful protocol behavior without use of  
        the State Attribute need to be redesigned. 
      * Provisioning of service in an Access-Reject.  This is not 
        permitted.  If limited access needs to be provided, then an
        Access-Accept with appropriate authorizations can be used instead.
      * Lack of user authentication or authorization restrictions.  
        In an authorization check, where there is no demonstration of a 
        live user, confidential data cannot be returned.  Where there 
        is a link to a previous user authentication, the State attribute 
        needs to be present. 
      * Lack of per-packet integrity and authentication. 
        It is expected that documents will support per-packet
        integrity and authentication. 
      * Modification of RADIUS packet sequences.  In RADIUS,
        each request is encapsulated in its own packet, and
        elicits a single response, sent to the requester.  Since
        changes to this paradigm are likely to require major modifications
        to RADIUS client and server implementations, they SHOULD be
        avoided if possible. 

For further details, see Section 3.3. 

Also, change Section 3.3 to the following:

3.3.  RADIUS Operational Model

   The RADIUS operational model includes several assumptions:

      * The RADIUS protocol is stateless; 
      * Provisioning of services is not possible within an Access-Reject; 
      * Distinction between authorization checks and user authentication; 
      * Authentication and integrity protection of RADIUS packets; 
      * RADIUS is a Client/Server protocol;
      * Packet length restriction. 

   While RADIUS server implementations may keep state, the RADIUS
   protocol is stateless, although information may be passed from one
   protocol transaction to another via the State Attribute.  As a
   result, documents which require stateful protocol behavior without
   use of the State Attribute are inherently incompatible with RADIUS as
   defined in [RFC2865], and need to be redesigned.  See [RFC5080]
   Section 2.1.1 for a more in-depth discussion of the use of the State
   Attribute.

   As noted in [RFC5080] Section 2.6, the intent of an Access-Reject is
   to deny access to the requested service.  As a result, RADIUS does
   not allow the provisioning of services within an Access-Reject.
   Documents which include provisioning of services within an Access-
   Reject are inherently incompatible with RADIUS, and need to be
   redesigned.

   As noted in [RFC5080] Section 2.1.1, a RADIUS Access-Request may not
   contain user authentication attributes or a State Attribute linking
   the Access-Request to an earlier user authentication.  Such an
   Access-Request, known as an authorization check, provides no
   assurance that it corresponds to a live user.  RADIUS specifications
   defining attributes containing confidential information (such as
   Tunnel-Password) should be careful to prohibit such attributes from
   being returned in response to an authorization check.  Also,
   [RFC5080] Section 2.1.1 notes that authentication mechanisms need to
   tie a sequence of Access-Request/Access-Challenge packets together
   into one authentication session.  A similar need exists when 
   dynamic authorization is used in as noted in [RFC5176] Section 3.3. 
   The State Attribute is RECOMMENDED for this purpose.  

   While [RFC2865] did not require authentication and integrity
   protection of RADIUS Access-Request packets, subsequent
   authentication mechanism specifications such as RADIUS/EAP [RFC3579]
   and Digest Authentication [RFC5090] have mandated authentication and
   integrity protection for certain RADIUS packets.  [RFC5080] Section
   2.1.1 makes this behavior RECOMMENDED for all Access-Request packets,
   including Access-Request packets performing authorization checks.  It
   is expected that specifications for new RADIUS authentication
   mechanisms will continue this practice.

   The RADIUS protocol as defined in [RFC2865] is a request-response
   protocol spoken between RADIUS clients and servers.  A single RADIUS
   Access-Request packet will solicit in response at most a single
   Access-Accept, Access-Reject or Access-Challenge packet, sent to the
   IP address and port of the RADIUS Client that originated the Access-
   Request.  Similarly, a single Change-of-Authorization (CoA)-Request
   packet [RFC5176] will solicit in response at most a single CoA-ACK or
   CoA-NAK packet, sent to the IP address and port of the Dynamic
   Authorization Client (DAC) that originated the CoA-Request.  A single
   Disconnect-Request packet will solicit in response at most a single
   Disconnect-ACK or Disconnect-NAK packet, sent to the IP address and
   port of the Dynamic Authorization Client (DAC) that originated the
   CoA-Request.  Changes to this model are likely to require major
   revisions to existing implementations and so this is NOT RECOMMENDED.

   The Length field in the RADIUS packet header is defined in [RFC2865]
   Section 3.  It is noted there that the maximum length of a RADIUS
   packet is 4096 octets.  As a result, attribute designers SHOULD NOT
   assume that a RADIUS implementation can successfully process 
   RADIUS packets larger than 4096 octets.  If a situation is envisaged
   where it may be necessary to carry authentication, authorization or
   accounting data in a packet larger than 4096 octets, then one of 
   the following approaches is RECOMMENDED: 

     1. Utilization of a sequence of packets.  In the case of RADIUS
        accounting, this would include a sequence of Accounting-Request
        packets.  This is non-trivial since RADIUS accounting clients 
        would need to be modified to split the attribute stream across 
        multiple Accounting-Requests, and billing servers would need to be 
        modified to re-assemble and interpret the attribute stream. 
        For RADIUS authentication, a sequence of Access-Request/
        Access-Challenge packets would be used; for this to be feasible,
        attribute designers need to enable inclusion of
        attributes that can consume considerable space within 
        Access-Challenge packets.  To maintain compatibility with 
        existing NASes,  either the use of Access-Challenge 
        packets needs to be permissible (as with RADIUS/EAP, defined in 
        [RFC3579]), or support for receipt of an Access-Challenge needs to 
        be indicated by the NAS (as in RADIUS Location [RADIUSLOC]). Also, 
        the specification needs to clearly describe how attribute 
        splitting is signalled and how attributes included within
        the sequence are to be interpretted, without requiring
        stateful operation.  Unfortunately, previous specifications
        have not always exhibited the required foresight.  For example, 
        even though very large filter rules are conceivable, the NAS-Filter-Rule
        Attribute defined in [RFC4849] is not permitted in an 
        Access-Challenge packet, nor is a mechanism specified to
        allow a set of NAS-Filter-Rule attributes to be split across
        an Access-Request/Access-Challenge sequence. 

     2. Utilization of names rather than values.  Where an attribute
        relates to a policy that could conceivably be pre-provisioned
        on the NAS, then the name of the pre-provisioned policy can be 
        transmitted in an attribute, rather than the policy itself, 
        which could be quite large.  An example of this is the Filter-Id 
        Attribute defined in [RFC2865] Section 5.11, which enables a set 
        of pre-provisioned filter rules to be referenced by name. 

     3. Utilization of Packetization Layer Path MTU Discovery
        techniques, as specified in [RFC4821].  As a last resort, where
        the above techniques cannot be made to work, it may be possible
        to apply the techniques described in [RFC4821] to discovery of
        of the maximum supported RADIUS packet size on the path between
        a RADIUS client and a home server.  While such an approach 
        can avoid the complexity of utilization of a sequence of 
        packets, dynamic discovery is likely to be time consuming
        and cannot be guaranteed to work with existing RADIUS 
        implementations.  As a result, this technique is not 
        generally applicable. 

Delivery-date: Sat, 12 Jul 2008 03:17:56 +0000
Date: Fri, 11 Jul 2008 20:16:14 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: "David B. Nelson" <[email-masked]>
cc: [email-masked], 'Bernard Aboba' <[email-masked]>
Subject: RE: Question on draft-ietf-radext-management-authorization-04.txt

> OK, I don't know what typical NAS implementations use for NAS-Port and/or
> NAS-Port-Id for remote connections, e.g. when the NAS-Port-Type is Virtual.
> 
> I could imagine that they might use a number of things.  Remote IP address
> and Remote TCP Port are one possibility.  The file descriptor value for use
> with the open socket might be another.  By definition, the values are
> transient, or if the value is not transient, the status of the particular
> virtual port instance they describe certainly would be.  I suppose that what
> would be important is that the NAS *has* some unique and meaningful values
> for those attributes, valid for the duration of the remote management
> session.

Right.  The issue isn't so much how they fill in the values, but that they 
need to include *some* kind of port and session identification if dynamic 
authorization is to work well.  This might not be obvious to readers.

Delivery-date: Fri, 11 Jul 2008 20:08:12 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Cc: "'Bernard Aboba'" <[email-masked]>
Subject: RE: Question on draft-ietf-radext-management-authorization-04.txt
Date: Fri, 11 Jul 2008 16:06:53 -0400
Organization: Elbrys Networks, Inc.

> Typically, the way that this kind of problem is solved is via 
> addition of session identification attributes, such as the
> Acct-Session-Id, NAS-Port or NAS-Port-Id.  Is a NAS-Port/
> NAS-Port-Id Attribute likely to be available in the case of 
> a management session (local or remote)?

OK, I don't know what typical NAS implementations use for NAS-Port and/or
NAS-Port-Id for remote connections, e.g. when the NAS-Port-Type is Virtual.

I could imagine that they might use a number of things.  Remote IP address
and Remote TCP Port are one possibility.  The file descriptor value for use
with the open socket might be another.  By definition, the values are
transient, or if the value is not transient, the status of the particular
virtual port instance they describe certainly would be.  I suppose that what
would be important is that the NAS *has* some unique and meaningful values
for those attributes, valid for the duration of the remote management
session.

> If an Acct-Session-Id exists, this is probably the
> cleanest way to solve the problem.

Yes.

Delivery-date: Fri, 11 Jul 2008 19:49:30 +0000
From: "David B. Nelson" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Question on draft-ietf-radext-management-authorization-04.txt
Date: Fri, 11 Jul 2008 15:48:16 -0400
Organization: Elbrys Networks, Inc.

> So I think we're talking about trying to dis-ambiguate a situation
> where there is a valid User-Name attribute, but perhaps multiple
> sessions associated with that.  It might be worth quoting some
> text from RFC 5176 regarding the recommended NAS and session 
> identification attributes, since it might not necessarily be 
> obvious that an Access-Request for a management session should
> necessarily have a NAS-Port/NAS-Port-Id + Acct-Session-Id 
> associated with it.

I can remove the Framed-Management-Protocol and
Management-Transport-Protection Attributes from usage as "session
identifiers" for Dynamic Authorization and quote chapter and verse from RFC
5176 as to what SHOULD be used as "session identifiers".

I think that will cover the "80% problem" without introducing too many
opportunities for odd behaviors and wild-card usages.

The only reason that I could see for a NAS to not include the appropriate
session identifier attributes in an Access-Request message would be if the
NAS implementation didn't assign identifiers until it processed the
Access-Accept message, i.e. didn't want to assign IDs to sessions that may
never materialize, or the NAS implementation didn't support RADIUS
accounting, and thus had no notion of session identifiers.

Do we need to add some wiggle room to cover those corner cases?

Delivery-date: Fri, 11 Jul 2008 19:29:43 +0000
Date: Fri, 11 Jul 2008 12:27:54 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: "David B. Nelson" <[email-masked]>
cc: [email-masked], 'Bernard Aboba' <[email-masked]>
Subject: RE: Question on draft-ietf-radext-management-authorization-04.txt

> I think RFC 5176 already says that.  But then it goes on to provide for
> additional forms of session identifying attributes, for the cases when the
> "SHOULD" doesn't apply.
>
> One of the use cases that motivate some of this behavior is the "privacy
> NAI", i.e. anonymous (external) authentication, in which the RADIUS entities
> don't have the actual user identity.  I think that makes sense for certain
> forms of network access.  I can't imagine a valid use for anonymous
> authentication for the purpose of NAS management, however.  :-)

Right.  So I think we're talking about trying to dis-ambiguate a situation 
where there is a valid User-Name attribute, but perhaps multiple sessions 
associated with that.  It might be worth quoting some text from RFC 5176 
regarding the recommended NAS and session identification attributes, since 
it might not necessarily be obvious that an Access-Request for a 
management session should necessarily have a NAS-Port/NAS-Port-Id + 
Acct-Session-Id associated with it. 

> As an "overlay" to the "SHOULD" in RFC 5176?

Quoting from RFC 5176 would be sufficient. 

> > Assuming we do this, then the remaining use of
> > Framed-Management-Protocol and Management-Transport-Protection in 
> > a CoA-Request would be as a wildcard.  As you say, this kind of
> > use will probably not be mainstream - which raises the question
> > of whether putting it in is worth the interoperability issues it
> > might end up raising.
> 
> Right.

Delivery-date: Fri, 11 Jul 2008 16:20:39 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Cc: "'Bernard Aboba'" <[email-masked]>
Subject: RE: Question on draft-ietf-radext-management-authorization-04.txt
Date: Fri, 11 Jul 2008 12:18:33 -0400
Organization: Elbrys Networks, Inc.

> Another way to solve the problem is to specify that one or more
> of the above session identification attributes SHOULD be present
> in a management Access-Request.

I think RFC 5176 already says that.  But then it goes on to provide for
additional forms of session identifying attributes, for the cases when the
"SHOULD" doesn't apply.

> That way those attributes are likely to be available for session
> identification in the event that dynamic authorization is needed.

Indeed.  We *could* say that if your implementation doesn't follow the
"SHOULD" in RFC 5176 regarding the inclusion of session IDs, and the Dynamic
Authorization Client doesn't have the appropriate session ID attribute(s)
available, you're simply out of luck.

One of the use cases that motivate some of this behavior is the "privacy
NAI", i.e. anonymous (external) authentication, in which the RADIUS entities
don't have the actual user identity.  I think that makes sense for certain
forms of network access.  I can't imagine a valid use for anonymous
authentication for the purpose of NAS management, however.  :-)

> I think it might be worthwhile to add a section on dynamic 
> authorization, clarifying what session identification attributes 
> SHOULD be included in an Access-Request.

As an "overlay" to the "SHOULD" in RFC 5176?

> Assuming we do this, then the remaining use of
> Framed-Management-Protocol and Management-Transport-Protection in 
> a CoA-Request would be as a wildcard.  As you say, this kind of
> use will probably not be mainstream - which raises the question
> of whether putting it in is worth the interoperability issues it
> might end up raising.

Right.

Delivery-date: Fri, 11 Jul 2008 14:20:57 +0000
Date: Fri, 11 Jul 2008 16:19:41 +0200
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: "David B. Nelson" <[email-masked]>, [email-masked]
Subject: Re: REMINDER: RADEXT WG Last Call on Design Guidelines Document

Bernard Aboba wrote:
> Ugh.  I wonder how the RADSEC proxy would function when receiving packets 
> from an implementation like that.

  If both IP's are listed as clients, then all the packets get processed.

> RFC 5080 does suggest that NAS-Identifier be used to avoid 
> multi-homing confusion, at least within the RADIUS packet itself.  
> Using different source addresses does seem "novel" - and quite 
> likely to confuse.  One can imagine quite bizarre scenarios for an interop 
> torture test - like having a NAS sending RADIUS/EAP packets within the 
> same session from different IP addresses.  The RFC 5080 algorithm in 
> Section 2.1.2 references "source IP", so it would be confused by this, 
> wouldn't it? 

  Yes.  Luckily so far, devices do this only for accounting packets.

  Anyone crazy enough to do this for EAP will quickly discover that it
Just Doesn't Work.  They'll then fix their implementation.

  For accounting packets, it's harder to claim that this behavior
violates the spec.

  Alan DeKok.

Delivery-date: Fri, 11 Jul 2008 14:02:40 +0000
Date: Fri, 11 Jul 2008 07:01:44 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: "David B. Nelson" <[email-masked]>
cc: [email-masked], 'Alan DeKok' <[email-masked]>
Subject: RE: REMINDER: RADEXT WG Last Call on Design Guidelines Document

> >   e.g. I just ran into devices with multiple interfaces that send
> > Accounting-Requests from IP (1) for Start/Stop, and from IP (2) for
> > Interim-Updates.
> > 
> >   Since this isn't forbidden by the specs, they have no interest in
> > fixing it.  It's everyone *else* that has to butcher their systems in
> > order to deal with such nonsense.

Ugh.  I wonder how the RADSEC proxy would function when receiving packets 
from an implementation like that.

RFC 5080 does suggest that NAS-Identifier be used to avoid 
multi-homing confusion, at least within the RADIUS packet itself.  
Using different source addresses does seem "novel" - and quite 
likely to confuse.  One can imagine quite bizarre scenarios for an interop 
torture test - like having a NAS sending RADIUS/EAP packets within the 
same session from different IP addresses.  The RFC 5080 algorithm in 
Section 2.1.2 references "source IP", so it would be confused by this, 
wouldn't it? 

Delivery-date: Fri, 11 Jul 2008 13:54:19 +0000
Date: Fri, 11 Jul 2008 06:52:54 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: "David B. Nelson" <[email-masked]>
cc: [email-masked], 'Bernard Aboba' <[email-masked]>
Subject: RE: Question on draft-ietf-radext-management-authorization-04.txt

> For example suppose there are three sessions with a User-Name of "dave", one
> with a Service-Type of "NAS-Prompt", and two with a Service-Type of
> "Framed-Management".  Of the latter two, one has a
> Framed-Management-Protocol of "Web-based" and the other has a
> Framed-Management-Protocol of "SNMP".  If you want to affect the web
> session, you need to "address" the session either by an available session ID
> attribute, which is preferable in my opinion, or by the value of
> Framed-Management-Protocol, if the session ID information is not available.

Typically, the way that this kind of problem is solved is via addition of 
session identification attributes, such as the Acct-Session-Id, NAS-Port 
or NAS-Port-Id.  Is a NAS-Port/NAS-Port-Id Attribute likely to be 
available in the case of a management session (local or remote)?  This is 
not clear to me. If an Acct-Session-Id exists, this is probably the 
cleanest way to solve the problem.  

> >    In this case, if it is desired to identify a single session,
> >    session identification MAY be performed by using one or more of the
> >    Framed-IP-Address, Framed-IPv6-Prefix/Framed-Interface-Id, Called-
> >    Station-Id, Calling-Station-Id, NAS-Port, and NAS-Port-Id attributes.
> 
> It is in the sprit of this last paragraph that I proposed that some of the
> management provisioning attributes, specifically Framed-Management-Protocol
> and Management-Transport-Protection *could* be used to further identify one
> session from another.  Unfortunately, that usage also allows any of these
> "provisioning" attributes to be use alone (or in combination with others) to
> form all sorts of interesting (maybe not useful) wild-card matches.

Another way to solve the problem is to specify that one or more of the 
above session identification attributes SHOULD be present in a management 
Access-Request.  That way those attributes are likely to be available for 
session identification in the event that dynamic authorization is needed. 

> We can eliminate Framed-Management-Protocol and
> Management-Transport-Protection from such usage in this document.  We can't
> go back and clarify the "murkiness" that exists in RFC 5176 about using this
> sort of wild-card matching when selecting one or more sessions for action.

I think it might be worthwhile to add a section on dynamic authorization, 
clarifying what session identification attributes SHOULD be included in an 
Access-Request.  Assuming we do this, then the remaining use of 
Framed-Management-Protocol and Management-Transport-Protection in a 
CoA-Request would be as a wildcard.  As you say, this kind of use will 
probably not be mainstream - which raises the question of whether putting 
it in is worth the interoperability issues it might end up raising. 

Delivery-date: Fri, 11 Jul 2008 12:37:09 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Cc: "'Alan DeKok'" <[email-masked]>
Subject: RE: REMINDER: RADEXT WG Last Call on Design Guidelines Document
Date: Fri, 11 Jul 2008 08:36:37 -0400

>   Leaving it open ended might not be catastrophic.  The rest of RADIUS
> is open ended.

It might not be catastrophic.  OTOH, just because there are so many "issues"
that arise because RADIUS is so open-ended, the engineer in me wants to
"fix" some of that, at least in any new features we introduce.

>   e.g. I just ran into devices with multiple interfaces that send
> Accounting-Requests from IP (1) for Start/Stop, and from IP (2) for
> Interim-Updates.
> 
>   Since this isn't forbidden by the specs, they have no interest in
> fixing it.  It's everyone *else* that has to butcher their systems in
> order to deal with such nonsense.

Yeah, well that's the kind of thing that motivates me to craft tighter
specifications for new features we're adding to RADIUS.  We can't fix the
past, but we don't need to add fuel to the fire, either.

Delivery-date: Fri, 11 Jul 2008 12:29:47 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Cc: "'Bernard Aboba'" <[email-masked]>
Subject: RE: Question on draft-ietf-radext-management-authorization-04.txt
Date: Fri, 11 Jul 2008 08:28:34 -0400

> [BA] Using the Framed-Management-Protocol and
> Management-Transport-Protection attributes for session identification
> would seem to imply the need to change the Management-Policy-Id and
> Management-Privilege-Level attributes based on values of those
> attributes, affecting multiple sessions.  The text does not talk about
> when this might be used, so wanted to make sure we understand what the
> potential uses are.

I did send the proposed table of attributes text in an e-mail to the list,
soliciting WG feedback, *before* I submitted -04.  However...   We're
getting that feedback now.

> Some possibilities that come to mind:
> 
> 1. Change the Management-Policy-Id of all sessions with
> Framed-Management-Protocol equal to a particular value.
> 
> A potential example might involve configuration of a new Management policy
> for web-based management; a CoA-Request might be used to cause this to be
> activated for all web-based management sessions currently active on a
> particular NAS.

I suppose.

The whole issue of using RADIUS attributes, other than the User-Name or one
of the session ID attributes, to identify one or more sessions seems pretty
murky to me.  I can see some scenarios where adding some "provisioning"
attributes into a request as further specification makes sense, however.
For example suppose there are three sessions with a User-Name of "dave", one
with a Service-Type of "NAS-Prompt", and two with a Service-Type of
"Framed-Management".  Of the latter two, one has a
Framed-Management-Protocol of "Web-based" and the other has a
Framed-Management-Protocol of "SNMP".  If you want to affect the web
session, you need to "address" the session either by an available session ID
attribute, which is preferable in my opinion, or by the value of
Framed-Management-Protocol, if the session ID information is not available.

> 2. Change the Mangement-Privilege-Level of all sessions with
> Management-Transport-Protection equal to a particular value.
> 
> A potential example might involve discovery of a vulnerability in a
> particular Management transport (e.g. the GNU TLS vulnerability discovered
> recently).  To avoid the potential for compromise, dynamic authorization
> might be used to lower the privileges of all sessions using that
> protection mechanism, at least until a patch becomes available.
> 
> Do people think that these examples make sense?

I think they make sense.  Whether they are within the bounds of "the 80%
problem" is another matter.

> Typically, dynamic authorization has been used to affect particular
> sessions, but the changes in [RFC5176] now make it possible to affect
> several sessions at once, using identification attributes, so discussions
> like this are likely to become more common.

Yes.  I've already indicated, above, that I think this extra flexibility can
be "murky" in its potential applications.

> Here is what RFC 5176 Section 3 says about NAS and session
> identificaiton attributes:
> 
>    In Disconnect-Request and CoA-Request packets, certain attributes are
>    used to uniquely identify the NAS as well as user session(s) on the
>    NAS.  The combination of NAS and session identification attributes
>    included in a CoA-Request or Disconnect-Request packet MUST match at
>    least one session in order for a Request to be successful; otherwise
>    a Disconnect-NAK or CoA-NAK MUST be sent.  If all NAS identification
>    attributes match, and more than one session matches all of the
>    session identification attributes, then a CoA-Request or Disconnect-
>    Request MUST apply to all matching sessions.
> 
>    . . .
> 
>    To address security concerns described in Section 6.1, either the
>    User-Name or Chargeable-User-Identity attribute SHOULD be present in
>    Disconnect-Request and CoA-Request packets.
> 
>    . . .
> 
>    A NAS implementing this specification SHOULD send an Acct-Session-Id
>    or Acct-Multi-Session-Id Attribute within an Access-Request.  Where
>    an Acct-Session-Id or Acct-Multi-Session-Id Attribute is not included
>    within an Access-Request, the Dynamic Authorization Client will not
>    know the Acct-Session-Id or Acct-Multi-Session-Id of the session it
>    is attempting to target, unless it also has access to the accounting
>    data for that session.
> 
>    Where an Acct-Session-Id or Acct-Multi-Session-Id Attribute is not
>    present in a CoA-Request or Disconnect-Request, it is possible that
>    the User-Name or Chargeable-User-Identity attributes will not be
>    sufficient to uniquely identify a single session (e.g., if the same
>    user has multiple sessions on the NAS, or if the privacy NAI is
>    used).  In this case, if it is desired to identify a single session,
>    session identification MAY be performed by using one or more of the
>    Framed-IP-Address, Framed-IPv6-Prefix/Framed-Interface-Id, Called-
>    Station-Id, Calling-Station-Id, NAS-Port, and NAS-Port-Id attributes.

It is in the sprit of this last paragraph that I proposed that some of the
management provisioning attributes, specifically Framed-Management-Protocol
and Management-Transport-Protection *could* be used to further identify one
session from another.  Unfortunately, that usage also allows any of these
"provisioning" attributes to be use alone (or in combination with others) to
form all sorts of interesting (maybe not useful) wild-card matches.

We can eliminate Framed-Management-Protocol and
Management-Transport-Protection from such usage in this document.  We can't
go back and clarify the "murkiness" that exists in RFC 5176 about using this
sort of wild-card matching when selecting one or more sessions for action.

Delivery-date: Fri, 11 Jul 2008 09:30:34 +0000
Date: Fri, 11 Jul 2008 11:28:29 +0200
From: Alan DeKok <[email-masked]>
To: "David B. Nelson" <[email-masked]>
CC: [email-masked]
Subject: Re: REMINDER: RADEXT WG Last Call on Design Guidelines Document

David B. Nelson wrote:
> OK, so that's not a viable simplification.  I'm still fishing for a
> definition of "security functionality", as used in this context, that's less
> open-ended than the plain meaning as found in the dictionary.

  Leaving it open ended might not be catastrophic.  The rest of RADIUS
is open ended.

  e.g. I just ran into devices with multiple interfaces that send
Accounting-Requests from IP (1) for Start/Stop, and from IP (2) for
Interim-Updates.

  Since this isn't forbidden by the specs, they have no interest in
fixing it.  It's everyone *else* that has to butcher their systems in
order to deal with such nonsense.

>>   If SDOs need functionality that is useful to *everyone*, they can
>> request standard space allocation.  If SDOs are defining their own
>> specifications, they do not need standard space allocation.
> 
> How, exactly, do we define "everyone"?

  "The wider Internet community".

>> I'm not sure many SDOs would agree to cede change control over
>> their allocations to IANA.  I'm not sure that IANA wants that work,
>> either.
> 
> Isn't IANA funded to allocate code points to anyone who presents a valid
> request, even individuals?

  Yes.. but change control?  I don't think any SDO forum would be
willing to go through IANA for SDO specific attribute allocation.

> To some extent, I think this is a matter of nomenclature.  If we say that
> the RADIUS code space is divided between "standard" space and "Vendor
> Specific" space, we effectively lump SDO uses, would could be very broadly
> adopted, with proprietary vendor uses, which could have minimal, if any,
> deployment.

  Yes.  That's the reality, unfortunately.

>  That's why I've been touting the term SDO Specific Attribute.
> True, it uses the Vendor Specific Attribute format (and top-level ID), but
> it allows for a distinction between proprietary vendor uses and standardized
> uses.  The distinction between "IETF standard" space and "other SDO
> standard" space then becomes merely a matter of which registry is used, and
> not a matter of "standard" vs. "non-standard".

  The document already refers to SSA's.  I think that's good enough.

  Alan DeKok.

Delivery-date: Fri, 11 Jul 2008 06:39:32 +0000
Date: Thu, 10 Jul 2008 23:38:09 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Question on draft-ietf-radext-management-authorization-04.txt

8. Table of Attributes

   Change-of-Authorization Messages
   Request  ACK   NAK   #     Attribute
   --------------------------------------------------------------------
   0-1     0     0   TBA-2   Framed-Management-Protocol (Note 1)
   0-1     0     0   TBA-3   Management-Transport-Protection (Note 1)
   0-1     0     0   TBA-4   Management-Policy-Id (Note 2)
   0-1     0     0   TBA-5   Management-Privilege-Level (Note 2)

  Disconnect Messages
  Request  ACK   NAK   #     Attribute
  ----------------------------------------------------------------------
  0-1      0     0   TBA-2   Framed-Management-Protocol (Note 1)
  0-1      0     0   TBA-3   Management-Transport-Protection (Note 1)
  0        0     0   TBA-4   Management-Policy-Id
  0        0     0   TBA-5   Management-Privilege-Level
 
    (Note 1) Where NAS or session identification attributes are included
    in Disconnect-Request or CoA-Request packets, they are used for
    identification purposes only.  These attributes MUST NOT be used for
    purposes other than identification (e.g., within CoA-Request packets
    to request authorization changes).

[BA] Using the Framed-Management-Protocol and 
Management-Transport-Protection attributes for session identification 
would seem to imply the need to change the Management-Policy-Id and 
Management-Privilege-Level attributes based on values of those 
attributes, affecting multiple sessions.  The text does not talk about 
when this might be used, so wanted to make sure we understand what the 
potential uses are. 

Some possibilities that come to mind: 

1. Change the Management-Policy-Id of all sessions with 
Framed-Management-Protocol equal to a particular value. 

A potential example might involve configuration of a new Management policy 
for web-based management; a CoA-Request might be used to cause this to be 
activated for all web-based management sessions currently active on a 
particular NAS. 

2. Change the Mangement-Privilege-Level of all sessions with 
Management-Transport-Protection equal to a particular value. 

A potential example might involve discovery of a vulnerability in a 
particular Management transport (e.g. the GNU TLS vulnerability discovered 
recently).  To avoid the potential for compromise, dynamic authorization 
might be used to lower the privileges of all sessions using that 
protection mechanism, at least until a patch becomes available. 

Do people think that these examples make sense? 

Typically, dynamic authorization has been used to affect particular 
sessions, but the changes in [RFC5176] now make it possible to affect 
several sessions at once, using identification attributes, so discussions 
like this are likely to become more common. 

Here is what RFC 5176 Section 3 says about NAS and session 
identificaiton attributes:

   In Disconnect-Request and CoA-Request packets, certain attributes are
   used to uniquely identify the NAS as well as user session(s) on the
   NAS.  The combination of NAS and session identification attributes
   included in a CoA-Request or Disconnect-Request packet MUST match at
   least one session in order for a Request to be successful; otherwise
   a Disconnect-NAK or CoA-NAK MUST be sent.  If all NAS identification
   attributes match, and more than one session matches all of the
   session identification attributes, then a CoA-Request or Disconnect-
   Request MUST apply to all matching sessions.

   . . .

   To address security concerns described in Section 6.1, either the
   User-Name or Chargeable-User-Identity attribute SHOULD be present in
   Disconnect-Request and CoA-Request packets.

   . . .

   A NAS implementing this specification SHOULD send an Acct-Session-Id
   or Acct-Multi-Session-Id Attribute within an Access-Request.  Where
   an Acct-Session-Id or Acct-Multi-Session-Id Attribute is not included
   within an Access-Request, the Dynamic Authorization Client will not
   know the Acct-Session-Id or Acct-Multi-Session-Id of the session it
   is attempting to target, unless it also has access to the accounting
   data for that session.

   Where an Acct-Session-Id or Acct-Multi-Session-Id Attribute is not
   present in a CoA-Request or Disconnect-Request, it is possible that
   the User-Name or Chargeable-User-Identity attributes will not be
   sufficient to uniquely identify a single session (e.g., if the same
   user has multiple sessions on the NAS, or if the privacy NAI is
   used).  In this case, if it is desired to identify a single session,
   session identification MAY be performed by using one or more of the
   Framed-IP-Address, Framed-IPv6-Prefix/Framed-Interface-Id, Called-
   Station-Id, Calling-Station-Id, NAS-Port, and NAS-Port-Id attributes.

Delivery-date: Fri, 11 Jul 2008 05:28:21 +0000
Date: Thu, 10 Jul 2008 22:26:30 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Conclusion of RADEXT WG last call on "RADIUS Design Guidelines"

The RADEXT WG last call on "RADIUS Design Guidelines" has 
completed.  Comments were received, corresponding to Issues 260-269 in 
the Issues Tracker.  Of the issues, 5 were technical, and 5 were 
editorial.

To view the discussion relating to these issues, click on the following 
link:
http://ops.ietf.org/lists/radiusext/2008/threads.html

Delivery-date: Fri, 11 Jul 2008 03:17:26 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-radext-management-authorization-04.txt 
Date: Thu, 10 Jul 2008 20:15:01 -0700 (PDT)

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the RADIUS EXTensions Working Group of the IETF.

	Title           : Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) Management
	Author(s)       : D. Nelson, G. Weber
	Filename        : draft-ietf-radext-management-authorization-04.txt
	Pages           : 23
	Date            : 2008-07-10

This document specifies Remote Authentication Dial-In User Service
(RADIUS) attributes for authorizing management access to a Network
Access Server (NAS).  Both local and remote management are supported,
with granular access rights and management privileges.  Specific
provisions are made for remote management via framed management
protocols, and for management access over a secure transport
protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-management-authorization-04.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-radext-management-authorization-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[email-masked]>

--NextPart--

Delivery-date: Thu, 10 Jul 2008 19:46:42 +0000
Date: Thu, 10 Jul 2008 12:45:44 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: RADEXT WG Last Call on "Crypto-Agility Requirements for RADIUS"

This is an announcement of RADEXT WG Last Call on "Crypto-Agility 
Requirements for RADIUS" prior to requesting that the IESG publish it as 
an Informational RFC. 
 
The document is available here:
http://www.ietf.org/internet-drafts/draft-ietf-radext-crypto-agility-requirements-00.txt
 
WG Last Call will last until August 10, 2008.   Please review the document 
and post your comments to the RADEXT WG mailing list 
([email-masked]) in the format described on the RADEXT WG Issues 
list (http://www.drizzle.com/~aboba/RADEXT/).   
 
If you have read the document and approve of its publication, but have no
comments, please also post this to the list. 

Delivery-date: Thu, 10 Jul 2008 19:25:18 +0000
Date: Thu, 10 Jul 2008 12:24:27 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: RADEXT WG Last Call on Extended RADIUS Attributes

This is an announcement of RADEXT WG Last Call on "Extended RADIUS 
Attributes" prior to requesting that the IESG publish it as a Proposed 
Standard. 
 
The document is available here:
http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-attributes-04.txt
 
WG Last Call will last until July 24, 2008.   Please review the document 
and post your comments to the RADEXT WG mailing list 
([email-masked]) in the format described on the RADEXT WG Issues 
list (http://www.drizzle.com/~aboba/RADEXT/).   
 
If you have read the document and approve of its publication, but have no
comments, please also post this to the list. 

Delivery-date: Thu, 10 Jul 2008 19:21:16 +0000
Date: Thu, 10 Jul 2008 12:19:20 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Take one: RADEXT WG Agenda at IETF 72

9:00 - 9:10  Preliminaries
 Blue Sheets
 Note Takers
 Jabber Scribe
 Agenda bashing
 Document Status

Completed WG Last Call (30 minutes)

NAS Management Authorization, David Nelson, 10 minutes
http://www.ietf.org/internet-drafts/draft-ietf-radext-management-authorization-04.txt

Extended RADIUS Attributes, Glen Zorn, 10 minutes
http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-attributes-04.txt

RADIUS Design Guidelines, Alan DeKok, 10 minutes
http://www.ietf.org/internet-drafts/draft-ietf-radext-design-05.txt

Transport Documents (40 minutes)

TCP Transport, Alan DeKok, 10 minutes
http://www.ietf.org/internet-drafts/draft-dekok-radext-tcp-transport-00.txt

Status Server, Alan DeKok, 10 minutes
http://www.ietf.org/internet-drafts/draft-ietf-radext-status-server-00.txt

RADIUS over DTLS, Alan DeKok, 10 minutes
http://www.ietf.org/internet-drafts/draft-dekok-radext-dtls-01.txt

RADSEC, Stefan Winter, 10 minutes
http://www.ietf.org/internet-drafts/draft-ietf-radext-radsec-00.txt

RADIUS Cryptoagility (30 minutes)

RADIUS Cryptoagility requirements, David Nelson, 10 minutes
http://www.ietf.org/internet-drafts/draft-ietf-radext-crypto-agility-requirements-00.txt

RADIUS Cryptoagility, Glen Zorn, 10 minutes
http://www.ietf.org/internet-drafts/draft-zorn-radius-keywrap-13.txt

RADIUS Confidentiality, Glen Zorn, 10 minutes
http://www.ietf.org/internet-drafts/draft-zorn-radius-encattr-10.txt

Additional Documents (20 minutes)

RADIUS Attributes for IEEE 802 Networks, Bernard Aboba, 10 minutes
http://www.ietf.org/internet-drafts/draft-aboba-radext-wlan-08.txt

IPv6 Attributes for DHCP Networks, B. Lourdelet, 10 minutes
http://www.ietf.org/internet-drafts/draft-lourdelet-radext-ipv6-dhcp-00.txt

Delivery-date: Thu, 10 Jul 2008 12:46:46 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Additional comments on draft-ietf-radext-management-authorization-03.txt
Date: Thu, 10 Jul 2008 08:45:38 -0400

More follow up:

I could also envision permitting Framed-Management-Protocol and
Management-Transport-Protection as session identification attributes is a
CoA-Request, similar to their usage in a Disconnect-Request message.

> Add the following text to Section 12 (as currently numbered):
> 
> Change-of-Authorization Messages
> 
>    Request   ACK   NAK    #     Attribute
> 
>       0       0     0   TBA-2   Framed-Management-Protocol
>       0       0     0   TBA-3   Management-Transport-Protection
>       0-1     0     0   TBA-4   Management-Policy-Id (Note 2)
>       0-1     0     0   TBA-5   Management-Privilege-Level (Note 2)

    Request   ACK   NAK    #     Attribute
 
       0-1     0     0   TBA-2   Framed-Management-Protocol (Note 1)
       0-1     0     0   TBA-3   Management-Transport-Protection (Note 1)
       0-1     0     0   TBA-4   Management-Policy-Id (Note 2)
       0-1     0     0   TBA-5   Management-Privilege-Level (Note 2)

I don't think it makes any sense to allow re-provisioning of the session
transport parameters, as that would almost certainly require a disconnect
and re-establishment of the session.

> Disconnect Messages
> 
>    Request   ACK   NAK   #   Attribute
> 
>       0-1     0     0   TBA-2   Framed-Management-Protocol (Note 1)
>       0-1     0     0   TBA-3   Management-Transport-Protection (Note 1)
>       0       0     0   TBA-4   Management-Policy-Id
>       0       0     0   TBA-5   Management-Privilege-Level
> 
> 
> 
> (Note 1) Where NAS or session identification attributes are included
>    in Disconnect-Request or CoA-Request packets, they are used for
>    identification purposes only.  These attributes MUST NOT be used for
>    purposes other than identification (e.g., within CoA-Request packets
>    to request authorization changes).
> 
> (Note 2) When included within a CoA-Request, these attributes
>    represent an authorization change request.  When one of these
>    attributes is omitted from a CoA-Request, the NAS assumes that the
>    attribute value is to remain unchanged.  Attributes included in a
>    CoA-Request replace all existing values of the same attribute(s).

Similar logic applies to the Disconnect-Request case.  Those attributes
which might aid in distinguishing one of a user's concurrent sessions from
among others may be useful.  The primary indicator here is likely to be the
Service-Type, but that is already permitted by RFC 5176.  We only need to
discuss the newly introduced attributes, in this document.

I'm planning to crate a -04 version of the draft today, to submit prior to
the upcoming "blackout" period on ID submissions.  Now would be a good time
to submit comments on this issue (or any other open issue against -03).  :-)

Delivery-date: Wed, 09 Jul 2008 21:37:08 +0000
Date: Wed, 9 Jul 2008 14:35:42 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: REMINDER:  Call for Agenda Items for IETF 72

Currently the RADEXT WG is scheduled to meet at IETF 72 in Dublin, Ireland 
on Wednesday morning from 9 AM - 11:30 AM on July 30, 2008 in the Conservatory Room. 

This is a call for agenda items for that meeting. If you have an item 
you'd like to put on the agenda, please contact myself 
([email-masked]) or Dave. 

Delivery-date: Wed, 09 Jul 2008 19:54:11 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Additional comments on draft-ietf-radext-management-authorization-03.txt
Date: Wed, 9 Jul 2008 15:52:55 -0400

Following up on an open issue:

> > Section 12
> >
> > Within the document, the CoA-Request is mentioned, but the table
> > does not describe which attributes can be included in CoA or
> > Disconnect Request, ACK or NAK packets.  Is it accurate to assume
> > that none of the attributes defined in this document can be
> > contained in a CoA or Disconnect packet?
> 
> Good question.  I need to think about this for a bit.

I've taken the time to re-read RFC 5176.  It's not entirely clear to me if
and how Dynamic Authorization ought to apply to NAS management.  There's a
clear and straightforward application for Disconnect-Request, to terminate a
management session for administrative reasons.

I'm a little less clear that there is an application for
Change-of-Authorization for management sessions.  One could well imagine
possible, hypothetical use cases, of course.  The question remains whether
there is an actual user requirement to be met.  OTOH, I see no reason to
explicitly prohibit the usage of Dynamic Authorization with NAS Management
Authorization, especially if such usage is entirely optional.

RCF 5176 Section 2.3 (page 9, second to last paragraph) requests that future
documents defining RADIUS attributes specify the nature of their usage in
CoA or Disconnect messages, and whether each attribute can be used as a
session identifier, for session provisioning, or for both.

I will take a stab at that, and hereby solicit WG feedback on the proposal.

Add the following text to Section 12 (as currently numbered):

Change-of-Authorization Messages

   Request   ACK   NAK    #     Attribute

      0       0     0   TBA-2   Framed-Management-Protocol
      0       0     0   TBA-3   Management-Transport-Protection
      0-1     0     0   TBA-4   Management-Policy-Id (Note 2)
      0-1     0     0   TBA-5   Management-Privilege-Level (Note 2)

Disconnect Messages

   Request   ACK   NAK   #   Attribute

      0-1     0     0   TBA-2   Framed-Management-Protocol (Note 1)
      0-1     0     0   TBA-3   Management-Transport-Protection (Note 1)
      0       0     0   TBA-4   Management-Policy-Id
      0       0     0   TBA-5   Management-Privilege-Level

(Note 1) Where NAS or session identification attributes are included
   in Disconnect-Request or CoA-Request packets, they are used for
   identification purposes only.  These attributes MUST NOT be used for
   purposes other than identification (e.g., within CoA-Request packets
   to request authorization changes).

(Note 2) When included within a CoA-Request, these attributes
   represent an authorization change request.  When one of these
   attributes is omitted from a CoA-Request, the NAS assumes that the
   attribute value is to remain unchanged.  Attributes included in a
   CoA-Request replace all existing values of the same attribute(s).

Delivery-date: Wed, 09 Jul 2008 00:14:54 +0000
From: IESG Secretary <[email-masked]>
To: IETF Announcement list <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: WG Action: RECHARTER: RADIUS Extensions Working Group (radext) 
Date: Tue,  8 Jul 2008 17:13:12 -0700 (PDT)

The charter of the RADIUS Extensions Working Group (radext) working group
in the Operations and Management Area of the IETF has been updated.  For 
additional information, please contact the Area Directors or the working 
group Chairs.

RADIUS Extensions Working Group (radext)
----------------------------------------
Last Modified: 2008-05-29

Chair(s):
* Bernard Aboba <[email-masked]>
* David Nelson <[email-masked]>

Operations and Management Area Director(s):
* Dan Romascanu <[email-masked]>
* Ronald Bonica <[email-masked]>

Operations and Management Area Advisor:
* Dan Romascanu <[email-masked]>

Technical Advisor(s):
* Paul Congdon <[email-masked]>

Mailing Lists:
General Discussion: [email-masked]
To Subscribe: [email-masked]
In Body: In Body: subscribe
Archive: https://ops.ietf.org/lists/radiusext

Description of Working Group:

The RADIUS Extensions Working Group will focus on extensions to the
RADIUS protocol required to define extensions to the standard
attribute space as well as to address cryptographic algorithm
agility and use over new transports. In addition, RADEXT will
work on RADIUS Design Guidelines and define new attributes for
particular applications of authentication, authorization and
accounting such as NAS management and local area network (LAN) usage.

In order to enable interoperation of heterogeneous RADIUS/Diameter
deployments, all RADEXT WG work items MUST contain a Diameter
compatibility section, outlining how interoperability with
Diameter will be maintained.

Furthermore, to ensure backward compatibility with existing RADIUS
implementations, as well as compatibility between RADIUS and Diameter,
the following restrictions are imposed on extensions considered by the
RADEXT WG:

- All documents produced MUST specify means of interoperation with
legacy RADIUS and, if possible, be backward
compatible with existing RADIUS RFCs, including RFCs 2865-2869,
3162, 3575, 3579, 3580, 4668-4673,4675, 5080, 5090 and 5176.
Transport profiles should, if possible, be compatible with RFC 3539.

- All RADIUS work MUST be compatible with equivalent facilities in
Diameter. Where possible, new attributes should be defined so that
the same attribute can be used in both RADIUS and Diameter without
translation. In other cases a translation considerations
section should be included in the specification.

Work Items

The immediate goals of the RADEXT working group are to address the
following issues:

- RADIUS design guidelines. This document will provide guidelines for
design of RADIUS attributes. It will specifically consider how
complex data types may be introduced in a robust manner, maintaining
backwards compatibility with existing RADIUS RFCs, across all the
classes of attributes: Standard, Vendor-Specific and SDO-Specific.
In addition, it will review RADIUS data types and associated
backwards compatibility issues.

- RADIUS Management authorization. This document will define the
use of RADIUS for NAS management over IP.

-RADIUS attribute space extension. The standard RADIUS attribute
space is currently being depleted. This document will provide
additional standard attribute space, while maintaining backward
compatibility with existing attributes.

-RADIUS Cryptographic Algorithm Agility. RADIUS has traditionally
relied on MD5 for both per-packet integrity and authentication as well
as attribute confidentiality. Given the increasingly successful
attacks being mounted against MD5, the ability to support
alternative algorithms is required. This work item will
include documentation of RADIUS crypto-agility requirements,
as well as development of one or more Experimental RFCs providing
support for negotiation of alternative cryptographic algorithms
to protect RADIUS.

- IEEE 802 attributes. New attributes have been proposed to
support IEEE 802 standards for wired and wireless LANs. This
work item will support authentication, authorization and
accounting attributes needed by IEEE 802 groups including
IEEE 802.1, IEEE 802.11 and IEEE 802.16.

- New RADIUS transports. A reliable transport profile for
RADIUS will be developed, as well as specifications for
Secure transports, including TCP/TLS (RADSEC) and UDP/DTLS.

- Documentation of Status-Server usage. A document
describing usage of the Status-Server facility will be
developed.

Goals and Milestones:

Jun 2008 RADIUS Design Guidelines submitted as a Best Current Practice
RFC
Jun 2008 RADIUS Management Authorization I-D submitted as a Proposed
Standard RFC
Sep 2008 RADIUS Crypto-agility Requirements submitted as an
Informational RFC
Sep 2008 Extended Attributes I-D submitted as a Proposed Standard RFC
Dec 2008 IEEE 802 Attributes I-D submitted as a Proposed Standard RFC
Jan 2009 Reliable Transport Profile for RADIUS I-D submitted as a
Proposed Standard RFC
Mar 2009 Status-Server I-D submitted as a Proposed Standard RFC
Mar 2009 RADSEC (RADIUS over TCP/TLS) draft submitted as an Experimental
RFC
June 2009 RADIUS over DTLS I-D submitted as an Experimental RFC
June 2009 RADIUS Cryptographic Algorithm Agility I-D submitted as an
Experimental RFC

Delivery-date: Tue, 08 Jul 2008 18:12:14 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Cc: "'Alan DeKok'" <[email-masked]>
Subject: RE: REMINDER: RADEXT WG Last Call on Design Guidelines Document
Date: Tue, 8 Jul 2008 14:11:05 -0400
Organization: Elbrys Networks, Inc.

Alan DeKok writes...

> > (3) Undefined term.
> ...
> > Add a definition of what constitutes "security functionality". 
> > Given that I'm having difficulty in suggesting specific text to 
> > accomplish this, I'm thinking it's not all that obvious.  Do we
> > need to reference "security functionality" at all, or is an 
> > exception for "authentication credentials" sufficient?
> 
>   The Message-Authenticator attribute provides authentication of 
> RADIUS packets that is independent of any user authentication 
> credentials.

OK, so that's not a viable simplification.  I'm still fishing for a
definition of "security functionality", as used in this context, that's less
open-ended than the plain meaning as found in the dictionary.

>   SDOs don't have a problem referencing RADIUS specifications from other
> SDOs.  That's not the issue.  The issue is whether or not everyone
> *else* finds the specifications useful.

>   If SDOs need functionality that is useful to *everyone*, they can
> request standard space allocation.  If SDOs are defining their own
> specifications, they do not need standard space allocation.

How, exactly, do we define "everyone"?

> I'm not sure many SDOs would agree to cede change control over
> their allocations to IANA.  I'm not sure that IANA wants that work,
> either.

Isn't IANA funded to allocate code points to anyone who presents a valid
request, even individuals?

To some extent, I think this is a matter of nomenclature.  If we say that
the RADIUS code space is divided between "standard" space and "Vendor
Specific" space, we effectively lump SDO uses, would could be very broadly
adopted, with proprietary vendor uses, which could have minimal, if any,
deployment.  That's why I've been touting the term SDO Specific Attribute.
True, it uses the Vendor Specific Attribute format (and top-level ID), but
it allows for a distinction between proprietary vendor uses and standardized
uses.  The distinction between "IETF standard" space and "other SDO
standard" space then becomes merely a matter of which registry is used, and
not a matter of "standard" vs. "non-standard".

I'm an engineer but I recognize that sometimes marketing considerations are
important.  :-)

>   How about adding 2.1.6:
> 
>   The extended RADIUS attribute document [EXTEN] defines a number of
>   extensions to RADIUS.  The standard attribute space is extended by
>   permitting standard allocations from within a specific subset of the
>   VSA space; the format of extended attributes is defined; and
>   extended data types are defined within that format.
> 
>   New specifications seeking to extend the standard RADIUS data model
>   SHOULD examine [EXTEN] to see if their needs fit within the extended
>   RADIUS data model.

Yes, I think that would be helpful.

>   We could add the following sentence after the existing bullet points
> that discuss "SDOs or groups of SDOs".
> 
>   Any new RADIUS attributes or values intended for interoperable use
>   across a broad spectrum of the Internet Community SHOULD follow the
>   normal IETF process, and SHOULD result in allocations from the RADIUS
>   standard space.

I think that would also helpful, although the interpretation of "broad"
remains subjective.  I'm not sure ewe can do much better, though.

>   As noted in my response, there are many uses of attributes *outside*
> of SDOs and groups of SDOs.  The text here can be clarified a bit, but I
>  think it's relatively good.
> 
>   How about this text:
> 
>   When attributes are used primarily within a group of SDOs, and are
>   not applicable to the wider Internet community, we expect that one SDO
>   will be responsible for allocation from their own private space.

I guess this OK.   See my discussion, above.

Delivery-date: Tue, 08 Jul 2008 17:23:40 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Cc: "'Bernard Aboba'" <[email-masked]>
Subject: RE: Additional comments on draft-ietf-radext-management-authorization-03.txt
Date: Tue, 8 Jul 2008 13:22:22 -0400
Organization: Elbrys Networks, Inc.

Bernard Aboba writes...

> > > "MAY use these hint attributes" -> "may use these attributes
> > > as a hint"=20
> > OK, but why "MAY" --> "may"?
>=A0
> Hints are inherently optional.

Well, quoting RFC 2119:

   MAY   This word, or the adjective "OPTIONAL", mean that an
   item is truly optional.

Since MAY means "truly optional", which I can't distinguish from =
"inherently
optional", I'm proposing to leave the text as is.  :-)

Delivery-date: Tue, 08 Jul 2008 13:22:52 +0000
Date: Tue, 08 Jul 2008 15:20:55 +0200
From: Alan DeKok <[email-masked]>
To: "David B. Nelson" <[email-masked]>
CC: [email-masked]
Subject: Re: REMINDER: RADEXT WG Last Call on Design Guidelines Document

David B. Nelson wrote:
> My review comments on the -04 version as are follows:
> 
> (1) Short-lived reference.
...
> The RADEXT WG mailing list is a relatively short-lived entity.  We hope the
> WG completes its charter and closes one of these days.  :-)  This text
> provides no guidance to the reader as to how to determine what constitutes
> an "equivalent" IETF mailing list.

  The introduction references the AAA doctors list.  A similar reference
should be added here.

> Requested change:
> 
> * Reviews of specifications are posted to the RADEXT WG mailing list or
> another IETF mailing list suggested by the Operations & Management Area
> Directors of the IETF;

  I think that referencing the AAA doctors list would be useful, too.

> (2) Misplaced modifier.
...
> Requested change:

  OK.

> (3) Undefined term.
...
> Add a definition of what constitutes "security functionality".  Given that
> I'm having difficulty in suggesting specific text to accomplish this, I'm
> thinking it's not all that obvious.  Do we need to reference "security
> functionality" at all, or is an exception for "authentication credentials"
> sufficient?

  The Message-Authenticator attribute provides authentication of RADIUS
packets that is independent of any user authentication credentials.

> (4) Needlessly IETF-centric viewpoint.
..
> This leads me to believe that the authors think that other (non-IETF) SDOs
> (or worse yet, groups of SDOs) are unlikely to define attributes that are
> useful to the broad Internet Community.

  SDOs don't have a problem referencing RADIUS specifications from other
SDOs.  That's not the issue.  The issue is whether or not everyone
*else* finds the specifications useful.

  e.g. 3GPP2 defines a number of RADIUS attributes.  I haven't seen them
implemented in a Wifi hotspot or in a low-end Wifi home router... and I
don't expect to see them there.  As such, the 3GPP2 specifications
belong in the SDO space, and not in the IETF space.

>  That may or may not be true.  I'm
> guessing that what this really means is that only the IETF ought to be
> consuming standard RADIUS attribute IDs, based on IANA allocation, and all
> other bodies need to host attributes in a private code-point space (i.e. the
> assigned VSA block).  Does this document intend to Update RFC 3575?

  Yes (to the first sentence), and no (to the second).  Pointing out
that IETF and IANA are responsible for standard-space allocations isn't
an update to IETF processes.  It's a re-iteration that vendors and SDOs
SHOULD NOT stomp on the IETF space for vendor-specific, or SDO-specific
allocations.

> I think the conditional phrase "for attributes matching any of the following
> criteria" will almost always evaluate to TRUE because of the second and
> third bullet items, so the whole paragraph makes little sense to me.

  If SDOs need functionality that is useful to *everyone*, they can
request standard space allocation.  If SDOs are defining their own
specifications, they do not need standard space allocation.

> If the issue is standard attribute scarcity, isn't this addressed by the
> RADIUS Extended Attribute format [EXTEN]?

  No.  While the guidelines document was started when [EXTEN] had 8-bit
attributes, the issue isn't attribute scarcity.  The issue as I see it
is requesting "standard" space allocation for SDO-specific
functionality.  I'm not sure many SDOs would agree to cede change
control over their allocations to IANA.  I'm not sure that IANA wants
that work, either.

> I think that this document should provide better guidance as to when an IANA
> allocation from the standard RADIUS Attribute code-point space is
> appropriate.  Does the need for interoperability between multiple SDOs meet
> that threshold? 

  I don't think so.  WiMAX is referencing 3GPP attributes.  There's no
need to re-host the 3GPP attributes in the IETF standard space just
because another SDO decides to reference them.

> Or must the usage be of general applicability to the
> Internet Community?

  Yes.  And it should be *new* functionality.

>  How does the existence of the Extended RADIUS Attribute
> (a VSA with a code-point block assigned to the IETF) change the distinction
> between "standard" and "VSA" allocations?

  How about adding 2.1.6:

  The extended RADIUS attribute document [EXTEN] defines a number of
  extensions to RADIUS.  The standard attribute space is extended by
  permitting standard allocations from within a specific subset of the
  VSA space; the format of extended attributes is defined; and
  extended data types are defined within that format.

  New specifications seeking to extend the standard RADIUS data model
  SHOULD examine [EXTEN] to see if their needs fit within the extended
  RADIUS data model.

> Requested change:

  We could add the following sentence after the existing bullet points
that discuss "SDOs or groups of SDOs".

  Any new RADIUS attributes or values intended for interoperable use
  across a broad spectrum of the Internet Community SHOULD follow the
  normal IETF process, and SHOULD result in allocations from the RADIUS
  standard space.

> (5) Format issues.

  Fixed.

> (6) Bad reference.

  Fixed.

> (7) Missing definition/reference.
...
> Where do we normatively define the term "extended data types"?

  I would suggest in a new section, 2.1.6, as shown above.

> (8) Duplicate section title.
...
> Both of these sections are entitled "Complex data types".  One of them is
> permissive and the other prohibitive.

  The first talks about Opaque data types being OK.  I've changed the
title to "Opaque data types".  The second is about Complex data types in
RADIUS being NOT RECOMMENDED.

> (9) Confusion over allocation policy.
...
> As discussed in comment (4), above, attributes intended for interoperable
> use across multiple SDOs *could* qualify for allocation from the standard
> RADIUS attribute space, or from the Extended RADIUS Attribute (IETF/SDO)
> space.

  As noted in my response, there are many uses of attributes *outside*
of SDOs and groups of SDOs.  The text here can be clarified a bit, but I
 think it's relatively good.

  How about this text:

  When attributes are used primarily withing a group of SDOs, and are
  not applicable to the wider Internet community, we expect that one SDO
  will be responsible for allocation from their own private space.

  Alan DeKok.

Delivery-date: Mon, 07 Jul 2008 21:46:35 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-radext-extended-attributes-04.txt 
Date: Mon,  7 Jul 2008 14:45:01 -0700 (PDT)

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the RADIUS EXTensions Working Group of the IETF.

	Title		: Extended Remote Authentication Dial In User Service (RADIUS) Attributes
	Author(s)	: Y. Li, A. Lior, G. Zorn
	Filename	: draft-ietf-radext-extended-attributes-04.txt
	Pages		: 13
	Date		: 2008-7-7
	
For the Remote Authentication Dial In User Service (RADIUS) protocol
   to continue to support new applications the RADIUS attribute type
   space must be extended beyond the current limit of 255 possible
   attribute types while maintaining backwards compatibility with the
   existing protocol.  This document defines a mechanism to accomplish
   that task, along with standard methods to group together related
attributes and to encode values that don't fit into 253 octets.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-attributes-04.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-radext-extended-attributes-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--NextPart--

Delivery-date: Mon, 07 Jul 2008 19:13:35 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Cc: "'Bernard Aboba'" <[email-masked]>
Subject: RE: Additional comments on draft-ietf-radext-management-authorization-03.txt
Date: Mon, 7 Jul 2008 15:12:33 -0400
Organization: Elbrys Networks, Inc.

Bernard Aboba writes...

> Section 8.1
> 
> "Service-Type of Framed-Management" -> "Service-Type Attribute
> with the value Framed-Management"

OK.
 
> "in Access-Request packet" -> "in an Access-Request packet"

OK.

> "MAY use these hint attributes" -> "may use these attributes as a hint"

OK, but why "MAY" --> "may"?

> "MUST treat the response" -> "MUST treat the Access-Accept"

OK.

Reference issues have been previously discussed.

> Section 8.2
> 
>    The Management-Transport-Protection Attribute specifies whether a
>    secure transport protocol (e.g.  SSH, TLS, DTLS, etc.) is required
>    for use with the associated framed or non-framed management access
>    session.  The value of this attribute specifies the minimum level of
>    protection that is required from the protected transport.  The
>    protected transport MAY provide a greater level of protection than is
>    called for by the value of Management-Transport-Protection.
> 
> [BA] The second sentence is more on target.  How about this?
> 
>    The Management-Transport-Protection Attribute specifies the minimum
>    level of protection that is required for a protected transport used
>    with the framed or non-framed management access session.  The protected
>    transport used by the NAS MAY provide a greater level of protection,
>    but MUST NOT provide a lower level of protection.

OK.
 
> "in Access-Request packet" -> "in an Access-Request packet"
> "RADIUS Client" -> "RADIUS client"
> "RADIUS Server" -> "RADIUS server"
> "MAY use this hint attribute" -> "may use this attribute as a hint"

OK, but same question on "MAY"...

> Section 8.3
> 
> "application to SMNP services" -> "SNMP"
> "NAS behavior in such cases is not predictable." -> "The behavior of the
> NAS in this case is undefined."
> "a single service provisioning message, such as" -> "an Access-Accept or
> CoA-Request".

All OK.

> ", within a flat namespace of significance to the NAS"
> 
> [BA] Are you saying that "." can't be used?  Can this be deleted?

Eh?  By "flat", I mean a monolithic name that can be searched by a
non-structured text comparison (e.g. strcasecmp()).  This is effectively a
prohibition on sub-fields within the name text that a client or server would
need to take special heed of.  You can include ".", but it has no more
significance than any other character.

> "Overloading or subdividing this flat name with" ->
> "Overloading or subdividing this attribute with"

Hmm.  Module the resolution of the "flatness" issue, above, this might be
OK.

> "If a simple flat policy name" -> "If a simple policy name"
> "sufficient to the anticipated use case" -> "sufficient"

Ditto.
 
> Section 12
> 
> Within the document, the CoA-Request is mentioned, but the table
> does not describe which attributes can be included in CoA or
> Disconnect Request, ACK or NAK packets.  Is it accurate to assume
> that none of the attributes defined in this document can be 
> contained in a CoA or Disconnect packet?

Good question.  I need to think about this for a bit.

> Section 14
> 
>    Any of the attributes described in this memo, with the exception of
>    Service-Type, may not be understood by the NAS which receives it.  A
>    legacy NAS not compliant with this specification may silently discard
>    these attributes while permitting the user to access the management
>    interface(s) of the NAS.  This can lead to users improperly receiving
>    unauthorized management access to the NAS, or access with greater
>    levels of access rights than were intended.  RADIUS servers SHOULD
>    attempt to ascertain whether or not the NAS supports these attributes
>    before sending them in an Access-Accept.
> 
> [BA] This paragraph could be more clear.  There are really two cases.
> When a Service-Type value of Framed-Management is used, I'd assume 
> that a NAS implementing this specification would be required to behave
> as specified (e.g. treat the Access-Accept as an Access-Reject if the
> attribute or value wasn't supported).

Right.  Service-Type is the one implicitly "mandatory" (as in the Diameter
Mandatory bit) attribute in RADIUS.

Can we assume that if the NAS supports a value of Framed-Management for the
Service-Type attribute that it also at least *recognizes* all the other
Framed Management related attributes in this document, even though it may
not support those services?  Or is that expecting too much?

> I think that an issue could occur when a legacy Service-Type value
> is used though, since then the NAS might ignore the new attributes 
> instead of treating the Access-Accept like an Access-Reject.

Um, yeah.

> I don't think you need to talk about the potential behavior of an
> implementation that claims to conform to the spec, but doesn't do 
> what it says.

:-)

How about:

  A legacy NAS may not recognize the attributes in this document
  that supplement the provisioning of CLI management access.  If
  the value of the Service Type Attribute is NAS-Prompt or 
  Administrative, the legacy NAS may silently discard such 
  attributes, while permitting the user to access the CLI
  management interface(s) of the NAS.  This can lead to users
  improperly receiving unauthorized management access to the NAS,
  or access with greater levels of access rights than were intended.
  RADIUS servers SHOULD attempt to ascertain whether or not the
  NAS supports these attributes before sending them in an 
  Access-Accept provisioning CLI access.

Delivery-date: Mon, 07 Jul 2008 18:31:15 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Cc: "'Bernard Aboba'" <[email-masked]>
Subject: RE: Editorial review of draft-ietf-radext-management-authorization-03.txt
Date: Mon, 7 Jul 2008 14:30:14 -0400
Organization: Elbrys Networks, Inc.

Bernard Aboba writes...
 
> Abstract
> 
>    This document describes Remote Authentication Dial-In User Service
>    (RADIUS) attributes for the authorization and service provisioning of
>    Network Access Servers (NASes).  Both local and remote management are
>    supported, with granular access rights and management privileges.
>    Specific provisions are made for remote management via framed
>    management protocols, and for specification of a protected transport
>    protocol.
> 
> [BA] This document is about NAS management authorization, not
> authorization of NASes.  Suggest the following:
> 
>    This document specifies Remote Authentication Dial-In User Service
>    (RADIUS) attributes for Network Access Server (NAS) management.
>    Both local and remote management are
>    supported, with granular access rights and management privileges.
>    Specific provisions are made for remote management via framed
>    management protocols, which may run over a secure transport
>    protocol.

Yeah, something went awry in the editing.  How about:

  This document specifies Remote Authentication Dial-In User Service
  (RADIUS) attributes for authorizing management access to a Network 
  Access Server (NAS).  Both local and remote management are supported,
  with granular access rights and management privileges.  Specific
  provisions are made for remote management via framed management
  protocols, which may run over a secure transport protocol.
 
> 2. Introduction and Rationale
> 
> [BA] How about combining Sections 2, part of 3 and 6 into a Section 1 that
> reads as follows?  The Terminology section can then be Section 1.1.
> 
> 1. Introduction
> 
>    RFC 2865 [RFC 2865] defines the NAS-Prompt and Administrative values of
>    the Service-Type Attribute.   Both of these values provide access to
>    the interactive, text-based Command Line Interface (CLI) of the NAS,
>    and were originally developed to control access to the physical
>    console port of the NAS, most often a serial port.
> 
>    Remote access to the CLI of the NAS has been available in NAS
>    implementations for many years, using protocols such as Telnet,
>    Rlogin and the remote terminal service of SSH.  In order to distinguish
>    local, physical, console access from remote access, the NAS-Port-Type
>    Attribute is generally included in Access-Request and Access-Accept
>    messages, along with the Service-Type Attribute, to indicate the form
>    of access.  A NAS-Port-Type of Async (0) is used to signify a local
>    serial port connection, while a value of Virtual (5) is used to
>    signify a remote connection, via a remote terminal protocol.  This
>    usage provides no selectivity among the various available remote
>    terminal protocols (e.g.  Telnet, Rlogin, SSH, etc.).

OK with me.

>    Today, it is common for network devices to support more than two
>    privilege levels for management access than just NAS-Prompt
>    (non-privileged) and Administrative (privileged).  Also, other
>    management mechanisms may be used, such as Web-based management,
>    Simple Network Management Protocol (SNMP) and NETCONF.
>    To provide support for these additional features, this specification
>    defines attributes for framed management protocols, management protocol
>    security, and management access privilege levels.

Looks OK to me, with minor grammatical tweaking.  How about:

  Today, it is common for network devices to support more than the two
  privilege levels for management access provided by NAS-Prompt
  (non-privileged) and Administrative (privileged).

>    Remote management via the command line is carried over protocols
>    such as Telnet, Rlogin and the remote terminal service of SSH.  Since
>    these protocols are primarily for the delivery of terminal or
>    pseudo-TTY services,  the term "Framed Management" is used to describe
>    management protocols supporting techniques other than the command-line.
>    Typically these mechanisms format management information in a binary or
>    textual encoding such as HTML, XML or ASN.1/BER.  Examples include
>    web-based management (HTML over HTTP or HTTPS), NETCONF (XML over
>    SSH/BEEP/SOAP) and SNMP (SMI over ASN.1/BER).  Command line
>    interface, menu interface or other text-based (e.g. ASCII or UTF-8)
>    terminal emulation services are not considered to be Framed Management
>    protocols.

OK with me.

> [BA] How about combining part of Section 3, as well as 4, 5 and 6 into
> a Section 2 that reads as follows?
> 
> 2. Overview
> 
>    To support the authorization and provisioning of Framed Management
>    access to managed entities, this document introduces a new value for
>    the Service-Type Attribute [RFC2865], and one new attribute.  The new
>    value for the Service-Type Attribute is Framed-Management, used for
>    remote device management via a Framed Management Protocol.  The new
>    attribute is Framed-Management-Protocol, the value of which specifies a
>    particular protocol for use in the remote management session.
> 
>    Two new attributes are introduced in this document in support of
>    granular management access rights or command privilege levels.
>    The Management-Policy-Id Attribute provides a text string
>    specifying  a policy name of local scope, that is assumed to have
>    been pre-provisioned on the NAS.  This use of an attribute to
>    specify use of a pre-provisioned policy is similar to
>    the Filter-Id Attribute defined in [RFC2865] Section 5.11.
> 
>    The local application of the Management-Policy-Id within the managed
>    entity may take the form of (a) one of an enumeration of command
>    privilege levels, (b) a mapping into an SNMP Access Control Model,
>    such as the View Based Access Control Model (VACM) [RFC3415], or (c)
>    some other set of management access policy rules that is mutually
>    understood by the managed entity and the remote management
>    application.  Examples are given in Section X.
> 
>    The Management-Privilege-Level Attribute contains an
>    integer-valued management privilege level indication.  This attribute
>    serves to modify or augment the management permissions provided by
>    the NAS-Prompt value of the Service-Type Attribute, and thus applies to
>    CLI management.
> 
>    To enable management security requirements to be specified, the
>    Management-Transport-Protection Attribute is introduced.  The value
>    of this attribute indicates the minimum level of secure transport
>    protocol protection required for the provisioning of NAS-Prompt,
>    Administrative or Framed-Management service.

This looks, OK, too.

Obviously we need to see the edited version, in context, but I don't see any
loss of information in this condensed version.

Delivery-date: Mon, 07 Jul 2008 18:01:18 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: REMINDER: RADEXT WG Last Call on Design Guidelines Document
Date: Mon, 7 Jul 2008 13:59:30 -0400
Organization: Elbrys Networks, Inc.

My review comments on the -04 version as are follows:

(1) Short-lived reference.

Submitter name: Dave Nelson
Submitter email address: [email-masked]
Date first submitted: July 7, 2008
Document: draft-ietf-radext-design-04.txt
Comment type: Technical
Priority: '1' Should fix 
Section: 1.1
Rationale/Explanation of issue:

* Reviews of specifications are posted to the RADEXT WG or
equivalent IETF mailing list;

The RADEXT WG mailing list is a relatively short-lived entity.  We hope the
WG completes its charter and closes one of these days.  :-)  This text
provides no guidance to the reader as to how to determine what constitutes
an "equivalent" IETF mailing list.

Requested change:

* Reviews of specifications are posted to the RADEXT WG mailing list or
another IETF mailing list suggested by the Operations & Management Area
Directors of the IETF;

(2) Misplaced modifier.

Submitter name: Dave Nelson
Submitter email address: [email-masked]
Date first submitted: July 7, 2008
Document: draft-ietf-radext-design-04.txt
Comment type: Editorial
Priority: '1' Should fix 
Section: 1.1
Rationale/Explanation of issue:

   RADIUS protocol changes, or specification of attributes that
   can be used to, in effect, provide new RADIUS commands (such as
   Service-Type) require greater expertise and deeper review, as
   do changes to the RADIUS operational model, as described in
   Section 3.3.

Service-Type is an attribute, not a command.

Requested change:

   RADIUS protocol changes, or specification of attributes (such
   as Service-Type) that can be used to, in effect, provide new
   RADIUS commands, require greater expertise and deeper review,
   As do changes to the RADIUS operational model, as described in
   Section 3.3.

(3) Undefined term.

Submitter name: Dave Nelson
Submitter email address: [email-masked]
Date first submitted: July 7, 2008
Document: draft-ietf-radext-design-04.txt
Comment type: Technical
Priority: '1' Should fix 
Section: 2.1.3
Rationale/Explanation of issue:

   As a result, the introduction of new complex data types
   within RADIUS attribute specifications SHOULD be avoided,
   except in the case of complex attributes involving authentication
   or security functionality.

"Security functionality" is a term that could be assigned a fairly broad
range of possible meanings.  Well intentioned RADIUS Attribute designers
might think this applies to any attribute that they wish to remain "secure"
or which has security implications for their product, e.g. important service
provisioning parameters.  While the term is defined by various examples in
Appendix B, I think a better "normative" definition is required here.

Requested change:

Add a definition of what constitutes "security functionality".  Given that
I'm having difficulty in suggesting specific text to accomplish this, I'm
thinking it's not all that obvious.  Do we need to reference "security
functionality" at all, or is an exception for "authentication credentials"
sufficient?

(4) Needlessly IETF-centric viewpoint.

Submitter name: Dave Nelson
Submitter email address: [email-masked]
Date first submitted: July 7, 2008
Document: draft-ietf-radext-design-04.txt
Comment type: Technical
Priority: '1' Should fix 
Section: 3.1.3
Rationale/Explanation of issue:

  SDO RADIUS Attribute specifications SHOULD allocate attributes from
  the vendor space, rather than requesting an allocation from the
  RADIUS standard attribute space, for attributes matching any of the
  following criteria:

   * attributes relying on data types not defined within RADIUS
   * attributes intended primarily for use within an SDO
   * attributes intended primarily for use within a group of SDOs.

This leads me to believe that the authors think that other (non-IETF) SDOs
(or worse yet, groups of SDOs) are unlikely to define attributes that are
useful to the broad Internet Community.  That may or may not be true.  I'm
guessing that what this really means is that only the IETF ought to be
consuming standard RADIUS attribute IDs, based on IANA allocation, and all
other bodies need to host attributes in a private code-point space (i.e. the
assigned VSA block).  Does this document intend to Update RFC 3575?

I think the conditional phrase "for attributes matching any of the following
criteria" will almost always evaluate to TRUE because of the second and
third bullet items, so the whole paragraph makes little sense to me.

If the issue is standard attribute scarcity, isn't this addressed by the
RADIUS Extended Attribute format [EXTEN]?

I think that this document should provide better guidance as to when an IANA
allocation from the standard RADIUS Attribute code-point space is
appropriate.  Does the need for interoperability between multiple SDOs meet
that threshold?  Or must the usage be of general applicability to the
Internet Community?  How does the existence of the Extended RADIUS Attribute
(a VSA with a code-point block assigned to the IETF) change the distinction
between "standard" and "VSA" allocations?

Requested change:

  SDO RADIUS Attribute specifications SHOULD allocate attributes from
  the vendor space, rather than requesting an allocation from the
  RADIUS standard attribute space, unless the attributes match any of the
  following criteria:

   * attributes intended for interoperable use across multiple SDOs.
   * attributes intended for interoperable use across a broad spectrum 
     of the Internet Community.

(5) Format issues.

Submitter name: Dave Nelson
Submitter email address: [email-masked]
Date first submitted: July 7, 2008
Document: draft-ietf-radext-design-04.txt
Comment type: Editorial
Priority: '1' Should fix 
Section: 3.3
Rationale/Explanation of issue:

      * The RADIUS protocol is stateless; * Provisioning of services is
      not possible within an Access-Reject; * Distinction between
      authorization checks and user authentication; * Authentication and
      integrity protection of RADIUS packets; * The RADIUS protocol is a
      Request/Response protocol.

Bulleted list not well formatted.

Requested change:

  * The RADIUS protocol is stateless;
  * Provisioning of services is not possible within an Access-Reject;
  * Distinction between authorization checks and user authentication;
  * Authentication and integrity protection of RADIUS packets;
  * The RADIUS protocol is a Request/Response protocol.

(6) Bad reference.

Submitter name: Dave Nelson
Submitter email address: [email-masked]
Date first submitted: July 7, 2008
Document: draft-ietf-radext-design-04.txt
Comment type: Editorial
Priority: '1' Should fix 
Section: A.1.2
Rationale/Explanation of issue:

A.1.2. Extended data types

   Where possible, the data types defined above in Section A.1.2 SHOULD
   be used.  The extended data types SHOULD be used only where there is
   no clear method of expressing the data using existing types.

Requested change:

A.1.2. Extended data types

   Where possible, the data types defined above in Section A.1.1 SHOULD
   be used.  The extended data types SHOULD be used only where there is
   no clear method of expressing the data using existing types.

A.1.2 --> A.1.1

(7) Missing definition/reference.

Submitter name: Dave Nelson
Submitter email address: [email-masked]
Date first submitted: July 7, 2008
Document: draft-ietf-radext-design-04.txt
Comment type: Editorial
Priority: '1' Should fix 
Section: A.1.2
Rationale/Explanation of issue:

A.1.2. Extended data types

   Where possible, the data types defined above in Section A.1.2 SHOULD
   be used.  The extended data types SHOULD be used only where there is
   no clear method of expressing the data using existing types.

Where do we normatively define the term "extended data types"?

Requested change:

Add a definition, or a reference to a definition.  Does this, in fact, mean
the RADIUS Attribute format defined in [EXTEN]?

A.1.2. Extended data types

   Where possible, the data types defined above in Section A.1.2 SHOULD
   be used.  The extended data types [EXTEN] SHOULD be used only where 
   there is no clear method of expressing the data using existing types.

(8) Duplicate section title.

Submitter name: Dave Nelson
Submitter email address: [email-masked]
Date first submitted: July 7, 2008
Document: draft-ietf-radext-design-04.txt
Comment type: Editorial
Priority: '1' Should fix 
Section: A.1.3, A.2.2
Rationale/Explanation of issue:

Both of these sections are entitled "Complex data types".  One of them is
permissive and the other prohibitive.

Requested change:

Clarify the subject of each of these sections in its title.

(9) Confusion over allocation policy.

Submitter name: Dave Nelson
Submitter email address: [email-masked]
Date first submitted: July 7, 2008
Document: draft-ietf-radext-design-04.txt
Comment type: Technical
Priority: '1' Should fix 
Section: A.5
Rationale/Explanation of issue:

A.5. Allocation of attributes

   Does the attribute have a limited scope of applicability, as outlined
   below?  If so, then the attributes SHOULD be allocated from the
   Vendor-Specific space.

      * attributes intended for a vendor to support their own systems,
      and not suitable for general usage
      * attributes relying on data types not defined within RADIUS
      * attributes intended primarily for use within an SDO
      * attributes intended primarily for use within a group of SDOs.

As discussed in comment (4), above, attributes intended for interoperable
use across multiple SDOs *could* qualify for allocation from the standard
RADIUS attribute space, or from the Extended RADIUS Attribute (IETF/SDO)
space.

Requested change:

A.5. Allocation of attributes

   Does the attribute have a limited scope of applicability, as outlined
   below?  If so, then the attributes SHOULD be allocated from the
   Vendor-Specific space.

      * attributes intended for a vendor to support their own systems,
      and not suitable for general usage
      * attributes relying on data types not defined within RADIUS
      * attributes intended for use within an single SDO

Delivery-date: Mon, 07 Jul 2008 12:46:31 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-radext-design-04.txt 
Date: Mon,  7 Jul 2008 05:45:01 -0700 (PDT)

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the RADIUS EXTensions Working Group of the IETF.

	Title           : RADIUS Design Guidelines
	Author(s)       : G. Weber, et al.
	Filename        : draft-ietf-radext-design-04.txt
	Pages           : 34
	Date            : 2008-07-07

This document provides guidelines for the design of attributes used
by the Remote Authentication Dial In User Service (RADIUS) protocol.
It is expected that these guidelines will prove useful to authors and
reviewers of future RADIUS attribute specifications, both within the
IETF as well as other Standards Development Organizations (SDOs).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-design-04.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-radext-design-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[email-masked]>

--NextPart--

Delivery-date: Mon, 07 Jul 2008 12:35:14 +0000
Date: Mon, 07 Jul 2008 14:32:52 +0200
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: [email-masked]
Subject: Re: Review of draft-ietf-radext-design-03.txt

Bernard Aboba wrote:
...

  I've just submitted -04, which incorporates this review.

  Alan DeKok.

Delivery-date: Sat, 05 Jul 2008 19:01:42 +0000
Date: Sat, 5 Jul 2008 11:59:25 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: REMINDER: RADEXT WG Last Call on Design Guidelines Document

This is a reminder of the ongoing RADEXT WG Last Call on "RADIUS Design 
Guidelines" prior to requesting that the IESG publish it as a Best
Current Practice RFC. 
 
The document is available here:
http://www.ietf.org/internet-drafts/draft-ietf-radext-design-03.txt
 
WG Last Call will last until July 10, 2008.   Please review the document 
and post your comments to the RADEXT WG mailing list 
([email-masked]) in the format described on the RADEXT WG Issues 
list (http://www.drizzle.com/~aboba/RADEXT/).   
 
If you have read the document and approve of its publication, but have no
comments, please also post this to the list. 

Delivery-date: Thu, 03 Jul 2008 12:21:01 +0000
Date: Thu, 03 Jul 2008 14:19:58 +0200
From: Alan DeKok <[email-masked]>
To: Stefan Winter <[email-masked]>
CC: [email-masked]
Subject: Re: TCP transport draft

Stefan Winter wrote:
> some small glitches:

  Fixed, thanks.

> Should there be some more TCP usage profile guidelines in it, like
> recommending TCP PSH when a RADIUS message is complete,

  There's no socket API to do that, so far as I know.  The closest thing
is that the kernel *usually* will send the data if it's written by
write() or send(), as one call.

> or should it
> remain at the sentence "We RECOMMEND that implementors of this
> ~   specification familiarize themselves with TCP application programming
> ~   concepts." IMHO, a little more handholding wouldn't hurt.

  I think that this document isn't the place to get into programming
guidelines.  If people want to know about TCP application programming,
there are books && lots of source available.  This document should
concentrate on RADIUS && TCP interaction issues.

  Alan DeKok.

Delivery-date: Thu, 03 Jul 2008 12:14:18 +0000
Date: Thu, 03 Jul 2008 14:13:02 +0200
From: Stefan Winter <[email-masked]>
To: Alan DeKok <[email-masked]>, [email-masked]
Subject: Re: TCP transport draft

Hi,

some small glitches:

2.2.  TCP Ports

~   IANA has already assigned TCP ports for RADIUS transport, as outlined
~   below:

~      * radius          1812/udp
~      * radius-acct     1813/tcp
~      * radius-dynauth  3799/tcp

1812/tcp.

2.6.3

~      * Packet from an unknown client (using the key as defined above)
~      * Packet with an invalid code field
~      * Packet that is less than the minimim RADIUS packet length
~      * Packet that is more than the minimim RADIUS packet length

more than the maximum.

Should there be some more TCP usage profile guidelines in it, like
recommending TCP PSH when a RADIUS message is complete, or should it
remain at the sentence "We RECOMMEND that implementors of this
~   specification familiarize themselves with TCP application programming
~   concepts." IMHO, a little more handholding wouldn't hurt.

Greetings,

Stefan Winter

- --
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

Delivery-date: Thu, 03 Jul 2008 10:36:39 +0000
Date: Thu, 03 Jul 2008 12:34:46 +0200
From: Alan DeKok <[email-masked]>
To: 'radext mailing list' <[email-masked]>
Subject: TCP transport draft

  I've just submitted a draft describing TCP as a transport for RADIUS.
 Much of the text re-iterates existing specifications, and says that
nothing has changed.

  A few TCP-specific issues are noted.

http://www.ietf.org/internet-drafts/draft-dekok-radext-tcp-transport-00.txt

  Alan DeKok.

Delivery-date: Tue, 01 Jul 2008 14:18:57 +0000
Date: Tue, 1 Jul 2008 07:17:29 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Review of draft-ietf-radext-design-03.txt

Section 1.1

Suggest chasnging:

"  The advice in this document applies to attributes used to encode
   service-provisioning or authentication data.  RADIUS protocol
   changes, or specification of attributes that can be used to, in
   effect, provide new RADIUS commands (such as Service-Type) are out of
   scope.  Since protocol changes require greater expertise and deeper
   review, such changes should not be undertaken outside the IETF and
   when handled within the IETF require "IETF Consensus" for adoption,
   as noted in [RFC3575] Section 2.1.

   As with protocol changes, this document does not provide guidance to
   document authors seeking to change the RADIUS operational model.
   While RADIUS server implementations may keep state, the RADIUS
   protocol is stateless, although information may be passed from one
   protocol transaction to another via the State Attribute.  As a
   result, documents which require stateful protocol behavior without
   use of the State Attribute are inherently incompatible with RADIUS as
   defined in [RFC2865], and need to be redesigned.

   See [RFC5080] Section 2.1.1 for a more in-depth discussion of the use
   of the State Attribute."

To:

"  The advice in this document applies to attributes used to encode
   service-provisioning or authentication data.  RADIUS protocol
   changes, or specification of attributes that can be used to, in
   effect, provide new RADIUS commands (such as Service-Type) require
   greater expertise and deeper review, as do changes to the RADIUS
   operational model, as described in Section 3.3. Such changes should 
   not be undertaken outside the IETF and when handled within the IETF 
   require "IETF Consensus" for adoption, as noted in "IANA Considerations 
   for RADIUS" [RFC3575] Section 2.1."

Add Section 3.3: 

"  3.3 RADIUS Operational Model

   The RADIUS operational model includes several assumptions:

     * The RADIUS protocol is stateless; 
     * Provisioning of services is not possible within an Access-Reject; 
     * Distinction between authorization checks and user authentication; 
     * Authentication and integrity protection of RADIUS packets; 
     * The RADIUS protocol is a Request/Response protocol; 

   While RADIUS server implementations may keep state, the RADIUS  
   protocol is stateless, although information may be passed from one
   protocol transaction to another via the State Attribute.  As a
   result, documents which require stateful protocol behavior without
   use of the State Attribute are inherently incompatible with RADIUS as
   defined in [RFC2865], and need to be redesigned.  See "Common
   RADIUS Implementation Issues and Suggested Fixes" [RFC5080] 
   Section 2.1.1 for a more in-depth discussion of the use
   of the State Attribute.

   As noted in [RFC5080] Section 2.6, the intent of an Access-Reject is
   to deny access to the requested service.  As a result, RADIUS does
   not allow the provisioning of services within an Access-Reject. 
   As a result, documents which include provisioning of services
   within an Access-Reject are inherently incompatible with RADIUS
   and need to be redesigned.

   As noted in [RFC5080] Section 2.1.1, a RADIUS Access-Request
   may not contain user authentication attributes or a State
   Attribute linking the Access-Request to an earlier user
   authentication.  Such an Access-Request, known as an 
   authorization check, provides no assurance that it 
   corresponds to a live user.  RADIUS specifications
   defining attributes containing confidential information
   (such as Tunnel-Password) should be careful to prohibit
   such attributes from being returned in response to an
   authorization check.  Also, [RFC5080] Section 2.1.1 notes that 
   authentication mechanisms need to tie a sequence of 
   Access-Request/Access-Challenge packets together into one 
   authentication session.  The State Attribute is RECOMMENDED
   for this purpose. 

   While [RFC2865] did not require authentication and integrity
   protection of RADIUS Access-Request packets, subsequent
   authentication mechanism specifications such as RADIUS/EAP
   [RFC3579] and Digest Authentication [RFC5090] have mandated
   authentication and integrity protection for all
   RADIUS packets.  It is expected that specifications for new
   RADIUS authentication mechanisms will continue this practice.
   As noted in [RFC5080] Section 2.1.1, integrity protection 
   should also be extended to Access-Request packets performing
   authorization checks.

   The RADIUS protocol as defined in [RFC2865] is a request-response
   protocol spoken between RADIUS clients and servers.  A single 
   RADIUS Access-Request packet will solicit in response at most a single 
   Access-Accept, Access-Reject or Access-Challenge packet, sent to the IP 
   address of the RADIUS Client that sent the original Access-Request.  
   Similarly, a single Change-of-Authorization (CoA)-Request packet
   will solicit in response at most a single CoA-ACK or CoA-NAK packet,
   sent to the IP address of the Dynamic Authorization Client (DAC)
   that sent the original CoA-Request. A single Disconnect-Request packet
   will solicit in response at most a single Disconnect-ACK or 
   Disconnect-NAK packet, sent to the IP address of the Dynamic 
   Authorization Client (DAC) that sent the original CoA-Request."

NITs:

Section 1

"such an "Expert Review"" -> "such as an "Expert Review""

Section 1.1

"In order enable" -> "In order to enable"

Prior to the first recommendation, insert:

"Encouraging SDOs to request review of RADIUS attribute specifications by 
sending email to the AAA Doctors or equivalent mailing list;"

"Development of a program to encourage SDOs to make" -> "SDOs to make"

"proposed in this document;" -> "proposed in this document, with reviews
posted to the RADEXT WG or equivalent IETF mailing list;" 

Section 2.1.1

"most significant octet first" -> "in network byte order"

"this usage is NOT RECOMMENDED" -> "this usage is NOT 
RECOMMENDED."

Section 2.1.3

"complex structures" -> "complex structures;"
"well-known types" -> "well-known types;"

"implement a new attribute, as the" -> "implement a new attribute. The"

"to send a new attribute" -> "to send a new static attribute"
"dictionary and policy management" -> "dictionary" 

"required in the RADIUS server's" -> "required in the policy management 
code and in the RADIUS server's"

"error prone implmentations, and interoperability problems." ->
"error prone implementations, interoperability problems, and even
security vulnerabilities."

"most of the complex attributes" -> "most of the existing complex 
attributes"

Section 2.1.4

"does not originate from, or is checked" -> "originates from the user
and is not validated" 
"on an unauthenticated host." -> "on the user."

Section 2.1.5

"RADIUS also SHOULD NOT be extended to new commands via attributes." ->
"New attributes or new values of existing attributes SHOULD NOT be used 
to define new RADIUS commands." 

"Specifications SHOULD NOT" -> "Specifications also SHOULD NOT"

Section 3.1.1

"attribute ID" -> "attribute" 

Section 3.1.3

"via IETF process" -> "via the IETF process"
"SDO specificiations" -> "SDO specifications."

Delivery-date: Tue, 01 Jul 2008 12:17:13 +0000
Date: Tue, 1 Jul 2008 05:15:32 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Completion of RADEXT WG last call on "RADIUS Authorization for NAS Management"

The RADEXT WG last call on "RADIUS Authorization for NAS Management" has 
completed.  Comments were received, corresponding to Issues 257 and 258 in 
the Issues Tracker.  

To view the discussion relating to these issues, click on the following 
link:
http://ops.ietf.org/lists/radiusext/2008/threads.html

Delivery-date: Tue, 01 Jul 2008 09:31:11 +0000
Date: Tue, 01 Jul 2008 11:29:34 +0200
From: Stefan Winter <[email-masked]>
To: [email-masked]
CC: Milan Sova <[email-masked]>
Subject: Re: I-D Action:draft-ietf-radext-radsec-00.txt

Hi,

| Apart from that, the title, abstract, some sections in the main body
| were updated to reflect the splitting. No real content changes in it.

It has been brought to my attention that the feature of Trusted CA
Indication (which I thought is not there before TLS 1.2) is already
present in TLS 1.1 - at least RFC-wise, I didn't check any
implementations. Anyway, the section dealing with this should be
corrected, I suggest the following text:

~   The list of Certification Authorities that a node which acts as a
~   client is willing to accept SHOULD be signaled within the TLS
~   Extension "Trusted CA Indication" during the TLS handshake, as
~   described in [8], section 3.4 (or equivalent extensions in future TLS
~   versions).  Omitting this indication makes it impossible to
~   deterministically select the right certificate if a RadSec node which
~   is acting as a server for multiple roaming consortia (in possession
~   of multiple certificates from different CAs) is contacted by a
~   client.

( [8] being RFC4266)

Greetings,

Stefan Winter

- --
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

Delivery-date: Tue, 01 Jul 2008 06:48:46 +0000
From: "Glen Zorn" <[email-masked]>
To: "'Alan DeKok'" <[email-masked]>
Cc: "'David B. Nelson'" <[email-masked]>, <[email-masked]>
Subject: RE: Additional comments ondraft-ietf-radext-management-authorization-03.txt
Date: Tue, 1 Jul 2008 13:47:02 +0700

Alan DeKok [mailto:[email-masked]] writes:
> Glen Zorn wrote:
> > Uh-huh...what's your point?  Everything that is copyrighted is also
> subject
> > to "fair use", at least in the US, & this would certainly constitute
> fair
> > use.
> 
>  "cut and paste" of the pages is fair use only if *quotes* are
> included.
>  Including the pages verbatim would likely not fall under fair use
> guidelines.

First, man pages are portions of a larger document (the manual) and as such
reproducing one is by definition a quotation from the full document.  Be
that as it may, however, see
http://www.freebsd.org/copyright/freebsd-doc-license.html &
http://www.freebsd.org/copyright/freebsd-license.html for the ability to
reproduce BSD man pages (the most likely candidate for rcp, anyway).  

>   Alan DeKok.

Delivery-date: Tue, 01 Jul 2008 06:30:58 +0000
Date: Tue, 01 Jul 2008 08:29:41 +0200
From: Alan DeKok <[email-masked]>
To: Glen Zorn <[email-masked]>
CC: "'David B. Nelson'" <[email-masked]>,  [email-masked]
Subject: Re: Additional comments ondraft-ietf-radext-management-authorization-03.txt

Glen Zorn wrote:
> Uh-huh...what's your point?  Everything that is copyrighted is also subject
> to "fair use", at least in the US, & this would certainly constitute fair
> use.

 "cut and paste" of the pages is fair use only if *quotes* are included.
 Including the pages verbatim would likely not fall under fair use
guidelines.

  Alan DeKok.

Delivery-date: Tue, 01 Jul 2008 06:02:05 +0000
From: "Glen Zorn" <[email-masked]>
To: "'Alan DeKok'" <[email-masked]>, "'David B. Nelson'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Additional comments ondraft-ietf-radext-management-authorization-03.txt
Date: Tue, 1 Jul 2008 13:00:00 +0700

Alan DeKok [[email-masked]] writes:

> David B. Nelson wrote:
> > Well, yes.  I suppose there is no copyright issue with cut and paste
> of UNIX
> > "man" pages into an RFC.
> 
>   s/copyright/license/
> 
>   Everything is copyrighted by someone, unless explicitly place in the
> public domain.

Uh-huh...what's your point?  Everything that is copyrighted is also subject
to "fair use", at least in the US, & this would certainly constitute fair
use.

> 
> > Does anyone else on the list think that including "man" pages in
> appendices
> > is the best way to go?
> 
>   No.
> 
>   I would suggest referring to a specific version of the "man" page as
> a
> stable reference.  e.g.:
> 
>     "foo", as described in MyOS Release 1.2 "man" page.  Other systems
>     may have similar definitions.

OK, the problem is that while the reference may be stable, it may not
necessarily be readily available after some period of time: i.e., stable but
useless.

>   Alan DeKok.

Delivery-date: Tue, 01 Jul 2008 05:36:31 +0000
Date: Tue, 01 Jul 2008 07:35:22 +0200
From: Alan DeKok <[email-masked]>
To: "David B. Nelson" <[email-masked]>
CC: [email-masked]
Subject: Re: Additional comments ondraft-ietf-radext-management-authorization-03.txt

David B. Nelson wrote:
> Well, yes.  I suppose there is no copyright issue with cut and paste of UNIX
> "man" pages into an RFC.

  s/copyright/license/

  Everything is copyrighted by someone, unless explicitly place in the
public domain.

> Does anyone else on the list think that including "man" pages in appendices
> is the best way to go?

  No.

  I would suggest referring to a specific version of the "man" page as a
stable reference.  e.g.:

    "foo", as described in MyOS Release 1.2 "man" page.  Other systems
    may have similar definitions.

  Alan DeKok.

Delivery-date: Tue, 01 Jul 2008 05:09:45 +0000
From: "Glen Zorn" <[email-masked]>
To: "'David B. Nelson'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Additional comments ondraft-ietf-radext-management-authorization-03.txt
Date: Tue, 1 Jul 2008 12:07:24 +0700

David B. Nelson [[email-masked]] writes:

...

> Does anyone else on the list think that including "man" pages in
> appendices is the best way to go?

Slight clarification: I don't think that it's necessarily the _best_ way,
but it is _a_ way & in the absence of another...BTW, if you're going to
include rsh at all, you should mention Kerberos.  Unfortunately, Kerberos is
not transport security, so it kind of messes up your structure.