Subject: RE: [Technical Errata Reported] RFC5176 (2012)

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 25 Jan 2010 20:05:45 -0800

The intent in writing that sentence was just to clarify use of Error-Cause
in CoA and Disconnect messages (the topic of RFC 5176).   So the intent was
not to update RFC 3579, or somehow imply that previous usages were
deprecated.  As you say, Error-Cause can be included in other messages as
well. 

Has there been confusion on this issue in the field?

-----Original Message-----
From: RFC Errata System [mailto:[email-masked]] 
Sent: Monday, January 25, 2010 7:43 PM
To: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]
Subject: [Technical Errata Reported] RFC5176 (2012)

The following errata report has been submitted for RFC5176, "Dynamic
Authorization Extensions to Remote Authentication Dial In User Service
(RADIUS)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5176&eid=2012

--------------------------------------
Type: Technical
Reported by: Avi Lior <[email-masked]>

Section: 3.5

Original Text
-------------
Values 200-299 represent successful completion, so that thesevalues may only
be sent within CoA-ACK or Disconnect-ACK packetsand MUST NOT be sent within
a CoA-NAK or Disconnect-NAK packet.

Corrected Text
--------------
Values 200-299 represent successful completion, so that thesevalues may be
sent in other reply messages such as Access-Reject, Access-Challenge,
CoA-ACK or Disconnect-ACK packetsand MUST NOT be sent within a CoA-NAK or
Disconnect-NAK packet.

Notes
-----
RFC 3579  allows for Error-Cause to be sent (specifically) in an
access-challenge and also in Reject messages as well.The specification in
5176 restricts the usage and should be clarified especially since 5176 was
published after 3579.I proposed minimal text but I think a broader approach
is needed for this attribute.  Here are some thoughts:1) Error-Cause is
needed in Access-Reject (as is allowed by 3579)2) IANA should have
procedures for defining new values (currently no procedure is defined). SDO
need to be able to use Error-Cause to report back why an
Authentication/Authorization failed.  Error-Cause seems to be the only
solution other than Reply-Message which is not really designed for reporting
error cause to the NAS.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please use
"Reply All" to discuss whether it should be verified or rejected. When a
decision is reached, the verifying party (IESG) can log in to change the
status and edit the report, if necessary. 

--------------------------------------
RFC5176 (draft-ietf-radext-rfc3576bis-13)
--------------------------------------
Title               : Dynamic Authorization Extensions to Remote
Authentication Dial In User Service (RADIUS)
Publication Date    : January 2008
Author(s)           : M. Chiba, G. Dommety, M. Eklund, D. Mitton, B. Aboba
Category            : INFORMATIONAL
Source              : RADIUS EXTensions
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG

--
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: Avi Lior <[email-masked]>
Date: Tue, 26 Jan 2010 00:15:09 -0500

Yes.  There is confusion between reading 2865 and various other RFC.

The only RFC that I found that allows Error-Cause to be included in other messages was 3579.  Is there another?

In fact I am faced with this problem as we speak.  Let me try to explain the various issues:

We  need a mechanism to indicate why an authentication/authorization has failed. 

First there are scenarios where the authentication has failed.  For that access-reject seems to suffice.

But we also have scenario where authentication has succeeded but authorization has failed.
In this case we need to communicate to the NAS why the session was not authorized.  This is needed so the NAS can make an intelligent decision or take alternative action.

The case in point is Femtocell authentication/authorization.

If the mobile is not authenticated then Access-Reject is the appropriate answer since no service is to be provided.

If the mobile is authenticated and not authorized for femto use then the Femtocell needs to interact with the mobile to get it to use the Macro cell (for example).

How do we tell the Femtocell that the MS is not authorized.

Access-Accept with an attribute indicating  that the MS is not authorized is workable but may be a problem.  A legacy  Femtocell that is not aware of the attribute will ignore the attribute and interpret the access-accept as permission to offer service.

