Subject: [AAA-WG]: Issue 404: NASREQ-11 Issues

From: Bernard Aboba <[email-masked]>
Date: Wed, 12 Mar 2003 11:48:19 -0800 (PST)

Issue 404: NASREQ-11 Issues
Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: March 11, 2003
Reference:
Document: NASREQ-11
Comment type: Technical
Priority: S
Section: Various
Rationale/Explanation of issue:

Section 1

"   This document describes Diameter applications that are used for AAA
   in the Network Access Server (NAS) environment."

Doesn't the document just describe a single
application? Suggested change:

"This document describes the Diameter NAS application,
which, when combined...."

Section 1.2

"1.2.  Advertising Application Support

   Diameter nodes conforming to this specification MAY advertise support
   by including the value of one (1) in the Auth-Application-Id or the
   Acct-Application-Id AVP of the Capabilities-Exchange-Request and
   Capabilities-Exchange-Answer commands [Base]."

Isn't advertisement mandatory? Shouldn't the MAY be a MUST?

Section 2

"   Unlike the RADIUS protocol [RADIUS], the Diameter protocol does not
   require authentication information to be contained in a request from
   the client. Therefore, it is possible to send a request for
   authorization only. The type of service depends upon the Auth-
   Request-Type AVP. This difference MAY cause operational issues in
   environments that need RADIUS interoperability, and it MAY be
   necessary that protocol conversion gateways add authentication
   information when transmitting to a RADIUS server."

The RADIUS protocol doesn't require authentication information to be
included in a Call-Check, so this isn't accurate. The use of a
capital MAY is inappropriate. Adding authentication information in
a gateway seems questionable security-wise. Rewrite to:

"The Diameter protocol allows authorization-only requests
depending on the Auth-Request-Type AVP, where no authentication
information is contained in a request from the client. This
capability goes beyond the Call Check capabilities described
in Section 5.6 of [RADIUS] in that no access decision is requested.

Since no equivalent capability exists in RADIUS, authorization-only
requests from a NAS implementing Diameter may not be easily
translated to an equivalent RADIUS message by a Diameter/RADIUS
gateway. For example, where a Diameter authorization-only request
cannot be translated to a RADIUS Call Check, it would be necessary
for the Diameter/RADIUS gateway to add authentication information
to the RADIUS Access Request. On receiving the Access-Reply, the
Diameter/RADIUS gateway would need to discard the access decision
(Accept/Reject). It is not clear that these translations can be
accomplished without adding significant security vulnerabilities."

Section 2.2

"A Diameter server
   informs the NAS of the maximum time allowed before re-authentication
   or re-authorization via the Authorization-Lifetime AVP [Base].  Note,
   however, that the Authorization-Lifetime AVP SHOULD NOT be used if
   the AAR message contained a NAS-IP-Address, NAS-IPv6-Address, or NAS-
   Identifier AVP since this would mean that the NAS is using RADIUS
   which does not support server-initiated re-authentication or re-
   authorization."

The 2nd sentence is correct, but it doesn't follow from the first.
The issue is not that the Diameter server informs the NAS of the
maximum time allowed; after all, this is what RADIUS does. The issue
is the ability to handle a server-initiated re-authentication or
re-authorization. This paragraph confuses the two issues. Rewrite to:

"A Diameter server
informs the NAS of the maximum time allowed before re-authentication
or re-authorization via the Authorization-Lifetime AVP [Base].
A NAS MUST re-authenticate and/or re-authorize after the period provided
by the Authorization-Lifetime AVP. Furthermore, it is possible for
Diameter servers to issue an unsolicited re-authentication and/or
re-authorization requests (e.g. Re-Auth-Request (RAR) message) to
the NAS. Upon receipt of such a message, the NAS issues a request
to re-authenticate and/or re-authorize the client.

Since RADIUS does not support server-initiated re-authentication or
re-authorization, a Diameter server SHOULD NOT attempt server-initiated
re-authentication or re-authorization for a session known to have
been initiated by a RADIUS client. Such sessions are indicated by
an AAR message containing a NAS-IP-Address, NAS-IPv6-Address or
NAS-Identifier AVP. In addition, the Authorization-Lifetime AVP SHOULD
NOT be included in an AA-Answer message relating to such a session; instead
the equivalent RADIUS attributes (e.g. Session-Timeout) SHOULD be used
instead."

Section 3.1

"   It is possible for a single session to be authorized first, then
   followed by an authentication request."

It would help to provide an example of when this would be desirable.
Unfortunately, I can't think of any.

The ABNF for AAR includes support for RADIUS attributes not allowable in
an Access-Request, including Session-Timeout, Idle-Timeout, and Class.
To avoid problems in translation, I'd avoid including these AVPs in the
ABNF.

The AAR ABNF also does not include the Proxy-State AVP, which is allowed
in a RADIUS Access Request. This is because the Proxy-Info AVP takes its
place, no?

