Subject: (radius) draft-ietf-radius-ext-02.txt ready for review

From: Carl Rigney <[email-masked]>
Date: Tue, 6 Oct 1998 22:29:02 -0700 (PDT)

With extreme apologies for the very long delay, I'm pleased to
announce that the RADIUS Extensions draft is ready for review.
I've placed a copy at
ftp://ftp.livingston.com/pub/radius/draft-ietf-radius-ext-02.txt
and it should be appearing in the usual Internet-Draft locations
soon.  

This draft includes the renumbering of attributes to avoid conflict
with the tunneling attributes, and incorporates the
Acct-Interim-Interval draft and EAP draft.  There may still be rough
edges but I wanted to get it out to the list for review before going
out of town 10/8-15; email me any corrections or suggestions or
improvement by 10/16 and I'll update it when I'm back and get it out
(finally) to last call.

I think ARAP's use of the Request Authenticator on page 5 in section
2.2 needs to be clarified with regard to byte order, and there's still
a place or two where EAP needs to be smoothed; in particular 1) how to
deal with EAP-Message in Access-Requests with no User-Name, and 2) 
the EAP-Message with an EAP-Start can have a length of 2, which no other
string in RADIUS permits.  Will having a string with no data in it
cause grief for anyone's implementation?

When I get back I'll send out the RADIUS and RADIUS Accounting updates;
the changes to those are mostly minor so I wanted to get Extensions out
first.  I should have them ready for last call by the end of October.

--
Carl Rigney
[email-masked]

"October 1998.  Thanks for asking."
-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.

---

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 7 Oct 1998 08:49:28 -0700

>1) how to deal with EAP-Message in Access-Requests with no User-Name, 

I think that it is reasonable to require the Access-Request to contain a
User-name attribute. Logic follows below. 

If the NAS sends the EAP-Request/Identity message and receives
an EAP-Response/Identity prior to sending a RADIUS Access-Request 
with an EAP-Message attribute, then the User-Name will be known and 
can be included in the Access-Request. This guarantees compatibility
with RADIUS proxies, and is the only mode which our implementation
supports. 

However, when the NAS sends a RADIUS Access-Request prior to 
initiating the EAP conversation, then the userID is not known and
the EAP-Start is used. This was intended for use in circumstances
where the EAP-Request/Identity might not be sent, since this is
not mandatory in RFC 2284. 

There are only a few examples in which an identity exchange
appears to not be necessary. One is identification based on called or
calling phone numbers. For example, a smart card authentication could be
required if the user calls from a given number. This case can be 
handled by requiring the User-Name attribute and allowing the 
NAS to populate it with the other identification information. 
Another case is of some form of authentication that can determine
the identity of the user without a claim of identity. Smartcard
authentication is one example of this; the user's identity can be
included on the smartcard. However, even though the identity
exchange is not strictly necessary, it is still desirable since this
allows the NAS and proxies to remain ignorant of the details of
individual EAP modules. This is not a hardship on the client since
the client can respond to the EAP-Request/Identity with the
User-Name taken from the smartcard. 

Biometric authentication methods could also conceivably fit
into this category, although the case is hard to make. 
Typically, the computation involved in comparing the measured
biometric against a personal's profile is substantial so that 
it makes more sense to have the individual claim an identity and
test the claim rather than matching the metric against *everyone*
in the database. Even in this case, one could argue that requiring
a User-Name attribute would not be a hardship; the NAS could
fill it in with a value implying "to be determined."

-

---

From: [email-masked] (Patrice Calhoun)
Date: Wed, 7 Oct 1998 09:18:40 -0700

>fill it in with a value implying "to be determined."

If this is to be the case, I would like the "to be determined" to 
be pre-defined. Otherwise each NAS manufacturer will include its
own proprietary value, and this makes it harder to support in 
multi-vendor environments.

Perhaps a User-Name of "EAP" ?

PatC

-

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 7 Oct 1998 18:15:41 -0700

One thing that leaps out: since the sections on EAP and interim accounting
appear to be basically cut-and-pasted from draft-ietf-radius-eap-05.txt and
draft-ietf-radius-acct-interim-01.txt respectively, I think that you need to
incorporate the authors of those drafts as authors of this one as well.

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 12 Oct 1998 15:17:34 -0700

Carl Rigney <[email-masked]> writes:

>2.2 needs to be clarified with regard to byte order,

Also, I notice that you specify what should be done if the ARAP user is
_not_ a guest, but not what should be done if (s)he _is_ a guest.  What
happens?  It would make the most sense to me to send an Access-Request w/o
extraneous attributes like username and password, but that seems to be
against the law.

>and there's still