Re: [Technical Errata Reported] RFC5176 (2012)

[Avi Lior <avi@bridgewatersystems.com>]

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. 


On 26-01-2010, at 12:05 , Bernard Aboba wrote:

> 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:rfc-editor@rfc-editor.org] 
> Sent: Monday, January 25, 2010 7:43 PM
> To: mchiba@cisco.com; gdommety@cisco.com; meklund@cisco.com;
> david@mitton.com; bernarda@microsoft.com; dromasca@avaya.com;
> rbonica@juniper.net; d.b.nelson@comcast.net; Bernard_Aboba@hotmail.com
> Cc: avi@bridgewatersystems.com; radiusext@ops.ietf.org;
> rfc-editor@rfc-editor.org
> 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 <avi@bridgewatersystems.com>
> 
> 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 radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>