Section 3.2

The Proxy-State attribute is not listed in the ABNF for AA-Answer. I assume
it is not supported because Proxy-Info AVP takes its place.

Section 4

"   AVPs new to Diameter have code values 256 and greater. A Diameter
   message that includes one of these AVPs MAY cause interoperability
   issues should the request traverse a AAA node that only supports the
   RADIUS protocol. However, the Diameter protocol should not be
   hampered from future developments due to the existing installed base."

The MAY doesn't need to be capitalized here. Rewrite to:

"  AVPs new to Diameter have code values 256 and greater. Diameter
   messages including one or more of these AVPs may cause interoperability
   problems should the request traverse a AAA node that only supports
   RADIUS."

One problem  that arises here is that the Diameter NAS client can't
know whether it is talking to a Diameter server or a Diameter/RADIUS
gateway, since in either case, the NAS application is advertised. Were
it to know that there was a Diameter/RADIUS gateway in the path, it
might restrict itself to "RADIUS compatibility mode".

Section 4.5

"   The Called-Station-Id AVP (AVP Code 30) is of type UTF8String, and
   allows the NAS to send in the request, the ASCII string of the phone
   number that the user called, using Dialed Number Identification
   (DNIS) or a similar technology. Note that this may be different from
   the phone number the call comes in on. It SHOULD only be present in"

The Called-Station-Id can also contain a MAC address, as in
draft-congdon-radius-8021x-23.txt. To cover this and other cases I
would change this to:

 "The Called-Station-Id AVP (AVP Code 30) is of type UTF8String, and
allows the NAS to send in the request, the ASCII string describing the layer 2
address that the user contacted to. For dialup access, this can
be a phone number, obtained using Dialed Number Identification
(DNIS) or a similar technology. Note that this may be different
from the phone number the call comes in on. For use with IEEE 802
access, the Called-Station-Id MAY contain a MAC address,
formatted as described in [Congdon]."

4.6

"   The Calling-Station-Id AVP (AVP Code 31) is of type UTF8String, and
   allows the NAS to send in the request the the ASCII string of the
   phone number that the call came from, using Automatic Number
   Identification (ANI) or a similar technology. It SHOULD only be
   present in authentication and/or authorization requests.

   If the Auth-Request-Type AVP is set to authorization-only and the
   User-Name AVP is absent, the Diameter Server MAY perform
   authorization based on this field. This can be used by a NAS to
   request whether a call should be answered based on the ANI.
"

Change to:

"The Calling-Station-Id AVP (AVP Code 31) is of type UTF8String, and
allows the NAS to send in the request the the ASCII string describing
the layer 2 address that the user connected from. For dialup access, this
is the  phone number that the call came from, using Automatic Number
Identification (ANI) or a similar technology. For use with IEEE 802
access, the Calling-Station-Id AVP MAY  contain a MAC address,
formated as described in [Congdon]. It SHOULD only be
present in authentication and/or authorization requests.

If the Auth-Request-Type AVP is set to authorization-only and the
User-Name AVP is absent, the Diameter Server MAY perform
authorization based on this field. This can be used by a NAS to
request whether a call should be answered based on the layer 2
address (ANI, MAC Address, etc.)"

4.7

As described, the Connect-Info attribute is only useful for dialup.

Change:

"   The Connect-Info AVP (AVP Code 77) is of type UTF8String and is sent
   in the AA-Request message, and indicates the nature of the user's
   connection. The connection speed SHOULD be included at the beginning
   of the first Connect-Info AVP in the message.  If the transmit and
   receive connection speeds differ, they may both be included in the
   first AVP with the transmit speed first (the speed the NAS modem
   transmits at), a slash (/), the receive speed, then optionally other
   information.

   For example, "28800 V42BIS/LAPM" or "52000/31200 V90"
"

To:

"   The Connect-Info AVP (AVP Code 77) is of type UTF8String and is sent
   in the AA-Request or ACR STOP message. When sent in the
   Access-Request it indicates the nature of the user's
   connection. The connection speed SHOULD be included at the beginning
   of the first Connect-Info AVP in the message.  If the transmit and
   receive connection speeds differ, they may both be included in the
   first AVP with the transmit speed first (the speed the NAS
   transmits at), a slash (/), the receive speed, then optionally other
   information. Examples:

   "28800 V42BIS/LAPM", "52000/31200 V90" or "11 Mbps 802.11b"

   If sent in the ACR STOP, this attribute may be used to
   summarize statistics relating to session quality. For example,
   in IEEE 802.11, the Connect-Info attribute may contain information
   on the number of link layer retransmissions. The exact format of
   this attribute is implementation specific."

Section 4.l0

