[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: Cleanup of Section 3
Issue: Cleanup of Section 2.3, 3
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: May 23, 2007
Reference:
Document: RFC3576bis-05
Comment type: Technical
Priority: S
Section: 2
Rationale/Explanation of issue:
In looking over Section 2.3 and 3, there is a lot of text in Section 2.3 Attributes heading relating to Proxy-State which probably belongs in Section 3. There is also a lot of text in a variety of sections that is very similar to what is in Section 2.3, but is worded slightly differently.
The proposed fix is to change the text of Section 2.3 Attributes heading from:
"Attributes
In Disconnect and CoA-Request packets, all Attributes are treated
as mandatory. A NAS MUST respond to a CoA-Request containing one
or more unsupported Attributes or Attribute values with a CoA-NAK;
a Disconnect-Request containing one or more unsupported Attributes
or Attribute values MUST be answered with a Disconnect-NAK. State
changes resulting from a CoA-Request MUST be atomic: if the
Request is successful, a CoA-ACK is sent, and all requested
authorization changes MUST be made. If the CoA-Request is
unsuccessful, a CoA-NAK MUST be sent, and the requested
authorization changes MUST NOT be made. Similarly, a state change
MUST NOT occur as a result of an unsuccessful Disconnect-Request;
here a Disconnect-NAK MUST be sent.
Within this specification attributes may be used for
identification, authorization or other purposes. RADIUS Attribue
specifications created after publication of this document SHOULD
state whether an Attribute can be included in CoA or Disconnect
messages and if so, which messages it may be included in and
whether it serves as an identification or authorization attribute.
Even if a NAS implements an attribute for use with RADIUS
authentication and accounting, it is possible that it will not
support inclusion of that attribute within Disconnect-Request or
CoA-Request packets, given the difference in attribute semantics.
This is true even for attributes specified as allowable within
Access-Accept packets (such as those defined within [RFC2865],
[RFC2868], [RFC2869], [RFC3162], [RFC3579], [RFC4372], [RFC4675],
[RFC4818] and [RFCFilter]). If unsupported attributes are
included within a Disconnect/CoA-Request packet, the RADIUS client
will send a Disconnect-NAK/CoA-NAK in response, possibly
containing an Error-Cause attribute with value Unsupported
Attribute (401).
If there are any Proxy-State Attributes in a Disconnect-Request or
CoA-Request received from the server, the forwarding proxy or NAS
MUST include those Proxy-State Attributes in its response to the
server.
A forwarding proxy or NAS MUST NOT modify existing Proxy-State,
State, or Class Attributes present in the packet. The forwarding
proxy or NAS MUST treat any Proxy-State attributes already in the
packet as opaque data. Its operation MUST NOT depend on the
content of Proxy-State attributes added by previous proxies. The
forwarding proxy MUST NOT modify any other Proxy-State Attributes
that were in the packet; it may choose not to forward them, but it
MUST NOT change their contents. If the forwarding proxy omits the
Proxy-State Attributes in the request, it MUST attach them to the
response before sending it.
When the proxy forwards a Disconnect or CoA-Request, it MAY add a
Proxy-State Attribute, but it MUST NOT add more than one. If a
Proxy-State Attribute is added to a packet when forwarding the
packet, the Proxy-State Attribute MUST be added after any existing
Proxy-State attributes. The forwarding proxy MUST NOT change the
order of any attributes of the same type, including Proxy-State.
Other Attributes can be placed before, after or even between the
Proxy-State Attributes.
When the proxy receives a response to a CoA-Request or Disconnect-
Request, it MUST remove its own Proxy-State (the last Proxy- State
in the packet) before forwarding the response. Since Disconnect
and CoA responses are authenticated on the entire packet contents,
the stripping of the Proxy-State Attribute invalidates the
integrity check - so the proxy needs to recompute it."
To:
"Attributes
In Disconnect and CoA-Request packets, all Attributes are treated
as mandatory. If one or more authorization changes specified in a
CoA-Request cannot be carried out, the NAS MUST send a CoA-NAK. A
NAS MUST respond to a CoA-Request containing one or more
unsupported Attributes or Attribute values with a CoA-NAK; an
Error-Cause Attribute with value 401 (Unsupported Attribute) or
407 (Invalid Attribute Value) MAY be included. A NAS MUST respond
to a Disconnect-Request containing one or more unsupported
Attributes or Attribute values with a Disconnect-NAK; an Error-
Cause Attribute with value 401 (Unsupported Attribute) or 407
(Invalid Attribute Value) MAY be included.
State changes resulting from a CoA-Request MUST be atomic: if the
Request is successful, a CoA-ACK MUST be sent in reply, and all
requested authorization changes MUST be made. If the CoA-Request
is unsuccessful, a CoA-NAK MUST be sent in reply, and the
requested authorization changes MUST NOT be made. Similarly, a
state change MUST NOT occur as a result of an unsuccessful
Disconnect-Request; a Disconnect-NAK MUST be sent in reply.
Within this specification attributes can be used for
identification, authorization or other purposes. RADIUS Attribute
specifications created after publication of this document SHOULD
state whether an attribute can be included in CoA or Disconnect
messages and if so, which messages it can be included in and
whether it serves as an identification or authorization attribute.
Even if a NAS implements an attribute for use with RADIUS
authentication and accounting, it is possible that it will not
support inclusion of that attribute within Disconnect-Request or
CoA-Request packets, given the difference in attribute semantics.
This is true even for attributes specified as allowable within
Access-Accept packets (such as those defined within [RFC2865],
[RFC2868], [RFC2869], [RFC3162], [RFC3579], [RFC4372], [RFC4675],
[RFC4818] and [RFC4849])."
Section 3, 3.1 and 3.2 are changed from:
"3. Attributes
In Disconnect-Request and CoA-Request packets, certain attributes are
used to uniquely identify the NAS as well as a user session on the
NAS. All NAS identification attributes included in a Request packet
MUST match in order for a Disconnect-Request or CoA-Request to be
successful; otherwise a Disconnect-NAK or CoA-NAK SHOULD be sent.
For session identification attributes, the User-Name and Acct-
Session-Id Attributes, if included, MUST match in order for a
Disconnect-Request or CoA-Request to be successful; other session
identification attributes SHOULD match. Where a mismatch of session
identification attributes is detected, a Disconnect-NAK or CoA-NAK
SHOULD be sent.
The ability to use NAS or session identification attributes to map to
unique/multiple sessions is beyond the scope of this document.
Identification attributes include NAS and session identification
attributes, as described below.
NAS identification attributes
Attribute # Reference Description
--------- --- --------- -----------
NAS-IP-Address 4 [RFC2865] The IPv4 address of the NAS.
NAS-Identifier 32 [RFC2865] String identifying the NAS.
NAS-IPv6-Address 95 [RFC3162] The IPv6 address of the NAS.
Session identification attributes
Attribute # Reference Description
--------- --- --------- -----------
User-Name 1 [RFC2865] The name of the user
associated with the session.
NAS-Port 5 [RFC2865] The port on which the
session is terminated.
Attribute # Reference Description
--------- --- --------- -----------
Called-Station-Id 30 [RFC2865] The link address to which
the session is connected.
Calling-Station-Id 31 [RFC2865] The link address from which
the session is connected.
Acct-Session-Id 44 [RFC2866] The identifier uniquely
identifying the session
on the NAS.
Acct-Multi-Session-Id 50 [RFC2866] The identifier uniquely
identifying related sessions.
NAS-Port-Id 87 [RFC2869] String identifying the port
where the session is.
Chargeable-User- 89 [RFC4372] The CUI associated with the
Identity session. Needed where a
privacy NAI is used, because
the User-Name may not be
unique (e.g. "anonymous").
To address security concerns described in Section 6.1, either the
User-Name or Chargeable-User-Identity attribute SHOULD be present in
Disconnect-Request and CoA-Request packets.
Where a Diameter client utilizes the same Session-Id for both
authorization and accounting, inclusion of an Acct-Session-Id
Attribute in a Disconnect-Request or CoA-Request can assist with
Diameter/RADIUS translation, since Diameter RAR and ASR commands
include a Session-Id AVP. An Acct-Session-Id attribute SHOULD be
included in Disconnect-Request and CoA-Request packets.
Where the Acct-Session-Id or Acct-Multi-Session-Id attributes are not
present in a CoA-Request or Disconnect-Request, it is possible that
the User-Name or Chargeable-User-Identity attributes will not be
sufficient to uniquely identify the session (e.g. if the same user
has multiple sessions on the NAS, or the privacy NAI is used). As a
result, the Called-Station-Id, Calling-Station-Id, NAS-Port and NAS-
Port-Id attributes MAY be used as additional session identification.
To address security concerns described in Section 6.2, one or more of
the NAS-IP-Address or NAS-IPv6-Address Attributes SHOULD be present
in Disconnect-Request and CoA-Request packets; the NAS-Identifier
Attribute MAY be present.
If one or more authorization changes specified in a CoA-Request
cannot be carried out, or if one or more attributes or attribute-
values is unsupported, a CoA-NAK MUST be sent. Similarly, if there
are one or more unsupported attributes or attribute values in a
Disconnect-Request, a Disconnect-NAK MUST be sent.
A Disconnect-Request MUST contain only NAS and session identification
attributes (see Section 3). If other attributes are included in a
Disconnect-Request, implementations MUST send a Disconnect-NAK; an
Error-Cause Attribute with value "Unsupported Attribute" MAY be
included.
3.1. Authorize Only
Support for a CoA-Request including a Service-Type Attribute with
value "Authorize Only" is OPTIONAL on the NAS and RADIUS server. A
Service-Type Attribute MUST NOT be included within a Disconnect-
Request.
A NAS MUST respond to a CoA-Request including a Service-Type
Attribute with value "Authorize Only" with a CoA-NAK; a CoA-ACK MUST
NOT be sent. If the NAS does not support a Service-Type value of
"Authorize Only" then it MUST respond with a CoA-NAK; an Error-Cause
value of 405 (Unsupported Service) SHOULD be included.
A CoA-Request containing a Service-Type Attribute with value
"Authorize Only" MUST in addition contain only NAS or session
identification attributes, as well as a State Attribute. If other
attributes are included in such a CoA-Request, a CoA-NAK MUST be
sent; an Error-Cause Attribute with value 401 (Unsupported Attribute)
SHOULD be included.
If a CoA-Request packet including a Service-Type value of "Authorize
Only" is successfully processed, the NAS MUST respond with a CoA-NAK
containing a Service-Type Attribute with value "Authorize Only", and
an Error-Cause Attribute with value 507 (Request Initiated). The NAS
then MUST send an Access-Request to the RADIUS server including a
Service-Type Attribute with value "Authorize Only". This Access-
Request SHOULD contain the NAS identification attributes from the
CoA-Request, as well as the session identification attributes from
the CoA-Request legal for inclusion in an Access-Request as specified
in [RFC2865], [RFC2868], [RFC2869] and [RFC3162]. As noted in
[RFC2869] Section 5.19, a Message-Authenticator attribute SHOULD be
included in an Access-Request that does not contain a User-Password,
CHAP-Password, ARAP-Password or EAP-Message Attribute. The RADIUS
server then will respond to the Access-Request with an Access-Accept
to (re-)authorize the session or an Access-Reject to refuse to
(re-)authorize it.
3.2. State
The State Attribute is available to be sent by the RADIUS server to
the NAS in a CoA-Request packet and MUST be sent unmodified from the
NAS to the RADIUS server in a subsequent ACK or NAK packet.
[RFC2865] Section 5.44 states:
An Access-Request MUST contain either a User-Password or a CHAP-
Password or State. An Access-Request MUST NOT contain both a
User-Password and a CHAP-Password. If future extensions allow
other kinds of authentication information to be conveyed, the
attribute for that can be used in an Access-Request instead of
User-Password or CHAP-Password.
In order to satisfy the requirements of [RFC2865] Section 5.44, an
Access-Request with Service-Type="Authorize-Only" MUST contain a
State attribute.
In order to provide a State attribute to the NAS, a server sending a
CoA-Request with a Service-Type value of "Authorize-Only" MUST
include a State Attribute, and the NAS MUST send the State Attribute
unmodified to the RADIUS server in the resulting Access-Request, if
any. A NAS receiving a CoA-Request containing a Service-Type value
of "Authorize-Only" but lacking a State attribute MUST send a CoA-NAK
and SHOULD include an Error-Cause attribute with value 402 (Missing
Attribute).
The State Attribute is also available to be sent by the RADIUS server
to the NAS in a CoA-Request that also includes a Termination-Action
Attribute with the value of RADIUS-Request. If the client performs
the Termination-Action by sending a new Access-Request upon
termination of the current session, it MUST include the State
Attribute unchanged in that Access-Request. In either usage, the
client MUST NOT interpret the Attribute locally. A CoA-Request
packet must have only zero or one State Attribute. Usage of the
State Attribute is implementation dependent."
To:
"3. Attributes
In Disconnect-Request and CoA-Request packets, certain attributes are
used to uniquely identify the NAS as well as a user session on the
NAS. All NAS identification attributes included in a Request packet
MUST match in order for a Disconnect-Request or CoA-Request to be
successful; otherwise a Disconnect-NAK or CoA-NAK SHOULD be sent.
For session identification attributes, the User-Name and Acct-
Session-Id Attributes, if included, MUST match in order for a
Disconnect-Request or CoA-Request to be successful; other session
identification attributes SHOULD match. Where a mismatch of session
identification attributes is detected, a Disconnect-NAK or CoA-NAK
SHOULD be sent.
The ability to use NAS or session identification attributes to map to
unique/multiple sessions is beyond the scope of this document.
Identification attributes include NAS and session identification
attributes, as described below.
NAS identification attributes
Attribute # Reference Description
--------- --- --------- -----------
NAS-IP-Address 4 [RFC2865] The IPv4 address of the NAS.
NAS-Identifier 32 [RFC2865] String identifying the NAS.
NAS-IPv6-Address 95 [RFC3162] The IPv6 address of the NAS.
Session identification attributes
Attribute # Reference Description
--------- --- --------- -----------
User-Name 1 [RFC2865] The name of the user
associated with the session.
NAS-Port 5 [RFC2865] The port on which the
session is terminated.
Called-Station-Id 30 [RFC2865] The link address to which
the session is connected.
Calling-Station-Id 31 [RFC2865] The link address from which
the session is connected.
Acct-Session-Id 44 [RFC2866] The identifier uniquely
identifying the session
on the NAS.
Acct-Multi-Session-Id 50 [RFC2866] The identifier uniquely
identifying related sessions.
NAS-Port-Id 87 [RFC2869] String identifying the port
where the session is.
Chargeable-User- 89 [RFC4372] The CUI associated with the
Identity session. Needed where a
privacy NAI is used, because
the User-Name may not be
unique (e.g. "anonymous").
To address security concerns described in Section 6.1, either the
User-Name or Chargeable-User-Identity attribute SHOULD be present in
Disconnect-Request and CoA-Request packets.
Where a Diameter client utilizes the same Session-Id for both
authorization and accounting, inclusion of an Acct-Session-Id
Attribute in a Disconnect-Request or CoA-Request can assist with
Diameter/RADIUS translation, since Diameter RAR and ASR commands
include a Session-Id AVP. An Acct-Session-Id attribute SHOULD be
included in Disconnect-Request and CoA-Request packets.
Where the Acct-Session-Id Attribute is not present in a CoA-Request
or Disconnect-Request, it is possible that the User-Name or
Chargeable-User-Identity attributes will not be sufficient to
uniquely identify the session (e.g. if the same user has multiple
sessions on the NAS, or the privacy NAI is used). As a result, one
or more of the Acct-Multi-Session-Id, Called-Station-Id, Calling-
Station-Id, NAS-Port and NAS-Port-Id attributes MAY be used as
additional session identification.
To address security concerns described in Section 6.2, one or more of
the NAS-IP-Address or NAS-IPv6-Address Attributes SHOULD be present
in Disconnect-Request and CoA-Request packets; the NAS-Identifier
Attribute MAY be present.
A Disconnect-Request MUST contain only NAS and session identification
attributes. If other attributes are included in a Disconnect-
Request, implementations MUST send a Disconnect-NAK; an Error-Cause
Attribute with value "Unsupported Attribute" MAY be included."
3.1. Proxy State
If there are any Proxy-State attributes in a Disconnect-Request or
CoA-Request received from the server, the forwarding proxy or NAS
MUST include those Proxy-State attributes in its response to the
server.
A forwarding proxy or NAS MUST NOT modify existing Proxy-State,
State, or Class attributes present in the packet. The forwarding
proxy or NAS MUST treat any Proxy-State attributes already in the
packet as opaque data. Its operation MUST NOT depend on the content
of Proxy-State attributes added by previous proxies. The forwarding
proxy MUST NOT modify any other Proxy-State attributes that were in
the packet; it may choose not to forward them, but it MUST NOT change
their contents. If the forwarding proxy omits the Proxy-State
attributes in the request, it MUST attach them to the response before
sending it.
When the proxy forwards a Disconnect or CoA-Request, it MAY add a
Proxy-State Attribute, but it MUST NOT add more than one. If a
Proxy-State Attribute is added to a packet when forwarding the
packet, the Proxy-State Attribute MUST be added after any existing
Proxy-State attributes. The forwarding proxy MUST NOT change the
order of any attributes of the same type, including Proxy-State.
Other attributes can be placed before, after or even between the
Proxy-State attributes.
When the proxy receives a response to a CoA-Request or Disconnect-
Request, it MUST remove its own Proxy-State (the last Proxy- State in
the packet) Attribute before forwarding the response. Since
Disconnect and CoA responses are authenticated on the entire packet
contents, the stripping of the Proxy-State Attribute invalidates the
integrity check - so the proxy needs to recompute it.
3.2. Authorize Only
Support for a CoA-Request including a Service-Type Attribute with
value "Authorize Only" is OPTIONAL on the NAS and RADIUS server. A
Service-Type Attribute MUST NOT be included within a Disconnect-
Request.
A NAS MUST respond to a CoA-Request including a Service-Type
Attribute with value "Authorize Only" with a CoA-NAK; a CoA-ACK MUST
NOT be sent. If the NAS does not support a Service-Type value of
"Authorize Only" then it MUST respond with a CoA-NAK; an Error-Cause
value of 405 (Unsupported Service) SHOULD be included.
A CoA-Request containing a Service-Type Attribute with value
"Authorize Only" MUST in addition contain only NAS or session
identification attributes, as well as a State Attribute. If other
attributes are included in such a CoA-Request, a CoA-NAK MUST be
sent; an Error-Cause Attribute with value 401 (Unsupported Attribute)
SHOULD be included.
If a CoA-Request packet including a Service-Type value of "Authorize
Only" is successfully processed, the NAS MUST respond with a CoA-NAK
containing a Service-Type Attribute with value "Authorize Only", and
an Error-Cause Attribute with value 507 (Request Initiated). The NAS
then MUST send an Access-Request to the RADIUS server including a
Service-Type Attribute with value "Authorize Only". This Access-
Request SHOULD contain the NAS identification attributes from the
CoA-Request, as well as the session identification attributes from
the CoA-Request legal for inclusion in an Access-Request as specified
in [RFC2865], [RFC2868], [RFC2869] and [RFC3162]. As noted in
[RFC2869] Section 5.19, a Message-Authenticator attribute SHOULD be
included in an Access-Request that does not contain a User-Password,
CHAP-Password, ARAP-Password or EAP-Message Attribute. The RADIUS
server then will respond to the Access-Request with an Access-Accept
to (re-)authorize the session or an Access-Reject to refuse to
(re-)authorize it.
3.3. State
The State Attribute is available to be sent by the RADIUS server to
the NAS in a CoA-Request packet and MUST be sent unmodified from the
NAS to the RADIUS server in a subsequent ACK or NAK packet.
[RFC2865] Section 5.44 states:
An Access-Request MUST contain either a User-Password or a CHAP-
Password or State. An Access-Request MUST NOT contain both a
User-Password and a CHAP-Password. If future extensions allow
other kinds of authentication information to be conveyed, the
attribute for that can be used in an Access-Request instead of
User-Password or CHAP-Password.
In order to satisfy the requirements of [RFC2865] Section 5.44, an
Access-Request with Service-Type="Authorize-Only" MUST contain a
State attribute.
In order to provide a State attribute to the NAS, a server sending a
CoA-Request with a Service-Type value of "Authorize-Only" MUST
include a State Attribute, and the NAS MUST send the State Attribute
unmodified to the RADIUS server in the resulting Access-Request, if
any. A NAS receiving a CoA-Request containing a Service-Type value
of "Authorize-Only" but lacking a State attribute MUST send a CoA-NAK
and SHOULD include an Error-Cause attribute with value 402 (Missing
Attribute).
The State Attribute is also available to be sent by the RADIUS server
to the NAS in a CoA-Request that also includes a Termination-Action
Attribute with the value of RADIUS-Request. If the client performs
the Termination-Action by sending a new Access-Request upon
termination of the current session, it MUST include the State
Attribute unchanged in that Access-Request. In either usage, the
client MUST NOT interpret the Attribute locally. A CoA-Request
packet must have only zero or one State Attribute. Usage of the
State Attribute is implementation dependent."