[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Technical Errata Reported] RFC5176 (2012)
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:avi@bridgewatersystems.com]
Sent: Monday, January 25, 2010 9:15 PM
To: Bernard Aboba
Cc: radiusext@ops.ietf.org
Subject: Re: [Technical Errata Reported] RFC5176 (2012)
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/>