Subject: (radius) New Drafts available for FTP

From: Carl Rigney <[email-masked]>
Date: Fri, 26 Feb 1999 13:02:18 -0800 (PST)

The following 3 drafts will be available in the usual internet-drafts
location soon, but you can FTP them right now from
ftp://ftp.livingston.com/pub/radius/ if you don't want to wait.

draft-ietf-radius-radius-07.txt 	RADIUS
draft-ietf-radius-accounting-07.txt     RADIUS Accounting
draft-ietf-radius-ext-03.txt    	RADIUS Extensions

I'll be issuing the Working Group Last Call on them as soon as I see
they're available in the drafts directory, or Monday, whichever comes
first, but feel to email me comments anytime in the next two weeks.

I would be especially grateful for anyone who's willing to undertake
the tedious task of double-checking that the packet dumps in the
"Examples" section of the RADIUS draft are in fact valid.

Once working group last call is completed satisfactorily, the RADIUS
draft will go to IETF Last Call for advancement to Draft Standard, and
the other two drafts will go to the IESG asking to be released as
informational.

Next week I should have the rough draft of the allocation policy
guidelines for people to comment on, and shortly after that I should
have the Implementation Survey document available for comment.

The 4 MIB documents have completed working group last call.  The two
RADIUS MIB documents will be submitted for IETF Last Call for advanced
to proposed standard, and the two RADIUS Accounting MIB documents will
be submitted to the IESG as informational.

The 3 Tunneling documents have completed working group last call, and
my understanding is that they're just waiting for the L2TP document.

The RADIUS Working Group is not meeting in Minnesota.

--
Carl Rigney
[email-masked]

"It doesn't have to finish but it has to stop." -- Mike O'Dell
-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.

---

From: "Steven P. Crain" <[email-masked]>
Date: Tue, 2 Mar 1999 15:37:42 -0500 (EST)

Section 4.1
It looks like you missed removing the requirement that User-Name be in all
Access-Requests.  Section 4.1 includes "An Access-Request MUST contain a
User-Name attribute."

Section 5.6
Also, in 5.6 the description of Call Check has an odd sentence:
> It is recommended that such Access-Requests use the value
> Calling-Station-Id as the User-Name.
I think you mean "value of Calling-Station-Id as the value of User-Name"
or somthing like that.

Also, User-Name is now allowed in Access-Accept packets, but there is no
discussion as to what it means.  I realize that this is intended to
provide a User-Name to include in Accounting messages if the
Calling-Station-Id was used to authenticate, but that should be specified.

I would like to see User-Name allowed for other purposes.  E.g. [email-masked]
could be authed with Service-Type = Login, Login-Service = Rlogin,
Login-IP-Host = shell.my.net, User-Name = "joe" (or even "joe314" or
"guest"). This would eleviate many hacks that have been used over the
years, and allow a dialup authentication name space that is different from
the Login-IP-Host's name space. Name space is not much of an issue with
PPP, but if you provide shell access for large numbers of customers, it
becomes much more of an issue.

[Note on security: if the radius server is trusted to approve rlogin
connections, it should be trusted to specify what username to rlogin with
as well.]

-- 
Steven P. Crain, Development
http://www.shore.net/~scrain
Shore.Net: Local Ties... World Class Connections

-