Re: AW: -01 version of Chargeable User Identity

[Bernard Aboba <aboba@internaut.com>]

> I was indeed suggesting that a CUI creating RADIUS Server should keep state
> of trusted CUI-capable NASes, and therefore inherit the risk of an "old" NAS
> not presenting the provided CUI in the accounting requests. After all, it is
> himself or  his user who probably asked for privacy protection which made
> the CUI necessary. The CUI creating RADIUS Server is basically a home RADIUS
> Server supporting roaming privacy - at least that is my point of view.

OK.  Are you saying that the null CUI attribute is only sent by the NAS
for a session in which authentication privacy is invoked?  For example,
this would imply that the Access-Request only contains a null CUI when the
EAP-Response/Identity is compatible with privacy (e.g. "@example.com").
But when a full identity is used (e.g. "fred@example.com") the null CUI
attribute is ommitted.

> To the more general question, of the overhead potentially introduced by a
> "mandatory" CUI attribute I would like to comment as follows:
> So far RADIUS does not support the concept of a mandatory attribute.

At IETF 60 David Nelson made a presentation on this.  In fact, RFC 2865
does seem to indicate that some attributes are mandatory, such as
Service-Type.

Dave -- can you summarize your conclusions?

> indeed proposed that the RADIUS server may enforce  "mandatoriness" by
> sending a "conditional" REJECT, indicating via a Reject reason (or
> alternatively via the mandatory attribute being present), that this Reject
> is indeed a Reject which has only been sent because the sender was unsure if
> the receiver would interpret a certain attribute as mandatory when present
> in an ACCEPT message - otherwise an ACCEPT would have been sent.

One issue is whether the RADIUS server supports CUI, and if not, what it
will do on receipt of an Access-Request with a null CUI attribute.  Since every
existing RADIUS server is in this category, this isn't behavior we can change
-- it is what it is.  All we can do is try to understand the current
behavior.

The other issue is whether the NAS supports CUI, and if so, what it will
do on receipt of an Access-Accept where CUI is not present.  My
understanding is that CUI will typically be required by the NAS, at least
for sessions where privacy is invoked.  Without CUI, there may be no way
for the NAS to know that has a valid billable identity prior to providing
service.  So it seems that the NAS would need to treat an Access-Accept
without CUI like an Access-Reject.  There is some precedent for this in
RFC 2865 -- I believe that the NAS needs to treat an Access-Accept with an
unimplemented Service-Type this way.

> I would be interested to hear if this could be a general method to solve the
> "mandatory/optional" backwards compabibility problem associated with the
> fact that it appears to be un-predictable if an unknown old NAS will reject
> or accept an Access Accept Message with a new attribute present, that he
> does not recognize.

Changing the semantics of the Access-Reject is somewhat tricky since the
goal of that message is to deny service.  As a result, RFC 2865
discourages inclusion of service-definition attributes within an
Access-Reject, and subsequent RFCs have only included attributes that
provide elaboration on the failure or its causes:  EAP-Message,
Reply-Message, etc.

> 3. NAS should autonomously convert the conditional REJECT into an ACCEPT and
> welcome the user as usual.

Interpetting an Access-Reject as an Access-Accept is explicitly forbidden
by RFC 2865.  We don't want to go down that road.


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>