[AAA-WG]: RE: Issue 402: NASREQ-11 Comments
David Mitton <david@mitton.com> Wed, 18 June 2003 18:27 UTC
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19908 for <aaa-archive@lists.ietf.org>; Wed, 18 Jun 2003 14:27:44 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id E0BBB91284; Wed, 18 Jun 2003 14:27:30 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56) id AA30791287; Wed, 18 Jun 2003 14:27:30 -0400 (EDT)
Delivered-To: aaa-wg@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D00F991284 for <aaa-wg@trapdoor.merit.edu>; Wed, 18 Jun 2003 14:27:27 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id A10CB5DD97; Wed, 18 Jun 2003 14:27:27 -0400 (EDT)
Delivered-To: aaa-wg@merit.edu
Received: from c000.snv.cp.net (h008.c000.snv.cp.net [209.228.32.72]) by segue.merit.edu (Postfix) with SMTP id 06AB65DDA6 for <aaa-wg@merit.edu>; Wed, 18 Jun 2003 14:27:27 -0400 (EDT)
Received: (cpmta 20040 invoked from network); 18 Jun 2003 11:27:24 -0700
Received: from 24.61.72.177 (HELO dmitton.mitton.com) by smtp.mitton.com (209.228.32.72) with SMTP; 18 Jun 2003 11:27:24 -0700
X-Sent: 18 Jun 2003 18:27:24 GMT
Message-Id: <5.2.1.1.2.20030618142539.03b14ec0@getmail.mitton.com>
X-Sender: david@getmail.mitton.com
X-Mailer: QUALCOMM Windows Eudora Version 5.2.1
Date: Wed, 18 Jun 2003 14:27:11 -0400
To: aaa-wg@merit.edu
From: David Mitton <david@mitton.com>
Subject: [AAA-WG]: RE: Issue 402: NASREQ-11 Comments
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Sender: owner-aaa-wg@merit.edu
Precedence: bulk
Note: This was posted by me originally on 5/11/2003 1:28am,
between the notice on NASreq 12a updates, and the discussion of Issue 403.
I didn't notice it missing until recently....
It was not being forwarded to the list because of a 50K size limit on
forwarding.
The list people have raised the limit to 100K.
This is a revised repost. I've tried to shorten it anyways.
Dave.
----------------
JARI: Comments marked with "JARI:"
DJM: Responses marked with "DJM:"
major snips to document marked with "..."
Some more work is required, but I will whittle further discussions down
to active paragraphs.
JARI: We are nearing a state where this draft can be made an RFC.
However, some work still remains. Some of the main comments:
- Some keyword issues in, e.g., advertising, sending acct
messages, ...
- Some clarifications, e.g., should service still be provided
while re-auth is going on, Accounting-Realtime-Required
effects, Auth-Request default values, optionality of some AVPs
in AAA/AAR requests, EVENT_RECORD, ...
- Normative/informative nature of the old RADIUS AVP semantics
needs clarification.
- Some question marks on the semantics of the AVPs, but I'm not
sure we can do much if the old RADIUS specifications apply in
any case.
- I'd prefer sections 9.1 and 9.1.1 to be more in the usual
keyword style than in the current "example of steps that may
be followed format".
- AVP table inconsistencies wrt base.
- Some additions to the security considerations may be needed,
e.g. RADIUS translation.
- Editorial corrections
AAA Working Group Pat R. Calhoun
Internet-Draft Black Storm Networks
Category: Standards Track Glen Zorn
Cisco Systems, Inc.
David Spence
Interlink Networks, Inc.
David Mitton
Circular Logic
February 2003
Diameter Network Access Server Application
draft-ietf-aaa-diameter-nasreq-11.txt
<snip>
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1. Requirements Language . . . . . . . . . . . . . . . . . . . . 6
1.2. Advertising Application Support . . . . . . . . . . . . . . . 6
JARI: A terms section might be useful. NAS, ARAP, IPX, CHAP, PAP etc.
DJM: Not sure it's necessary. Maybe at end.
2. NAS Calls, Ports, and Sessions . . . . . . . . . . . . . . . . . 6
JARI: Looking at the contents list, it might make sense to change the
section titles from "NAS <something>" to simply "<something>"?
What do you think?
DJM: Current is a simplification from previous, every thing was NASREQ.
JARI: And I still think the contents list should be more readable...
oh well, maybe the RFC editor has to generate the contents list
anyway and maybe they use some tool that generates nice
looking, indented contents lists... Ok, I'll send you the
script for that...
DJM: received... Used this with winawk on the 12a draft.
...
1. Introduction
This document describes Diameter applications that are used for AAA
in the Network Access Server (NAS) environment. The Diameter NAS
application, when combined with the Diameter base protocol [Base],
Transport Profile [DiamTrans] EAP [DiamEAP], and CMS Security
[DiamCMS] specifications, satisfies NAS-related requirements defined
in RFC2989 [AAACriteria] and RFC3169 [NASCriteria].
Initial deployments of the Diameter protocol are expected to include
legacy systems. Therefore, this application was carefully designed to
ease the burden of protocol conversion between RADIUS and Diameter.
This is achieved by including the RADIUS attribute space, and
eliminating the need to perform many attribute translations.
This document first describes the operation of a Diamter NAS
application. Then it defines the Diameter message Command-Codes.
The following sections enumerate the AVPs used in these messages
grouped by common usage. These are Session Identification,
Authentication, Authorization, and Accounting. The Authorization
JARI: s/, and/, Tunneling, and/ DJM: done
JARI: An overall comment: Does it make sense to capitalize words
like Authorization? I think the text would read better
if it was just "authorization". But this is not my
native language... DJM: done
AVPs are further broken down by service type. Interaction and
backwards compatibility issues with RADIUS are discussed in later
sections.
1.1. Requirements Language
In this document, the key words "MAY", "MUST", "MUST NOT",
"OPTIONAL", "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be
interpreted as described in [Keywords].
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].
JARI: Why is this a MAY? I realize that the support for NASREQ is
a MAY, but if you support it why do we allow not advertising
this fact? Or is this a configuration issue?
DJM: Changed (also Bernard Issue 404, second item)
I did not write this requirement, so I'm curious
why it may have been this way for so long.
2. NAS Calls, Ports, and Sessions
The arrival of a new call or service connection at a port of a
Network Access Server (NAS) starts a Diameter NAS message exchange.
Information about the call, the identity of the user, and his
JARI: s/his/the user's/? - DJM:done
authentication information are packaged into a Diameter AA-Request
(AAR) message and sent to a server.
...
2.1. Diameter Session Establishment
When the authentication or authorization exchange completes
successfully, the NAS application SHOULD start a session context, and
MAY send an Accounting START_RECORD message [Base]. The failure to
JARI: The MAY above is a bit weak? Is this a configuration issue
again, or are NASes generally allowed to skip accounting
if they feel like it? ;-)
DJM: Yes, I've reworded this per your later comments.
Accounting should not be skipped if implemented, but the spec
doesn't require the capability either.
start a session SHOULD cause an Accounting EVENT_RECORD message.
JARI: Is there an AVP which holds the type of failure? Or are all
EVENT_RECORD messages for this particular error?
DJM: It depends on the error. At this point I am worrying about
message flow. Not AVP content.
2.2. Diameter Session Re-Authentication or Re-Authorization
The Diameter protocol allows for users to be periodically re-
authenticated and/or re-authorized. In such instances, the Session-Id
AVP in the AAR message MUST be the same as the one present in the
original authentication/authorization message. 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.
A NAS MUST re-authenticate and/or authorize after the period provided
by the server. Furthermore, it is possible for Diameter servers to
issue an unsolicited re-authentication and/or re-authorization by
issuing an Re-Auth-Request message to the NAS. Upon receipt of such a
message, the NAS is instructed to issue a request to re-authenticate
and/or re-authorize the client.
JARI: Is this always possible? I think it is possible on PPP, but
perhaps there are other access types for which it might not
be possible. Is re-auth possible on all types of WLAN
links?
DJM: Yes, this is weakly described. And yes it varies.
Open issue
JARI: While re-auth is going on, can service still be provided?
DJM: Good question. I think it will be service specific.
2.3. Diameter Session Termination
When a NAS receives an indication that a user's session is being
disconnected (e.g. LCP Terminate is received), the NAS MUST issue a
Session-Termination-Request (STR) [Base] to its Diameter Server. This
will ensure that any resources maintained on the servers is freed
appropriately.
Further, a NAS that receives a Abort-Session-Request (ASR) [Base]
MUST issue an STR if the session requested is active, and disconnect
the PPP (or tunneling) session.
Termination of the session context, MUST cause the sending of an
Accounting STOP_RECORD message [Base], if accounting is active.
JARI: Compare the above text to the MAY for sending the START_RECORD!
Perhaps the above is the right text and something similar
should be written also for START_RECORD.
DJM: Done
JARI: Shouldn't we somehow take in account also
Accounting-Realtime-Required AVP from base?
DJM: hmm... where is that AVP described? Base?
More information on Diameter Session Termination is in [Base] section
8.4.
...
3.1. AA-Request (AAR) Command
The AA-Request message (AAR), indicated by the Command-Code field set
to 265 and the 'R' bit set in the Command Flags field, is used in
order to request authentication and/or authorization for a given NAS
user. The type of request is identified through the Auth-Request-Type
AVP, and the default mode is both authentication and authorization.
JARI: Default... hmm... does this mean Auth-Request-Type AVP
is optional? Base 8.7 does not talk about this. Please
clarify. Suggestion: don't talk about defaults.
DJM: needs work/input - Still open
If Authentication is requested the User-Name attribute SHOULD be
present, as well as any additional authentication AVPs that would
carry the password information. A request for authorization only
SHOULD include the information from which the authorization will be
performed, such as the User-Name, Called-Station-Id, or Calling-
Station-Id AVPs. All requests SHOULD contain AVPs uniquely identifing
JARI: s/identifing/identifying/ - DJM: done
the source of the call, such as Origin-Host, and NAS-Port. Certain
networks MAY use different AVPs for authorization purposes. A request
for authorization will include some AVPs defined in section 6.
...
3.2. AA-Answer (AAA) Command
The AA-Answer (AAA) message, is indicated by the Command-Code field
set to 265 and the 'R' bit cleared in the Command Flags field, is
sent in response to the AA-Request message. If authorization was
requested, a successful response will include the authorization AVPs
appropriate for the service being provided, as defined in section 6.
For authentication exchanges that require more than a single round
trip, the server MUST set the Result-Code AVP to
DIAMETER_MULTI_ROUND_AUTH. An AAA message with this result code MAY
include one or more Reply-Message and MAY include zero or one State
AVPs.
If the Reply-Message AVP was present, the access device SHOULD
display the text message to the user, and MUST prompt the user for a
response. If the access device is unable to prompt the user for a
new response, which could be achieved via PAP, it MUST treat this
answer as an error, and deny access.
JARI: s/access device/network access server/g ? (the term appears
just in two places) - DJM: Rewritten
JARI: In any case, the above paragraph is pretty confusing. At first,
I read it as if the access device was the user's equipment, but
it can't be because its the NAS that should be doing the access
denial and other tasks. I believe what is meant here is that the
NAS must be able to send a protocol message to the user's device
which would result in a text message. Suggested rewrite: "If the
Reply-Message AVP was present, the NAS SHOULD send a message to
the client, instructing it to prompt the user for a response.
This can be achieved via PAP in PPP, for instance. If the NAS
is unable to achieve this, it MUST treat the AA-Answer with the
Reply-Message AVP as an error, and deny access."
DJM: done.
Message Format
<AA-Answer> ::= < Diameter Header: 265, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Auth-Request-Type }
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ User-Name ]
[ Service-Type ]
JARI: I don't understand how some of this information
can be optional. How come Service-Type, for instance,
is not always necessary? Or is the optionality due to
the original RADIUS specifications? This comment
may apply to AAR as well.
DJM: Good observation, unfortunately it's due to the multiple uses of
these messages. We don't segregate final from interim or partial, and
some information is not appropriate in all situations.
...
4. NAS Session AVPs
Diameter reserves the AVP Codes 0-255 for RADIUS functions that are
implemented in Diameter.
AVPs new to Diameter have code values 256 and greater. A Diameter
message that includes one of these AVPs MAY cause interoperability
JARI: s/AVPs MAY/AVPs represent functionality not present in RADIUS,
and may/
DJM: ummm... well the RADIUS implementation may have the function, just
in a different representation. Also at this time, it may be conceivable
to have Diameter aware RADIUS implementations. I have "improved" this
sentence along your suggestion.
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.
JARI: Delete the last sentence.
DJM: well... I was looking at fixing it, but might as well - done.
There are some RADIUS attributes that are not allowed or supported
directly in Diameter. See section 9 below for more information.
4.1. Call and Session Information
This section contains the NAS unique AVPs that are needed to identify
JARI: s/NAS unique AVPs/AVPs specific to the NAS Diameter extension/
DJM: done.
call and session context information, and allows the server to set
constraints on a session.
...
4.4. NAS-Port-Type AVP
The NAS-Port-Type AVP (AVP Code 61) is of type Enumerated and
contains the type of the port on which the NAS is authenticating the
user. This AVP SHOULD be present if the NAS uses the same NAS-Port
number ranges for different service types concurrently.
The supported values are defined in [RADIUSTypes]. The following list
is informational:
JARI: An overall comment on all old RADIUS attributes. Its good that
the list below is marked as informational and the reference
to the normative information is given. However, there seems to
values and rules in this document that do not say this. E.g.
connectinfo slash rules in 4.7. What is their status? Should
we say somewhere that for any semantics about the RADIUS
attributes, this document is informational and the normative
definition can be found from the RADIUS specifications? Or
is the intention that this specification too is normative here
and we just have verified that there are no differences?
DJM: Over the life of this document, there has been schizophrenic
efforts to either include everything and ignore the past documents. Or
defer everything to past documents. The former means that we duplicate
everything (warts and all) and attempt to set the new bar. Problems of
combatibility will result. The latter approach leaves a document full
of pointers and difficultly in patching any of the old problems. The
Normative/non-normative/Standards-Track/Informational wrinkles pop up
here too.
I have been attempting to balance the work, but pulling things forward
but leaving pointers to where they came from.
...
4.7. Connect-Info AVP
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.
JARI: Is the space mandatory separator for the optional other
information?
DJM: ??? no ikling. The text is straight out of RFC2869
Actually not all of the original was lifted. I've added some more
because of the 253+ attribute issue. This is one.
For example, "28800 V42BIS/LAPM" or "52000/31200 V90"
...
5.2. Password-Retry AVP
The Password-Retry AVP (AVP Code 75) is of type Unsigned32 and MAY be
included in the AA-Answer if the Result-Code indicates an
authentication failure. The value of this AVP indicates how many
authentication attempts a user may be permitted before being
disconnected. This AVP is primarily intended for use when the Framed-
Protocol AVP (see Section 6.9.1) is set to ARAP.
JARI: I don't understand why Pwd-Rtr is related to ARAP only.
DJM: This attribute was defined in sect 5.9 of RFC2869 for ARAP.
We could generalize it, are you making a request?
5.3. Prompt AVP
The Prompt AVP (AVP Code 76) is of type Enumerated, and MAY be
present in the AA-Answer message. When present, it is used by the NAS
to determine whether the user's response, when entered, should be
echoed.
The supported values are listed in [RADIUSTypes]. The following list
is informational:
0 No Echo
1 Echo
JARI: Hmm... this doesn't seem to apply to all service types. Or?
DJM: This section doesn't segregate by service types or give all
possible combinations.
...
6.1. Service-Type AVP
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.
JARI: s/Diameter-SUCCESS/DIAMETER_SUCCESS/g
DJM: Done. 2 Occurances found
When used in a request, the Service-Type AVP SHOULD be considered to
be a hint to the server that the NAS has reason to believe the user
would prefer the kind of service indicated, but the server is not
required to honor the hint. The following values have been defined
for the Service-Type AVP:
JARI: Question: If the user connects through some protocol, such as
PPP, how can it be changed to something else if the server
decides to send back something else? I think it is possible in
some cases, but not in general.
<DJM: Yes, Typical is ASCII dial up to SLIP conversion.>
Perhaps some words are needed to
explain that the NAS may disconnect the user if it can't start
the service in the given situation, even if it does support it.
DJM: Not sure. The situation you describe is more of a
configuration/situation error. If the service only supports particular
methods of connection, then using others should not be assumed to be
successful. If a mode shift is not possible, then the service should
fail the connection, and that is the disconnect mechanism.
In any case, I have added the following:
Furthermore, if the service specified by the server is supported, but
not compatible with the current mode of access, the NAS MUST
fail to start the session. It must also generate the appropriate
error message(s).
The complete list of defined values can be found in [RADIUS] and
[RADIUSTypes]. The following list is informational:
...
6.2. Callback-Number AVP
The Callback-Number AVP (AVP Code 19) is of type UTF8String, and
contains a dialing string to be used for callback. It MAY be used in
an authentication and/or authorization request as a hint to the
server that a Callback service is desired, but the server is not
required to honor the hint in the corresponding response.
JARI: I don't understand how the client would know the callback number.
Or is this a copy of the calling number avp?
DJM: There are many (too many!) types of callback. Some clients know
the desired number (it may not to be initiating system!) and some
callback servers allow this.
The codification of the range of allowed usage of this field is
outside the scope of this specification.
...
6.4. Idle-Timeout AVP
The Idle-Timeout AVP (AVP Code 28) is of type Unsigned32 and sets the
maximum number of consecutive seconds of idle connection allowed to
the user before termination of the session or prompt. It MAY be used
in an authentication and/or authorization request (or challenge) as a
hint to the server that an idle timeout is desired, but the server is
not required to honor the hint in the corresponding response.
JARI: Default is?
DJM: The default is none, or system specific.
...
6.10. IP Access
The AVPs defined in this section are used when the user requests, or
is being granted, access to IP. They are only present if the Framed-
Protocol AVP (see Section 6.9.1) is set to PPP, SLIP, Gandalf
proprietarySingleLink/MultiLink protocol, or X.75 Synchronous.
JARI: Add space after "proprietary" - DJM: Done.
...
7.3. Tunnel-Client-Endpoint AVP
...
If Tunnel-Medium-Type is IPv4 (1), then this string is either the
fully qualified domain name (FQDN) of the tunnel client machine, or
it is a "dotted-decimal" IP address. Conformant implementations MUST
JARI: s/Conformant/Conforming/?
DJM: delete the word, "Implementations MUST..."
support the dotted-decimal format and SHOULD support the FQDN format
for IP addresses.
If Tunnel-Medium-Type is IPv6 (2), then this string is either the
FQDN of the tunnel client machine, or it is a text representation of
the address in either the preferred or alternate form [IPv6Addr].
Conformant implementations MUST support the preferred form and SHOULD
support both the alternate text form and the FQDN format for IPv6
addresses.
If Tunnel-Medium-Type is neither IPv4 nor IPv6, this string is a tag
referring to configuration data local to the Diameter client that
describes the interface and medium-specific address to use.
7.4. Tunnel-Server-Endpoint AVP
The Tunnel-Server-Endpoint AVP (AVP Code 67) is of UTF8String, and
contains the address of the server end of the tunnel. It MAY be used
in an authorization request as a hint to the server that a specific
endpoint is desired, but the server is not required to honor the hint
in the corresponding response.
This AVP SHOULD be included in the corresponding Accounting-Request
messages, in which case it indicates the address from which the
tunnel was initiated. This AVP, along with the Tunnel-Client-Endpoint
and Session-Id AVP [Base], MAY be used to provide a globally unique
means to identify a tunnel for accounting and auditing purposes.
If Tunnel-Medium-Type is IPv4 (1), then this string is either the
fully qualified domain name (FQDN) of the tunnel client machine, or
it is a "dotted-decimal" IP address. Conformant implementations MUST
support the dotted-decimal format and SHOULD support the FQDN format
for IP addresses.
JARI: I find the SHOULD troubling for interoperability. If a NAS gets
the TSE AVP from the server in FQDN format, what should it do?
DJM: there was a time when a lightweight NAS may not implement a DNS
client.
If it cannot support it, it barfs (in the technical sense).
The Session setup fails, the service is not provided, errors are
logged. Users curse and admins figure how to to provision so it
works within the capabilities of the NAS.
If Tunnel-Medium-Type is IPv6 (2), then this string is either the
FQDN of the tunnel client machine, or it is a text representation of
the address in either the preferred or alternate form [IPv6Addr].
Conformant implementations MUST support the preferred form and SHOULD
support both the alternate text form and the FQDN format for IPv6
addresses.
If Tunnel-Medium-Type is not IPv4 or IPv6, this string is a tag
referring to configuration data local to the Diameter client that
describes the interface and medium-specific address to use.
...
7.6. Tunnel-Private-Group-Id AVP
The Tunnel-Private-Group-Id AVP (AVP Code 81) is of type UTF8String,
and contains the group Id for a particular tunneled session. The
Tunnel-Private-Group-Id AVP MAY be included in an authorization
request if the tunnel initiator can pre-determine the group resulting
from a particular connection and SHOULD be included in the
authorization response if this tunnel session is to be treated as
belonging to a particular private group. Private groups may be used
to associate a tunneled session with a particular group of users.
For example, it MAY be used to facilitate routing of unregistered IP
addresses through a particular interface. This AVP SHOULD be
included in the Accounting-Request messages which pertain to the
tunneled session.
JARI: I understand the treatment at DIAMETER level for this AVP, but I
couldn't implement anything based on the above explanation for
actually using the group information. A particular interface
may be used but is not required, for instance.
DJM: ummm... and your point? ;-)
This attribute comes from RFC 2868 and is used to (excuse me if
I don't get it technically right) to join individual links into
an existing or desired group, via a specified connection point.
Not all tunnel implementations or configurations, support this
concept or capability, hence it's non-requiredness. I'm fairly
certain that there are running uses of this (but I didn't write
one either).
...
8. NAS Accounting
Applications implementing this specification use Diameter Accounting
as defined in the Base [Base] with the addition of the AVPs in the
following section.
Accounting Request messages (ACR) SHOULD be sent after any
JARI: Earlier in the document there was some confusion about when
accounting messages should be sent.
DJM: this requires a bit more work, more comments below. This stems
from the lack of desire or work wanting to be put into an overall
description of A//accounting.
Authentication or Authorization transaction and at the end of a
Session. The Accounting-Record-Type value indicates the type of
event. All other AVPs identify the session and provide additional
information relevant to the event.
If Authentication and Authorization are contained in one message
(typical case), then one START_RECORD should be sent. If
Authentication and Authorization occur in seperate transactions, the
JARI: s/seperate/separate/g - DJM: done.
first message should generate a START_RECORD, and the later, an
INTERIM_RECORD. For a given session, there should only be one set of
matching START and STOP records, with any number of INTERIM_RECORDS
in between, or one EVENT_RECORD.
JARI: Compare to Section 2.1. I'm not sure I understand what "failure
to start a session" exactly means, but let's assume we do a
successful authentication, successful authorization, and the
"fail to start a session". It would be incorrect in this case to
send START_RECORD, INTERIM_RECORD, EVENT_RECORD, as seems to be
indicated by 2.1. Suggestion: make 2.1 inline with the text
here.
DJM: Okay, it's sort of fuzzy, as you're beginning to see.
Most NAS type applications do Authentication/Authorization in one
exchange. So a session "starts" cleanly on receipt of the AAA.
But thanks to the flexibility of Diameter this can get drawn out.
In practice, we have a session context that is initialized at
the time of the call "pickup" and it gets filled in
as we progress, until we have enough to deliver the service or not.
It's at that point that we fail or "start" service.
We got in trouble in RADIUS because some NASes would issue a
Acct-Start on a PPP session before NCP finished, and could not tell
you the IP addr of the user system. Others would delay for that,
which in turn drives the real-time people crazy.
So I agree, we should define Accounting messages linked to specific
protocol events to eliminate some implementation confusion. (there
will be other forms of confusion that arise)
This will take some more wordsmithing and proper sequence
construction. -- Open Issue
</DJM>
...
9. RADIUS/Diameter Protocol Interactions
This section describes some basic guidelines that may be used by
servers that act as AAA Translation Agents. A complete description of
all the differences between RADIUS and Diameter is beyond the scope
of this section and document. Note that this document does not
restrict implementations from creating additional methods, as long as
the translation function doesn't violate the RADIUS or the Diameter
protocols.
+---------------------+
| AVP Flag rules |
|----+-----+----+-----|----+
AVP Section | | |SHLD| MUST| |
Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr|
-----------------------------------------|----+-----+----+-----|----|
NAS-Identifier 32 9.2.1 UTF8String | M | P | | V | Y |
NAS-IP-Address 4 9.2.2 OctetString| M | P | | V | Y |
NAS-IPv6-Address 95 9.2.3 OctetString| M | P | | V | Y |
State 24 9.2.4 OctetString| M | P | | V | Y |
Termination- 295 9.2.5 Enumerated | M | P | | V | Y |
Cause | | | | | |
-----------------------------------------|----+-----+----+-----|----|
JARI: This table is not explained by the nearby text.
DJM: Every major section has a table of Diameter AVPs in it. I will add
this sentence:
The following Diameter AVPs pertain to RADIUS interactions and are
described in this section:
There are primarily two different situations that must be handled;
one where a RADIUS request is received that must be forwarded as a
Diameter request, and the inverse. RADIUS does not support a peer-
to-peer architecture and server initiated operations are generally
not supported. See [RADDynAuth] for an alternative.
Some RADIUS attributes are encrypted. RADIUS security and encryption
techniques are applied on a hop-per-hop basis. A Diameter agent will
have to decrypt RADIUS attribute data entering the Diameter system
and if that information is forwarded, MUST secure it using Diameter
specific techniques.
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
JARI: Replace the first sentence with "Note that this section uses two
different terms, AVP and attribute."
DJM: Not sure the improvement you were after. How about this:
Note that this section uses the two terms; "AVP" and "attribute" in
a concise and specific manner. The former is used to signify a
Diameter AVP,...
the latter is used to signify a RADIUS attribute.
...
The corresponding Diameter response is always guaranteed to be
received by the same Translation Agent that translated the original
request, due to the contents of the Origin-Host AVP in the Diameter
request. The following steps are applied to the response message
during the Diameter to RADIUS translation:
- If the Diameter Command-Code is set to AA-Answer and the Result-
Code AVP is set to DIAMETER_MULTI_ROUND_AUTH, the gateway must
send a RADIUS Access-Challenge with the Diameter Session-Id and
the Origin-Host AVPs encapsulated in the RADIUS State attribute,
with the prefix "Diameter/". This is necessary in order to
ensure that the Translation Agent that will receive the
subsequent RADIUS Access-Request will have access to the Session
Identifier, and be able to set the Destination-Host to the
correct value. If the Multi-Round-Time-Out AVP is present, the
value of the AVP MUST be inserted in the RADIUS Session-Timeout
AVP.
- If the Command-Code is set to AA-Answer, the Diameter Session-Id
AVP is saved in a new RADIUS Class attribute, whose format
consists of the string "Diameter/" followed by the Diameter
Session Identifier. This will ensure that the subsequent
Accounting messages, which could be received by any Translation
Agent, would have access to the original Diameter Session
Identifier.
- If a Proxy-State attribute was present in the RADIUS request,
the same attribute is added in the response. This information
may be found in the Proxy-Info AVP group, or in a local state
table.
- If state information regarding the RADIUS request was saved in a
Proxy-Info AVP or local state table, the RADIUS Identifier and
UDP IP Address and port number are extracted and used in issuing
the RADIUS reply.
JARI: Question: Does the above rules work even in a situation where
there's been a change to another translation agent due to
load balancing or a fault?
DJM: Groan... I don't know, I didn't design this part - Open Issue
9.1.1. Diameter Request Forwarded as RADIUS Request
JARI: This should be 9.2 not a subsection of RADIUS->DIAMETER!
DJM: whoops, must fix table or two and some cross references then
When a server receives a Diameter request that is to be forwarded to
a RADIUS entity, the following steps are an example of the steps that
may be followed:
JARI: "... example of the steps that may be followed... " are we sure
that we can't create normative keyword language for these
operations?
- The Origin-Host AVP's value is inserted in the NAS-Identifier
attribute.
- The following information MUST be present in the corresponding
Diameter response, and therefore MUST be saved either in a local
state table, or it MAY be encoded in a RADIUS Proxy-State
attribute:
1. Origin-Host AVP
2. Session-Id AVP
3. Proxy-Info AVP
4. Route-Record AVPs (in the proper order)
5. Any other AVP that MUST be present in the response, and
has no corresponding RADIUS attribute.
- If the CHAP-Auth AVP is present, the grouped AVPs are used to
create the RADIUS CHAP-Password attribute data.
- If the User-Password AVP is present, the data should be
encrypted using RADIUS rules. Likewise for any other encrypted
attribute values.
- AVPs that are of the type Address, must be translated to the
corresponding RADIUS attribute.
- If the Accounting-Input-Octets, Accounting-Input-Packets,
Accounting-Output-Octets or Accounting-Output-Packets AVPs are
present, these must be translated to the corresponding RADIUS
attributes. Further, the value of the Diameter AVPs do not fit
within a 32-bit RADIUS attribute, the RADIUS Acct-Input-
Gigawords and Acct-Output-Gigawords must be used.
- If the RADIUS link supports the Message-Authenticator attribute
[RADIUSExt] it SHOULD be generated and added to the request.
When the corresponding response is received by the Translation Agent,
which is guaranteed in the RADIUS protocol, the following steps may
be followed:
- If the RADIUS code is set to Access-Challenge, a Diameter AA-
Answer message is created with the Result-Code set to
DIAMETER_MULTI_ROUND_AUTH. If the Session-Timeout AVP is present
in the RADIUS message, its value is inserted in the Multi-Round-
Time-Out AVP.
- If a Proxy-State attribute is present, extract the encoded
information, otherwise retrieve the original Proxy-Info AVP
group information from the local state table.
- The request's Origin-Host information is added to the
Destination-Host AVP.
- The Acct-Session-Id information is added to the Session-Id AVP.
- The Route-Record AVPs MUST be added to the Diameter message, in
the same order they were present in the request.
- If a Proxy-Info AVP was present in the request, the same AVP
MUST be added to the response.
- If the RADIUS State attributes are present, these attributes
must be present in the Diameter response.
- Any other AVPs that were saved, and MUST be present in the
response, are added to the message.
9.2. AVPs Used Only for Compatibility
...
9.2.4. State AVP
The State AVP (AVP Code 24) [RADIUS] is of type OctetString and has
two uses in the Diameter NAS application.
The State AVP MAY be sent by a Diameter Server to a NAS in an AA-
Response command that contains a Result-Code of
DIAMETER_MULTI_ROUND_AUTH. If so, the NAS MUST return it unmodified
in the subsquent AA-Request command.
JARI: s/subsquent/subsequent/g - DJM: done.
...
9.3. Prohibited RADIUS Attributes
The following RADIUS attributes MUST NOT be transfered to a Diameter
message. Many of these are discussed in section 9.1.
JARI: I spent some time reading the previous sections and trying to
figure out what "transferred" meant above. Apparently, it means
that they must not appear in a diameter message and must be
translated instead to some other Diameter AVPs. They are not
completely forbidden. Suggested reformulation: "The following
RADIUS attributes MUST NOT appear in a Diameter
message. Instead, they are translated to other Diameter AVPs or
handled in some special manner. The rules for the treatment of
the attributes are discussed in Sections 9.1 and 9.5."
DJM: Excellent, done. modulo section reference changes
Attribute Description Defined Nearest Diameter AVP
-----------------------------------------------------------------
3 CHAP-Password RFC 2865 CHAP-Auth Group
26 Vendor-Specific RFC 2865 Vendor Specific AVP
40 Acct-Status-Type RFC 2866 Accounting-Record-Type
42 Acct-Input-Octets RFC 2866 Accounting-Input-Octets
...
10.1. AA-Request/Answer AVP Table
The table in this section is limited to the Command Codes defined in
this specification.
JARI: I don't understand the above comment. Remove?
DJM: Sorry, had to add that to fend off someone else's problem with this
table. Perhaps I need to spend more/different text on this.
...
10.2.1. Accounting Framed Access AVP Table
The table in this section is used when the Service-Type specifies
Framed Access.
+-----------+
| Command |
|-----+-----+
Attribute Name | ACR | ACA |
---------------------------------------|-----+-----+
Accounting-Application-Id | 0-1 | 0-1 |
JARI: No such AVP in base or nasreq...
DJM: Yes, but there probably was at one time, and there is an
Acct-Application-Id also listed below. Seems to be an editing error. Most
Diameter Accounting AVPs spell out "Accounting" but this one is of the few
exceptions.
Accounting-Input-Octets | 1 | 0 |
Accounting-Input-Packets | 1 | 0 |
Accounting-Output-Octets | 1 | 0 |
Accounting-Output-Packets | 1 | 0 |
Accounting-Record-Type | 1 | 1 |
Accounting-Record-Number | 0-1 | 0-1 |
Accounting-Realtime-Required | 0-1 | 0 |
Accounting-Sub-Session-Id | 0-1 | 0-1 |
Acct-Application-Id | 0-1 | 0-1 |
JARI: I don't fully understand the construction of this table
vs. the one in the base spec. The above attribute,
for instance, is included but not discussed in this
specification. But some other base attributes such
as Auth-Application-Id are not included. Is this
an old version of the base table, with the NASREQ
additions? May I suggest taking a new version from
base-17...?
DJM: ...moving targets aren't always hit. (or stay hit)
I checked everything against Base-16? at the time.
If there are further changes, I need to know.
The BASE does not describe this application, I must.
This application uses Base AVPs, how it uses them (not what they
are) must be described here, even if it's just an inclusion that
says it's allowable. I guess more verbage is required to make
these tables self explanatory.
...
11.2. AVP Codes
This specification assigns the values 363-366 and 400-405 from the
AVP Code namespace defined in [Base]. See sections 4, and 5 for the
assignment of the namespace in this specification. Note that the
values 363-366 are jointly, but consistently, assigned in [DiamMIP].
This specification also specifies the use of AVPs in the 0-255 range,
which are defined in [RADIUSTypes]. These values are assigned by the
policy in RFC 2865 Section 6. [RADIUS]
JARI: I can't find a statement either in this document or in the base
that would say something about the attribute lengths for the
0-255 AVPs. Presumably, 253 bytes may not be exceeded, or at
least if it is, translation agents will fail? No wait... 9.4
has some text. But unfortunately it doesn't describe for which
attributes the concatenation approach is possible. Add a list
there.
DJM: grrr... okay, but this is getting near exceding the scope of
this document. I cannot re-document RADIUS.
11.3. Application Identifier
...
12. Security Considerations
The security considerations of the Diameter protocol itself have
been discussed in [Base].
This document does not contain a security protocol, but does discuss
how PPP authentication protocols can be carried within the Diameter
protocol. The PPP authentication protocols that are described are PAP
and CHAP.
The use of PAP SHOULD be discouraged, since it exposes user's
passwords to possibly non-trusted entities. However, PAP is also
frequently used for use with One-Time Passwords (OTP), which do not
expose a security risk.
This document also describes how CHAP can be carried within the
Diameter protocol, which is required for RADIUS backward
compatibility. The CHAP protocol, as used in a RADIUS environment,
facilitates authentication replay attacks.
JARI: Any references to the attacks discussed above?
JARI: Maybe there should be some discussion of what it implies
if authorization-only AAA requests are made, and in which
cases such usage is safe.
DJM: Submissions are welcome.
JARI: What are the security impacts of RADIUS-DIAMETER translation?
Are all or only some of the known radius vulnerabilities carried
onto DIAMETER in such a setup? See reference "Joshua Hill. An
Analysis of the RADIUS Authentication Protocol.
http://www.untruth.org/~josh/security/radius/, 2001."
DJM: I have read that document in the past, however, we have tried
to document the Diameter NAS Application protocol in this document, and
avoided including a full treatis on Diameter/RADIUS how-to build a
gateway. This really requires another document. If I could make it
relate to my job (what's that?) I'd write it myself.
...
Intellectual Property Considerations
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to per-
tain to the implementation or use of the technology described in this
JARI: Why does this section have hyphenation on???
DJM: It does not. However, the source text was cut and pasted from
another document which had the one split word. Identification of the source
is an exercise left to the reviewer. (hint: ends in -17)
((and certainly don't look at the Full Copyright statement in that
document, it has 3 hypenated split words)
...
- [AAA-WG]: RE: Issue 402: NASREQ-11 Comments David Mitton