An access-reject is a better option but we need to be able to carry additional information -- currently we dont have too many options.  Reply message which is not really intended for the Femtocell.  Error-Cause would work but we would need it to be extended by SDOs.

Note that Error-Cause may also be the wrong attribute to use.  One would (correctly) argue that its purpose is to only indicate when errors have occurred in the protocol.  Failure to authorize is not an error condition of the protocol.

Avi.

---

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 25 Jan 2010 22:06:36 -0800

A quick search turned up the following references to Error-Cause in RADIUS
RFCs:

RFC 3579 explicitly enables inclusion of Error-Cause in Access-Reject and
Access-Challenge messages (see Section 3.3). 
RFC 3580 lists Error-Cause in Table 8. 
RFC 4672 mentions Error-Cause in definition of MIB objects.
RFC 5176 talks about use in CoA and Disconnect messages. 
RFC 5580 uses Error-Cause (e.g. for "Location-Info-Required"). 

It's possible I've missed a few references/uses.  But on this basis alone,
there shouldn't be much question that it
can be used beyond CoA and Disconnect messages -- especially since RFC 5176
doesn't update RFC 3579 (so that anything said in RFC 3579 isn't affected). 

The issue of authorization has come up in a number of situations, most
recently IEEE 802.1X-REV, where within an Access-Accept, a user can be
authorized for a variety of levels of access, from unfettered access to
restricted access.  There are also situations where the client might not
implement IEEE 802.1X at all, but where it is still desired to allow the
client on the network in some form (perhaps via a Web portal or restricted
access of some kind), so that RADIUS might still end up being used,
conceivably.  

As you say, most of the existing uses of Error-Cause are for protocol error
of some kind, so in looking at the IEEE 802.1X-REV authorization scenarios,
the preliminary thinking was to use some other attribute to communicate the
content that might end up in EAPOL-Announcements that provide the client
with an indication of the access status. 

-----Original Message-----
From: Avi Lior [mailto:[email-masked]] 
Sent: Monday, January 25, 2010 9:15 PM
To: Bernard Aboba
Cc: [email-masked]
Subject: Re: [Technical Errata Reported] RFC5176 (2012)

The only RFC that I found that allows Error-Cause to be included in other
messages was 3579.  Is there another?

In fact I am faced with this problem as we speak.  Let me try to explain the
various issues:

We  need a mechanism to indicate why an authentication/authorization has
failed. 

First there are scenarios where the authentication has failed.  For that
access-reject seems to suffice.

But we also have scenario where authentication has succeeded but
authorization has failed.
In this case we need to communicate to the NAS why the session was not
authorized.  This is needed so the NAS can make an intelligent decision or
take alternative action.

If the mobile is not authenticated then Access-Reject is the appropriate
answer since no service is to be provided.

If the mobile is authenticated and not authorized for femto use then the
Femtocell needs to interact with the mobile to get it to use the Macro cell
(for example).

Access-Accept with an attribute indicating  that the MS is not authorized is
workable but may be a problem.  A legacy  Femtocell that is not aware of the
attribute will ignore the attribute and interpret the access-accept as
permission to offer service.

An access-reject is a better option but we need to be able to carry
additional information -- currently we dont have too many options.  Reply
message which is not really intended for the Femtocell.  Error-Cause would
work but we would need it to be extended by SDOs.

Note that Error-Cause may also be the wrong attribute to use.  One would
(correctly) argue that its purpose is to only indicate when errors have
occurred in the protocol.  Failure to authorize is not an error condition of
the protocol.

Avi.

---

From: Avi Lior <[email-masked]>
Date: Tue, 26 Jan 2010 02:15:10 -0500

> doesn't update RFC 3579 (so that anything said in RFC 3579 isn't affected). 
The problem is still that the use of Error-Cause in Access-Reject is not that obvious.  3579 talks about using it in Access-Challenge and only in the table of attributes does it show it as 0-1 in Reject.

