[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Technical Errata Reported] RFC5176 (2012)
On 26-01-2010, at 14:06 , Bernard Aboba wrote:
> 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 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.
>
> 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.
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.
>
>
> -----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/>