Subject: Re: [radext] #109: Additional IEEE 802.11 Attributes

From: "radext issue tracker" <[email-masked]>
Date: Fri, 03 Aug 2012 16:51:02 -0000

#109: Additional IEEE 802.11 Attributes

Comment (by Bernard_Aboba@…):

 Response from Bernard:

 Existing values of Acct-Terminate-Cause relate to conditions on the host
 or NAS that cause a session to be terminated; the attribute is used to
 inform the Accounting Server of what happened.

 This sounded similar to the first part of the description in the text:

    The Reason code field of a Disassociation or Deauthentication frame
    (see clause 8.3.3.4 and 8.3.3.12 respectively in [IEEE-802.11]) is
    transmitted by an Access Point to the station

 If a Disassociation or Deauthentication frame is sent by the AP to the
 station that causes a session to be terminated, then sending an Acct-
 Terminate-Cause in an Accounting-Request could make sense.

 However, there is also the rest of the sentence:

 "when authorization is denied, where authentication may have been
 successful."

 Some questions come to mind:

 1.  Is it the NAS which is initiating the termination (e.g., reporting the
 Reason-Code to the RADIUS server ) or is it the RADIUS server (e.g.,
 telling the AP to send a particular Reason-Code to the station)?
 2.  Is the termination occurring after a session has been started
 (Disconnect-Request) or does it represent a denial of access (Access-
 Reject)?

 One of the reason codes (code 27) seems to imply that the session was
 terminated by the SP after it was started (e.g., Access-Accept was sent,
 then a Disconnect-Request).

 In that situation, a reason for the disconnect might be included in the
 Disconnect-Request, then echoed in an Accounting-Request.

 Rather than using another attribute in the Accounting-Request to indicate
 the reason for the termination, it may make sense to use Acct-Terminate-
 Cause;  however, if that is done then Acct-Terminate-Cause would also be
 needed in the Disconnect-Request so the DAS would know what to include
 (e.g., why the session was terminated).

 Other codes (such as 28, 29 or 30) seem to imply that the session never
 got started; the implication is that an Access-Reject was sent.

 In that situation, is the desire to cause the AP to send a particular
 Reason-Code to the Station?   If a session was not started, then an
 Accounting-Request would not be sent.

 In that scenario, the use of Acct-Terminate-Cause may make less sense, and
 instead it may make sense to include an Attribute expressing the Reason-
 Code.

 The "when authentication may have been successful" raises the question of
 whether an EAP-Success is being transmitted within an EAP-Message
 attribute contained within an Access-Reject.

 RFC 3579 Section 2.6.3 says:

    Access-Accept packets SHOULD have only one EAP-Message attribute in
    them, containing EAP Success; similarly, Access-Reject packets SHOULD
    have only one EAP-Message attribute in them, containing EAP Failure.

    Where the encapsulated EAP packet does not match the result implied
    by the RADIUS Packet Type, the combination is likely to cause
    confusion, because the NAS and peer will arrive at different
    conclusions as to the outcome of the authentication.

 > From: jsalowey at cisco.com
 > To: bernard_aboba at hotmail.com
 > Date: Tue, 3 Jul 2012 17:21:56 +0000
 > CC: radext at ietf.org
 > Subject: Re: [radext] Proposed Resolution for Issue #109
 >
 > Hi Bernard,
 >
 > I haven't found anywhere where the Acct-Terminate-Cause is allowed in
 the Access-Reject. If we want to use this attribute in an Access-Reject
 then I think we would have to explicitly allow that in this draft. Do you
 see any problem with including that?
 >
 > Also, most of the existing values are indicating conditions present on
 the NAS whereas the presence of the attribute in the reject is indicating
 the reason for the reject policy decision from the AAA. Perhaps it would
 be better to use a separate attribute. The use of terminate-cause in 5196
 is pretty limited and specific.
 > Thanks,
 > Joe

 Response from Joe Salowey:

 > Existing values of Acct-Terminate-Cause relate to conditions on the host
 or NAS that cause a session to be terminated; the attribute is used to
 inform the Accounting Server of what happened.
 >
 > This sounded similar to the first part of the description in the text:
 >    The Reason code field of a Disassociation or Deauthentication frame
 >    (see clause 8.3.3.4 and 8.3.3.12 respectively in [
 > IEEE-802.11
 > ]) is
 >    transmitted by an Access Point to the station
 >
 >
 > If a Disassociation or Deauthentication frame is sent by the AP to the
 station that causes a session to be terminated, then sending an Acct-
 Terminate-Cause in an Accounting-Request could make sense.
 >
 > However, there is also the rest of the sentence:
 >
 > "when authorization is denied, where authentication may have been
 successful."
 >
 > Some questions come to mind:
 >
 > 1.  Is it the NAS which is initiating the termination (e.g., reporting
 the Reason-Code to the RADIUS server ) or is it the RADIUS server (e.g.,
 telling the AP to send a particular Reason-Code to the station)?

 [Joe] the use case that prompted this attribute was a denial of
 authorization from the AAA to tell the AP to send a particular reason
 code.  In other cases I suppose there may be other triggers for the AP to
 terminate the session.

 > 2.  Is the termination occurring after a session has been started
 (Disconnect-Request) or does it represent a denial of access (Access-
 Reject)?

 [Joe] the focus was on Access-Reject, but Disconnect-Request would
 probably applicable too.

 > One of the reason codes (code 27) seems to imply that the session was
 terminated by the SP after it was started (e.g., Access-Accept was sent,
 then a Disconnect-Request).
 >
 > In that situation, a reason for the disconnect might be included in the
 Disconnect-Request, then echoed in an Accounting-Request.
 >
 > Rather than using another attribute in the Accounting-Request to
 indicate the reason for the termination, it may make sense to use Acct-
 Terminate-Cause;  however, if that is done then Acct-Terminate-Cause would
 also be needed in the Disconnect-Request so the DAS would know what to
 include (e.g., why the session was terminated).
 >
 > Other codes (such as 28, 29 or 30) seem to imply that the session never
 got started; the implication is that an Access-Reject was sent.
 >
 > In that situation, is the desire to cause the AP to send a particular
 Reason-Code to the Station?   If a session was not started, then an
 Accounting-Request would not be sent.

 [Joe] Yes.

 > In that scenario, the use of Acct-Terminate-Cause may make less sense,
 and instead it may make sense to include an Attribute expressing the
 Reason-Code.
 >
 > The "when authentication may have been successful" raises the question
 of whether an EAP-Success is being transmitted within an EAP-Message
 attribute contained within an Access-Reject.

 [Joe]  Good point,  I think we would want to include a note to remind the
 reader of this recommendation.   It might also be feasible to allow the
 attribute in an Access-Accept to indicate failed authorization even if
 authentication succeeds,  however this seems like it may lead the
 confusing situation where an access-accept really means access-reject.

 > RFC 3579 Section 2.6.3 says:
 >
 >    Access-Accept packets SHOULD have only one EAP-Message attribute in
 >    them, containing EAP Success; similarly, Access-Reject packets SHOULD
 >    have only one EAP-Message attribute in them, containing EAP Failure.
 >
 >    Where the encapsulated EAP packet does not match the result implied
 >    by the RADIUS Packet Type, the combination is likely to cause
 >    confusion, because the NAS and peer will arrive at different
 >    conclusions as to the outcome of the authentication.

-- 
-----------------------------+------------------------------
 Reporter:  jsalowey@…       |       Owner:  bernard_aboba@…
     Type:  defect           |      Status:  new
 Priority:  major            |   Milestone:  milestone1
Component:  ieee802ext       |     Version:  1.0
 Severity:  In WG Last Call  |  Resolution:
 Keywords:                   |
-----------------------------+------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/109#comment:2>
radext <http://tools.ietf.org/radext/>