"   When used by 802.1X supplicants, the service typically terminates due
   to the expiry of the Session-Timeout AVP.  The access device may then
   reauthenticate the user with a new AA-Request.  The RECOMMENDED way
   to do this in Diameter is to use the Authorization-Lifetime AVP
   rather than the Termination-Action AVP.  However, the Termination-
   Action AVP MAY be used when copied from a RADIUS Access-Accept to a
   Diameter AA-Answer by a Translation Agent."

This contradicts Section 2.2, which says that the Authorization-Lifetime
AVP SHOULD NOT be used with RADIUS clients. The only alternative is to
use Session-Timeout and Termination-Action, but that doesn't do the job,
since the meaning has been changed. This leaves a Diameter server
incapable of communicating that it would like a RADIUS client to
re-authenticate at a given interval. The suggested fix is to change
the meaning of Termination-Action so that it is compatible with RADIUS.

Section 6.1

"   The Service-Type AVP (AVP Code 6) is of type Enumerated and contains
   the type of service the user has requested, or the type of service to
   be provided.  One such AVP MAY be present in an authentication and/or
   authorization request or response. A NAS is not required to implement
   all of these service types, and MUST treat unknown or unsupported
   Service-Types as though a response with a Result-Code other than
   Diameter-SUCCESS had been received instead."

Is this the same as saying that the authentication failed?

Note also that Service-Types 15 and 16 have recently been defined by IEEE 802.11f.
Should these be included in the list?

Section 8

"If Authentication and Authorization occur in seperate transactions, the
first message should generate a START_RECORD, and the later, an
INTERIM_RECORD."

This assumes that service is begun once the authorization response is received,
correct?

I think you need to add Connect-Info to the list of Accounting AVPs.

Section 9

Why does this section include a table with NAS-Identifier,
NAS-IP-Address, NAS-IPv6-Address, etc.? This looks like it
belonged somewhere else and ended up here by mistake.

"   Note that this section uses the two terms; AVP and attribute in a
   consise manner. The former is used to signify a Diameter AVP, while
   the latter is used to signify a RADIUS attribute."

Do you mean "consistent manner"?

Section 9.1

"Therefore, a
RADIUS/Diameter Translation Agent SHOULD NOT assume to track session
state information."

I think you mean "SHOULD NOT be assumed", no?

"      - If a Message-Authenticator attribute is present, it MUST be
        checked and discarded.  The gateway system SHOULD generate and
        include a Message-Authenticator in return responses to this
        system."

I think you mean that it is checked, and if valid, then it is not included
within the Diameter message; if invalid, then the packet is silently discarded.

"      - The Diameter Origin-Host and Origin-Realm AVPs MUST be created
        and added using the information from the NAS-Identifier
        attribute, and/or the FQDN corresponding to the NAS-IP-Address
        attribute.  The AAA protocol specified in the identity would be
        set to "RADIUS"."

I think that the FQDN corresponding to the NAS-IP-Address is preferred,
if available.

"      - If the RADIUS message contains an address attribute, (e.g.
        Framed-IP-Address, Login-IP-Host, Login-IPv6-Host, NAS-IP-
        Address, NAS-IPv6-Address) it MUST be converted to the
        appropriate Diameter AVP and Address type."

Didn't we dump the idea of address type?

9.1.1

"      - The Origin-Host AVP's value is inserted in the NAS-Identifier
        attribute."

How about also supporting translation of Origin-Host AVP to
NAS-IP-Address or NAS-IPv6-Adddress?

9.4

"If this is not possible, an attribute error should be
   returned."

Not sure which protocol this is referring to. RADIUS doesn't support
error messages, and Diameter doesn't have attribute (only AVPs).

9.5.2

"   The Diameter AVP will consist of the following fields;
      Diameter Flags: V=1, M=0, P=0
      Diameter Vendor code = RADIUS VSA Vendor code
      Diameter AVP code = RADIUS VSA Vendor type code
      Diameter AVP length = length of AVP (header + data + padding)
      Diameter Data = RADIUS VSA vendor data

   If the RADIUS receiving code knows of vendor specific fields
   interpretations for the specific vendor, it may employ them to parse
   an extended AVP code or data length, Otherwise the recommended
   standard fields will be used.

   Nested Multiple vendor data fields MUST be expanded into multiple
   Diameter AVPs."

Forwarding a RADIUS Vendor-Specific AVP as non-mandatory
could be dangerous in some circumstances, such as when a
proprietary Filter or key attribute is included. I'd suggest
setting M=1 by default, unless more information is known.

13.1

"[AAATrans]    B. Aboba, J. Wood. "Authentication, Authorization and
              Accounting (AAA) Transport Profile", draft-ietf-aaa-
              transport-08, IETF work in progress, April 2002"

Latest version is -12.

Additional comments

I believe that it would be useful to talk about translation of unsolicited disconnect
or change of filters messages to their RADIUS equivalents, defined in
[DynAuth].