Subject: Re: [radext] Proposed Resolution for Issue #109

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Tue, 3 Jul 2012 17:21:56 +0000

Hi Bernard,

I haven't found anywhere where the Acct-Termiate-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

On Jun 26, 2012, at 3:35 PM, Bernard Aboba wrote:

> <RAD-WLAN.txt>

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Tue, 3 Jul 2012 17:21:56 +0000

Hi Bernard,

Thanks,

Joe

> <RAD-WLAN.txt>

_______________________________________________
radext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/radext

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 4 Jul 2012 09:29:13 -0700

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: [email-masked]
> To: [email-masked]
> Date: Tue, 3 Jul 2012 17:21:56 +0000
> CC: [email-masked]
> 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?  
>

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 4 Jul 2012 09:29:13 -0700

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Wed, 11 Jul 2012 04:40:10 +0000

On Jul 4, 2012, at 9:29 AM, Bernard Aboba wrote:

>    (see clause 8.3.3.4 and 8.3.3.12 respectively in [
> IEEE-802.11
> ]) is

[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.  

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

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

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Wed, 11 Jul 2012 04:40:10 +0000

[Joe] Yes.