Authentication, Authorization and Accounting (aaa)

Bernard Aboba | 1 Sep 2003 20:11

: [Issue] Diameter/DynAuth RADIUS translation

Submitter name: Bernard Aboba
Submitter email address: aboba <at> internaut.com
Date first submitted: September 1, 2003
Reference:
Document: nasreq-12
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:

Update the references:

[RADDynAuth]  M. Chiba, M Dommety, M. Eklund, D. Mitton, B. Aboba,
              "Dynamic Authorization Extensions to Remote
              Authentication Dial In User Service (RADIUS)",
              RFC 3576, August 2003.

[RADIUSIANA]  B. Aboba, "IANA Considerations for RADIUS", RFC 3575,
              August 2003.

[RAD802.1X]   P. Congdon, et.al "IEEE 802.1X RADIUS Usage Guidelines",
              RFC 3580, September 2003.

Update Section 6.1 to include the new Service-Type value:

    17  Authorize Only  [RFC3576]

Delete the following text from Section 9.1:

"   If the Diameter translation system receives a message as specified in

(Continue reading)

headers

Jari Arkko | 2 Sep 2003 16:32

Re: : [Issue] Diameter/DynAuth RADIUS translation

Bernard Aboba wrote:
> Submitter name: Bernard Aboba
> Submitter email address: aboba <at> internaut.com
> Date first submitted: September 1, 2003
> Reference:
> Document: nasreq-12
> Comment type: T
> Priority: S
> Section: Various
> Rationale/Explanation of issue:
> 
> Update the references:

Ok.

> Update Section 6.1 to include the new Service-Type value:
> 
>     17  Authorize Only  [RFC3576]

Ok.

> Add the following to Section 9.1:
...
> Add the following to Section 9.2:

The text sounds right. But I wonder if my head hurts because
I'm tired, or because a sequence diagram would make the issue
easier. The particular piece of text I had trouble with was
where STA, ASR, and RADIUS Access Request were mentioned in
the same sentence. Which direction are these messages sent?

(Continue reading)

headers

Bernard Aboba | 12 Sep 2003 03:40

Re: : [Issue] Diameter/DynAuth RADIUS translation

> The text sounds right. But I wonder if my head hurts because
> I'm tired, or because a sequence diagram would make the issue
> easier. The particular piece of text I had trouble with was
> where STA, ASR, and RADIUS Access Request were mentioned in
> the same sentence. Which direction are these messages sent?

How does this look?

Section 9.2

"If the Diameter/RADIUS gateway supports [RADDynAuth], it may translate
a Diameter Re-Authorization-Request (RAR) message to a RADIUS CoA-Request
with a Service-Type value of "Authorization Only".  It is possible that
the NAS receiving this message will not support [RADDynAuth], in which
case an ICMP Port Unreachable message will be returned to the
Diameter/RADIUS gateway.  However, even if the NAS supports [RADDynAuth],
it may not support a Service-Type value of "Authorization Only" in a
CoA-Request message.  In this case it will respond with a CoA-Nak and
(optionally) an Error-Cause attribute with value 405," Unsupported
Service" and no Service-Type attribute.  If a Diameter/RADIUS gateway
receives such a packet, or an ICMP port unreachable message, or if it does
not support [RADDynAuth], then it SHOULD reply to the AAA server with a
Diameter Re-Authorization-Answer (RAA) message with a
Result-Code AVP of "DIAMETER_COMMAND_UNSUPPORTED".

If in response to a CoA-Request sent to the NAS, the Diameter/RADIUS
gateway  receives a RADIUS CoA-NAK containing a
Service-Type Attribute with value "Authorize Only"
and an Error-Cause Attribute with value "Request Initiated",
this is translated to a Diameter Re-Authorization-Answer (RAA)

(Continue reading)

headers

Bernard Aboba | 4 Sep 2003 22:32

Re: : [Issue] Diameter/DynAuth RADIUS translation

> The text sounds right. But I wonder if my head hurts because
> I'm tired, or because a sequence diagram would make the issue
> easier. The particular piece of text I had trouble with was
> where STA, ASR, and RADIUS Access Request were mentioned in
> the same sentence. Which direction are these messages sent?

I got a bit lazy and didn't include as much detail in Section 9.2 as in
Section 9.1.  I'll rework it.