3580 is totally vague about Error-Cause.

4672 only counts when Error-Cause is in Coa-NAK or Disconnect-NAK.  So it does not provide any hints about Error-Cause in any Access-Reject.

So it is 5580 that actually uses it in Access-Reject.

So the reader would have to specifically read the table of occurance in 3579 or 5580 to know that they can use this attribute in Access-Reject.

The proposed errata would be helpful - but I will let you guys decide.

> with an indication of the access status. 

Given the above the situation is very grim.  Error-Cause is not the right attribute.

In a situation where the AAA Server doesnt not intend to allow for access to the service provided - an access-accept is should not be used.  Access-Reject does not allow us to use even a Vendor Specific Attribute (26) so we cant communicate the reason for rejection.

The only solution is to use Access-Accept with a code that indicates that no service should be provided.  This is a terrible solution/situation.

---

From: "Dave Nelson" <[email-masked]>
Date: Tue, 26 Jan 2010 07:58:38 -0500

> As you say, most of the existing uses of Error-Cause are for
> protocol error of some kind, so in looking at the IEEE 802.1X-REV 
> authorization scenarios, the preliminary thinking was to use some
> other attribute to communicate the content that might end up in
> EAPOL-Announcements that provide the client with an indication
> of the access status.

Haven't we already clarified, in RFC 5080 Section 2.6, that with the use of
an Access-Reject message "no means no" and that Access-Reject cannot be used
to provision restricted or alternate forms of service or access?

---

From: "Dave Nelson" <[email-masked]>
Date: Tue, 26 Jan 2010 08:11:40 -0500

> So it is 5580 that actually uses it in Access-Reject.

That usage is as follows:

   o  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).

It constitutes a "poor-man's" form of capabilities negotiations, in that it
signals that needed information that is missing from an
Authentication-Request.  It is not use to signal a limited or alternate form
of service to be provided as a result of the Access-Reject, however.  That
would violate the "no means no" doctrine.

> Given the above the situation is very grim.  Error-Cause is not the right

I think it is not the right attribute.  In fact I think there is no
attribute that *can* be use to change an Access-Reject into a modified,
limited or alternate form of Access-Accept.

> In a situation where the AAA Server doesnt not intend to allow for access
> to the service provided - an access-accept is should not be used.  Access-
> Reject does not allow us to use even a Vendor Specific Attribute (26) so
> we cant communicate the reason for rejection.

Correct.

> The only solution is to use Access-Accept with a code that indicates that
> no service should be provided.  This is a terrible solution/situation.

Well, if *no* service is to be provided, then why isn't an Access-Reject
appropriate?  OTOH, if what's really happening is that the RADIUS server is
provisioning an alternate form of service, maybe even one that the NAS is
not in a position to provide, why not send an Access-Accept including a set
of attributes that provision the allowed service and let the NAS decide if
it can provide that service, and if not how it wants to signal to the client
that the alternate (allowed) service is not achievable on that connection?

---

From: Avi Lior <[email-masked]>
Date: Tue, 26 Jan 2010 08:19:30 -0500

Yes 5080 is helpful here - I remember this discussion.  I can use it to clear up the issue and squash any arguments at the SDO.

It both describes a problem and provides a way to address this problem:

"If the desire is to allow
   limited access, then an Access-Accept can be sent with attributes
   provisioning limited access. "

I wish another document was as clear ;-)

There are still issues with this approach since a legacy NAS may not recognize the attributes that provision the limited access.  It would have been good to include the warning.

However, in my case this is not going to be a problem.

---

From: Avi Lior <[email-masked]>
Date: Tue, 26 Jan 2010 08:25:38 -0500

i agree with you David,  see inline...

> would violate the "no means no" doctrine.

Understood.

> limited or alternate form of Access-Accept.
Right.
> appropriate?  

When I meant no service - it is not the service that was requested.

> OTOH, if what's really happening is that the RADIUS server is

