Subject: (radius) I-D ACTION:draft-ietf-radius-radius-v2-00.txt

From: [email-masked]
Date: Fri, 05 Mar 1999 17:09:22 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Remote Authentication Dial-In User Service 
Working Group of the IETF.

	Title		: Remote Authentication Dial In User Service (RADIUS)
	Author(s)	: C. Rigney, A. Rubens, W. Simpson, S. Willens
	Filename	: draft-ietf-radius-radius-v2-00.txt
	Pages		: 75
	Date		: 04-Mar-99
	
   This document describes a protocol for carrying authentication,
   authorization, and configuration information between a Network Access
   Server which desires to authenticate its links and a shared
   Authentication Server.

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

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

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

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

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-radius-radius-v2-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

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

---

From: MARC DE VRIES WE41/KT <[email-masked]>
Date: Mon, 08 Mar 1999 18:19:52 +0200 (MET-DST)

Some comments on the draft-ietf-radius-radius-v2-00.
MAY or MAY NOT be useful...

1. page 6

<quote>
   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 are permitted in an Access-Reject.
</quote>

Proxy-State should also be permitted in Access-Reject

2. page 10

<quote>
The forwarding server MUST
         NOT modify any other Proxy-States that were in the packet and
         MUST NOT change the order of any attributes of the same type,
         including Proxy State.
</quote>

<quote>
A forwarding server MUST not modify existing
   Proxy-State, State, or Class attributes present in the packet.
</quote>

As discussed on the list earlier, most of this page is implementation
dependent. It could be included as an example (as in the new accounting draft),
but not as a requirement.

In any case, I would interpret "MUST NOT modify" as "MAY delete and add again
later on", but this is not clear from the text.

3. page 17 and 65

<quote>
      An Access-Request MUST contain a User-Name attribute.  
</quote>

<quote>
   Request   Accept   Reject   Challenge   #    Attribute
   0-1       0-1      0        0            1   User-Name
</quote>

There is a mismatch here.

4. page 24
 
<quote>
      string    1-253 octets.   Strings of length zero (0) MUST NOT be
                sent; omit the entire attribute instead.
</quote>

In the new accounting draft, the string can still be 0-253.
Has there been concensus on this issue?

5. page 51

<quote>
5.30.  Called-Station-Id

   Description

      This Attribute allows the NAS to send in the Access-Request packet
      the phone number that the user called, using Dialed Number
      Identification (DNIS) or similar technology.  Note that this may
      be different from the phone number the call comes in on.  It is
      only used in Access-Request packets.
</quote>

Why does this say 'only used in Access-Request packets'?
This is valuable info in accounting as well, as many operators use the DNIS
number to identify realms.
I would either remove the restriction or add 'but MAY be sent in
Accounting-Request packets.'

6. page 65

There is a special note [1] regarding usage of password attributes, but no
special note for usage of NAS-IP and NAS-Identifier.

That extra note *is* provided, however, in the accounting draft.

Should it be added here as well (although already covered in the body)?

7. page 75

I guess it MUST be included, but still makes me wonder:

(snipped some)
"THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 TASK FORCE DISCLAIMS ALL WARRANTIES OF FITNESS 
 FOR A PARTICULAR PURPOSE."

;)

 Kind regards,

Marc.

-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.