yes.  But the danger here is that the NAS may not understand the attributes that are offering the alternate (limiting) service and would interpret the response as a full access-accept.

For this situation to work correctly the sender of the Access-Accept would have to know whether or not the Receiver has to means to recognize the response correctly.  This could be provided by a capability exchange for example.

If the NAS did not indicate support for the new attributes that an Access-Reject may be the correct response.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 26 Jan 2010 14:42:00 +0100

> yes.  But the danger here is that the NAS may not understand the attributes that are offering the alternate (limiting) service and would interpret the response as a full access-accept.

  I agree.  Access-Accept means "let them on the network", and only
*partially* "give them limited services".  There are just too many
unknowns around NAS behavior to over-load Access-Accept.

> If the NAS did not indicate support for the new attributes that an Access-Reject may be the correct response.

  Many systems use Reply-Message as a feedback for failed
authentication.  e.g. "Password expired".

  I'm ambivalent about using Error-Cause.  I don't see many major
problem with it.  But it does extend the meaning of Access-Reject past
"go away, and I'm not telling you why".

  In this case, Error-Cause seems to be a substitute for an
administrator actually knowing the NAS capabilities, and configuring
them properly.  This would seem to be most useful for global proxy chains.

  Alan DeKok.

---

From: "Dave Nelson" <[email-masked]>
Date: Tue, 26 Jan 2010 08:42:18 -0500

> yes.  But the danger here is that the NAS may not understand the
> attributes that are offering the alternate (limiting) service and
> would interpret the response as a full access-accept.

If the provisioning is via Service-Type, then NASes MUST treat provisioning
of an unrecognized / unsupported service as if the message were an
Access-Reject.  That's clearly stated and has been around long enough that
any NAS failing to enforce this behavior is *badly* broken.

> For this situation to work correctly the sender of the Access-Accept
> would have to know whether or not the Receiver has to means to
> recognize the response correctly.

For subsidiary attributes that further modify the Service-Type attribute,
this is true. There are recommendations that NASes ought to have a local
policy regarding treatment of such attributes, but there is no absolute
guarantee.  Service-Type is the only RADIUS attribute that is implicitly
"mandatory" in all implementations.

> This could be provided by a capability exchange for example.

I always thought that would be useful and the WG never seemed to agree.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 26 Jan 2010 14:50:54 +0100

> any NAS failing to enforce this behavior is *badly* broken.

  Yes.

  It gets *much* worse than that.

  Alan DeKok.

---

From: "Dave Nelson" <[email-masked]>
Date: Tue, 26 Jan 2010 08:51:48 -0500

> There are just too many unknowns around NAS behavior to over-load
> Access-Accept.

I don't think anyone has suggested over-loading Access-Accept.  If use as
originally intended, to provision service, it works just fine, at least if
the service is described in the Service-Type attribute.

After all, RADIUS is not about answering authorization questions from NASes,
it's about identifying users and *telling* them what service they get, based
on their identity, and contextual hints from the NAS.

---

From: Avi Lior <[email-masked]>
Date: Tue, 26 Jan 2010 09:19:59 -0500

Hmmmm

"provisioning a service"  is authorization no?

I authenticate you then authorize you for a service by sending you authorization attribute that define what service or services you will receive.

> on their identity, and contextual hints from the NAS.

identifying users is authentication and telling them what service they get is authorization.  Am I missing something?

Anyway it may not be important that the language we are using is aligned.

---

From: Avi Lior <[email-masked]>
Date: Tue, 26 Jan 2010 09:33:35 -0500

The summary for this discussion is:

-Access-Accept should be used as defined by 5080.
-However there are dangers - which a capability negotiation could have solved.
-Error-Cause is for protocol errors mostly.  Having said that it does have a an Error Code 501 "Administratively Prohibited" which would be a stretch to call a protocol error.

Regarding the Errata. I still think it should be issued because it is not that obvious where Error-Cause can be included.  But we know.

-IANA should have clear instruction on how to extend Error-Cause.  Currently i dont think they do.

-Unless i am missing something, except for values 0-199 and 300-399, the RFCs do not reserve unused values for Error-Cause -- and then we wonder why people just grab numbers.

-It would have been useful to allow VSA to be included in Access-Reject. So at least an SDO can return an Error-Cause of their own or even Authorization-Failure-Cause or Authentication-Failure-Cause instead of hacking the Reply-Message attribute.

---

From: "David B. Nelson" <[email-masked]>
Date: Tue, 26 Jan 2010 10:15:10 -0500

On Jan 26, 2010, at 9:33 AM, Avi Lior wrote:

> -It would have been useful to allow VSA to be included in Access- 
> Reject.
> So at least an SDO can return an Error-Cause of their own or even
> Authorization-Failure-Cause or Authentication-Failure-Cause instead of
> hacking the Reply-Message attribute.

Potentially useful, yes, but also "dangerous".  If VSAs are allowed in  
Access-Reject messages, it becomes much harder to maintain the "no  
means no" doctrine.

---

From: "David B. Nelson" <[email-masked]>
Date: Tue, 26 Jan 2010 10:21:08 -0500

Correct.

> I authenticate you then authorize you for a service by sending you  
> authorization attribute that define what service or services you  
> will receive.

Yes.

> identifying users is authentication and telling them what service  
> they get is authorization.  Am I missing something?
>

It is a semantics issue.   The RADIUS model is to provision services  
(authorize access) based on authenticated identity, contextual hints  
from the NAS and server-based policy.   The NAS cannot ask questions  
of the form "Would you allow this user to access that service?"  The  
NAS can ask questions of the form "I have this user, who has made a  
connection attempt via that port / protocol, what access should I  
provision to the user?"

---

From: Avi Lior <[email-masked]>
Date: Tue, 26 Jan 2010 17:38:16 -0500

> Access-Reject messages, it becomes much harder to maintain the "no  

If someone wanted to break the doctrine they can just hack Reply-Message or they can just use a VSA anyway.  You cant prevent anything if someone want to be dangerous or careless or whatever you want to call it.

If you want someone to be respectful of your protocol then you should create a protocol that demands respect by providing the tools necessary to meet the legitimate  usecases for which that protocol will be used.  Overtime those usecases will change.  Failing to recognize those changes means that people will fix it themselves and you wil loose control of the protocol.  This is exactly where we were heading before RADEXT was formed.  But the IETF was smart enough to recongize that the use of the RADIUS protocol is strong and is evolving.

So I would assert that telling a NAS why we are sending an Access-Reject is a valid use-case - after all Diameter allows the Server to specifically indicate when Authorization has failed (vs Authentication).

BTW I think what is also missing is how one translates between Diameter Result-Code and Error-Cause.

---

From: Avi Lior <[email-masked]>
Date: Tue, 26 Jan 2010 17:52:03 -0500

I fail to see a distinction here - but it could be me...

On 26-01-2010, at 23:21 , David B. Nelson wrote:

> from the NAS and server-based policy.  

Correct.  No problem here.

>  The NAS cannot ask questions  
> of the form "Would you allow this user to access that service?"  

This user = authenticated identity. (I have this user)
That service = contextual hints. (port/protocol)

> The  

I am sorry i just dont see a difference.

---

From: "David B. Nelson" <[email-masked]>
Date: Tue, 26 Jan 2010 19:22:52 -0500

On Jan 26, 2010, at 5:52 PM, Avi Lior wrote:

>> The  NAS can ask questions of the form "I have this user, who has  
>> made a

I guess the difference is that the RADIUS server is free to ignore the  
contextual hints and simply provision the service that is dictated by  
the user's identity and context-independent policy.   The NAS need to  
be prepared to deal with *either* an Access-Accept provisioning an  
unexpected / unsupported service *or* an Access-Reject, in response to  
the same Access-Request.