Issue 301: Securing the AAAH-generated session
keys
Submitter name: Bob Kopacz
Submitter email
address:bkopacz@interlinknetworks.com
Date first submitted: 03-05-2002
Reference:
Document: draft-mobileip-09
Comment type: Technical
Priority: 1
Section:
Rationale/Explanation of issue:
The
draft-mobileip-09 was updated per issue#266.Issue#266
addressed the case
where the HA was in a foreign network, the
destination AAAF generated the
FA-HA key, and the destination AAAF
wanted to use CMS to return the key to
the FA in a secure manner.
Because the mobility agents may not support CMS
(CMS is a SHOULD for
clients but a MUST for servers), the issue#266 solution
was for the
destination AAAF (i.e. the HA's AAAF) to set up a DSA with
the
originating AAAF (i.e. the FA's AAAF), and to pass the
CMS-encrypted
FA-HA key to the originating AAAF within a CMS-Encrypted-Data
AVP.
The key is thus hidden as it traverses the home domain and
any
intermediary proxy/relay AAA servers.
Issue#266 was retricted to
the case of CMS-securing the
AAAF-generated session key.There is a similar
need to CMS-secure
the AAAH-generated session keys, if there are intervening
proxy
networks between the home network and the mobility agent's
network.
The proposal here is for an AAAH who wants to CMS-secure
its
generated session keys, to set up a DSA with the mobility
agent's
local AAAF, and to pass the CMS-secured keys to the AAAF a
la
issue#266.
AAAH-generated keys destined for the FA: An
AAAH-generated FA-MN key
(and maybe an AAAH-generated FA-HA key) is returned
to the FA in the
AMA, which possibly traverses intermediary proxies.The AAAH
can
CMS-secure these keys by setting up a DSA with the FA's local
AAAF,
and passing the CMS-encrypted keys to the AAAF a la
issue#266.The
AAAH knows the identity of the originating AAAF because this
is
kindly provided in the AMR's MIP-Originating-Foreign-AAA
AVP.
AAAH-generated keys destined for a foreign HA: The
AAAH-generated
HA-MN key is forwarded in the HAR to the HA.If the HA resides
in a
foreign network, the HAR may traverse intermediary proxies, and
the
AAAH may want to CMS-secure this key.Unfortunately the AAAH
doesn't
necessarily know who the destination AAAF is.The problem
here is that the
AAAH wants to set up the DSA before forwarding the
HAR which carries the
encrypted keys.In this case, I am currently
stuck and soliciting
suggestions.(One goofy notion, whose only
virtue is that it works, is this:
The AAAH sends a "half-baked" HAR
which doesn't contain the keys.The AAAF
receives this half-baked
HAR, extracts the AAAH's identity from the
half-baked HAR, sets up a
DSA with the AAAH, who resends a fully-baked HAR
with the
CMS-encrypted keys.Unfortunately, this entails another
round
trip.)
Requested change:
In section 5.0Key
Distribution Center
> 5.0Key Distribution Center
>
>
[...]
>
> If the AAAH does not communicate directly with the
foreign agent, and
> it does not wish for intermediate proxies to have
access to the
> session keys, they SHOULD be protected using the CMS
security
> application [CMS].
Change the first sentence to
:
"If the AAAH does not communicate directly with one or both
mobility
agents,..."
- - -
In section5.2Key Material vs. Session
Key
> 5.2Key Material vs. Session Key
>
> [...]
>
> The session keys destined for mobility agents may be encoded
using
> the security association available between the AAA server and
the
> agents (e.g. IPSec, TLS, CMS).
Change the above sentence
to:
"The session keys destined for mobility agents may be encoded
using
the security association available between the AAA server and
the
agents (e.g. IPSec, TLS, CMS), or, if the AAAH suspects a
foreign
mobility agent doesn't support CMS, by using the
security
association available between the AAAH and the AAA server
hosting
the mobility agent."
- - -
In section 5.3Distributing
the Mobile-Home Session Key
> 5.3Distributing the Mobile-Home Session
Key
>
[Need some text here to address the case where the HA is in
a foreign
network, the HA doesn't support CMS, and the AAAH wants to set up
a
DSA with the destination AAAF, and pass the CMS-encrypted HA-MN key
to
the destination AAAF.]
- - -
In section 5.4Distributing the
Mobile-Foreign Session Key
> 5.4Distributing the Mobile-Foreign
Session Key
>
> The Mobile-Foreign session key material is also
generated by AAAH
> (upon request) and is added to the MIP-MN-to-FA-Key
AVP, which is
> added to the HAR, and copied by the home agent into a
Generalized MN-
> FA Key Reply Extension [MIPKEYS] to the Mobile IP
Registration Reply
> message, using the SPI proposed by the Mobile Node in
the MN-FA Key
> Request From AAA Subtype extension. Further, the home
agent includes
> the SPI in the HAA's MIP-FA-to-MN-SPI AVP. The AAAH
includes the
> session key in the MIP-FA-to-MN-Key AVP in the HAA, which
contains
> the session key used by the foreign agent in the computation of
the
> Mobile-Foreign authentication extension.
>
> Upon
receipt of the HAA, the Diameter server responsible for key
> allocation
creates the MIP-FA-to-HA Key AVP, using the SPI in the
> MIP-FA-to-HA-SPI.
If the key is generated at the AAAF (home agent in
> foreign domain), it
adds the MIP-FA-to-HA Key AVP to the HAA and
> sends it to the AAAH.
Depending upon where the HA was located the
> AAAH either generates the
MIP-FA-to-HA Key AVP itself or extracts the
> AVP from the HAA sent by the
AAAF. The AAAH adds the MIP-FA-to-HA Key
> to the AMA.If the
MIP-FA-to-MN-Key AVP was present in the AMA, the
> foreign agent MUST
include the Mobile-Foreign authentication
> extension in the Registration
Reply, using the newly distributed key.
Append the following
paragraph:
"If the AAAH is returning an FA-HA or FA-MN key to the FA, and
the
AAAH wants to secure these keys because the originating AAAF is not
a
peer (there are intermediate proxies), the AAAH first sets up a
DSA with the
originating AAAF, and passes the FA's key(s) within a
CMS-Encrypted-Data AVP
in the AMA."
Further notes from Tony:
Date: Sun, 24 Mar 2002 23:30:03 -0800
From: Tony Johansson
<tony.johansson@ericsson.com>
To: aaa-wg
<aaa-wg@merit.edu>
Cc: Bob Kopacz
<BKopacz@InterlinkNetworks.com>, Fredrik Johansson
<fredrik.johansson@ipunplugged.com>,
Johan Johansson
<johanj@ipunplugged.com>, David Spence
<DSpence@InterlinkNetworks.com>,
Pat R. Calhoun
<pcalhoun@bstormnetworks.com>
Subject: [AAA-WG]: Issue 299 and
#301
All,
During, the AAA working group meeting at IETF53 I
presented the issues #299 and
#301 and two alternative ways in which we could
workout a solution to the open
issues - see below:
Alt1:
Clarifications / new requirements without any new dependencies to
MIP.
------------------------------------------------------------------------------
AAAH
-
Require that each subdomain of a realm is authorized/authenticated by
exactly
one AAAH. So while a home network may have multiple AAAH's, each
subdomain will
have exactly one AAAH.
- Or, require that, if the home
realm has multiple AAA servers to which the same
user can be routed to, then
there MUST be a synchronization
mechanism between the AAAH servers. However,
the specific synchronization
mechanism is beyond the scope of this
spec.
AAAF
- How to map HA IP address to HA FQDN is still open.
Reverse DNS look up is not
at all a straightforward solution for
this
Alt 2: New dependencies to MIP, by requiring the usage of the GNAIE
draft.
-----------------------------------------------------------------------------
AAAH
-
Require that the MN support the GNAIE draft, updated to include the
definition
of a AAAH NAI. When sending a MIP RegReq, this AAAH NAI
would
be included to guarantee that a registered user always ends up in the
same
initial AAAH.
AAAF
- The mapping of the HA IP address and HA
FQDN, Host and realm would be
automatically solved, since this would be
included in the MIP RegReq as well.
There was a very clear and strong
consensus that alternative 2 would be by far
the best solution. However, this
means more work and dependencies
to the MIP working group and the goal is set
to have the Diameter MIPv4 appl.
draft in working group last call by the
April 2nd. Looking at the
GNAIE draft, I done see that much work needs to be
done to make it fulfill our
needs, so to me it could easily be done in time,
but the big
question is how quickly could it be pushed through the MIP
working group and go
to last call? I have sent the question MIP wg and I hope
to soon get answer
back.
Regards,
Tony
Issue 302: Combine occurrence rules tables with
message ABNF
Submitter name: Bob Kopacz
Submitter email
address:bkopacz@interlinknetworks.com
Date first submitted: 03-05-2002
Reference:
Document: all drafts
Comment type: Technical
Priority:
1
Section:
Rationale/Explanation of issue:
1. There are
often conflicts between the message ABNF and the
[redundant] information in
the occurrence rules tables.Combining
the message ABNF with the occurrence
rules would create one location
for the message AVP occurrence information,
and eliminate the
redundancies and neverending conflicts.
2. The
current ABNF is a little tricky, in that the default number
of occurrences
depends on the type of braces around the AVPs.So
replace the <nulls>
and the *'s with the explicit counts as in the
occurrence rules, e.g. 0, 0+,
0-1, etc.Then we don't need both the
{}braces and the []braces, as the
numeric counts indicate required
versus optional.
For example, the
current ABNF for the AA-Mobile-Node-Request is:
>
<AA-Mobile-Node-Request> ::= < Diameter Header: 260, REQ, PXY
>
>< Session-Id >
>{ Auth-Application-Id }
>{
User-Name }
>{ Destination-Realm }
>{ Origin-Host }
>{
Origin-Realm }
>{ MIP-Reg-Request }
>{ MIP-MN-AAA-Auth }
>[
Destination-Host ]
>[ Origin-State-Id ]
>[ MIP-Mobile-Node-Address
]
>[ MIP-Home-Agent-Address ]
>[ MIP-Feature-Vector ]
>[
MIP-Originating-Foreign-AAA ]
>[ Authorization-Lifetime ]
>[
Auth-Grace-Period ]
>[ Auth-Session-State ]
>[ MIP-FA-Challenge
]
>[ MIP-Candidate-Home-Agent-Host ]
>* [ AVP ]
>* [
Proxy-Info ]
>* [ Route-Record ]
The occurrence rule tables could
be absorbed into the message ABNF
(and eliminated), with a message ABNF that
looks like:
> <AA-Mobile-Node-Request> ::= < Diameter Header:
260, REQ, PXY >
>1 < Session-Id >
>1 [ Auth-Application-Id
]
>1 [ Destination-Realm ]
>1 [ MIP-Reg-Request ]
>1 [
MIP-MN-AAA-Auth ]
>1 [ Origin-Host ]
>1 [ Origin-Realm ]
>1 [
User-Name ]
>0-1 [ Authorization-Lifetime ]
>0-1 [ Auth-Grace-Period
]
>0-1 [ Auth-Session-State ]
>0-1 [ Accounting-Multi-Session-Id
]
>0-1 [ Destination-Host ]
>0-1 [ MIP-Candidate-Home-Agent-Host
]
>0-1 [ MIP-Originating-Foreign-AAA ]
>0-1 [ MIP-FA-Challenge
]
>0-1 [ MIP-Feature-Vector ]
>0-1 [ MIP-Home-Agent-Address
]
>0-1 [ MIP-Mobile-Node-Address ]
>0-1 [ Original-State-Id
]
>0+[ Proxy-Info ]
>0+[ Route-Record ]
>0 [
Acct-Application-Id ]
>0 [ Error-Message ]
>0 [ Error-Reporting-Host
]
>0 [ MIP-FA-to-HA-Key ]
>0 [ MIP-FA-to-HA-SPI ]
>0 [
MIP-FA-to-MN-Key ]
>0 [ MIP-FA-to-MN-SPI ]
>0 [ MIP-Filter-Rule
]
>0 [ MIP-Foreign-Agent-Host ]
>0 [ MIP-HA-to-FA-Key ]
>0 [
MIP-HA-to-MN-Key ]
>0 [ MIP-Key-Lifetime ]
>0 [ MIP-MN-to-FA-Key
]
>0 [ MIP-MN-to-HA-Key ]
>0 [ MIP-Reg-Reply ]
>0 [
Redirect-Host ]
>0 [ Redirect-Host-Usage ]
>0 [
Redirect-Max-Cache-Time ]
>0 [ Result-Code ]
>0 [
Re-Auth-Request-Type ]
>0 [ Session-Timeout ]
>0+[ AVP ]
3.
This is not a significant change to the drafts.
Requested
Change:
Do this in all the Diameter drafts.
Issue 303: Security model for peer discovery and
redirect
Submitter name: David Spence
Submitter email address:
DSpence@Interlinknetworks.com
Date first submitted: March 6,
2002
Reference:
Document: Base
Comment type: T
Priority:
S
Section:
Rationale/Explanation of issue:
While I haven't studied
studied base-10 in great detail yet, I
believe there are still significant
security issues with peer-to-peer
connections that need to be
addressed.
Two of the models for using Diameter that I'm not
particularly
thrilled with and admittedly haven't devoted a whole lot of
thought
to in the past are the peer discovery and redirect
models.
Nevertheless, it is extremely important that if we include
these
models in Diameter, we need to make them work.The thing that both
of
these models share is that peer-to-peer connections are
created
dynamically.This raises two problems.The first is, what makes
the
connection originator feel comfy about seeking to establish
the
connection?The second is, what makes the connection recipient
feel
comfy about accepting the connection?
Consider the redirect
model.If Bob@donut.com dials in to
wondernet.net, the wondernet AAA server,
aaaf.wondernet.net, sends an
authentication/ authorization request to his
redirect agent,
aaa.omniscient.com.Aaa.omniscient.com redirects him
to
aaah.donut.com.Aaaf.wondernet.net is comfy because he
trusts
aaa.omniscient.com.Aaah.donut.com receives a CER
from
aaaf.wondernet.net.Perhaps aaa.omniscient.com trusts
aaah.donut.com,
too.But that doesn't help him because the CER has
nothing in it even claiming
that the connection is being created
because of a redirect from
aaa.omniscient.com, let alone proving it.
-->(1)A major weakness with
the redirect model is that the recipient
does not even know who made the
referral.
Now consider the server discovery model. Bob@donut.com dials in
to
wondernet.net, and the wondernet AAA server, aaaf.wondernet.net, does
a
DNS lookup to discover that the AAA server for donut.com
is
aaah.donut.com.What good does that do aaaf.wondernet.net?How
does
aaaf.wondernet.net even know whether wondernet and donut have
a
business relationship?If they do have a business relationship, then
why
is it so hard to configure aaah.donut.com into
aaaf.wondernet.net's peer
table?So what good is peer discovery?
-->(2)A problem with peer
discovery is that a server doing it must
have an independent means of
knowing what realms it may make
peer connections to.
Assuming
aaaf.wondernet.net does have enough configuration
information to feel comfy
establishing a peer-to-peer connection with
aaah.donut.com, we still have
the same problem with had with the
redirect model: How does aaah.donut.com
know it's o.k. to receive a
connection from aaaf.wondernet.net?
In
either model, if a Diameter server receives a CER from a Diameter
node that
is not hard configured into its peer table, then we need to
ensure that some
form of peer-to-peer security is in place.It
cannot assume that such a
connection is IPsec protected.So it must
insist on TLS.But this is nowhere
stated.
-->(3)A Diameter node receiving a CER request from another
Diameter
node that is not hard configured into its peer table MUST
reject the CER if it does not arrive on a TLS-secured transport
connection.
Some may assume that the successful establishment of a
TLS connection
provides sufficient warm fuzzies to both parties to the
connection
for them to want to bring up a peer-to-peer link and transfer
Diameter messages over it.I am not convinced that that is a
reasonable
assumption except perhaps in some very constrained cases.
These constraints
need to be fully described in the security
considerations
section.
-->(4)The limitations in the use of TLS to establish trust
need to be
understood and clearly stated.
Requested
change:
I think the usefulness of the redirect and server discovery
models
ought to be reexamined in light of the security problems they
introduce.It may be that removing redirect and server discovery
from
Diameter is the best solution.
If the working group believes that
redirect and server discovery are
really needed and still useful when
constrained to operate securely,
then their use needs to the subject of a
genuine security analysis.
These capabilities are not present in RADIUS and
they greatly
complicate peer-to-peer security.In RADIUS a node will only
exchange messages with other nodes with which it is configured to
communicate.If Diameter introduces dynamic peer-to-peer
connections, a
new trust model must be created or else the entire AAA
infrastructure is at
risk.
Issue 304: Allowance for temporary peer
connections
Submitter name: Ghadiyaram Venkata, David Spence
Submitter
email address: Ext-Venkata.Ghadiyaram@nokia.com,
DSpence@Interlinknetworks.com
Date first submitted: March 6,
2002
Reference:
Document: Base
Comment type: T
Priority:
1
Section:
Rationale/Explanation of issue
A CER received from a
previously unknown peer (such as would happen as a
result of peer discovery
or a redirect) does not contain complete
information as to how the recipient
could recreate the peer connection if it
is lost.
Requested
change:
Add the following text:
"If a CER from and unknown peer is
answered with a successful CEA, the
lifetime of the peer entry is equal to
the lifetime of the transport
connection. In case of a transport failure, all
the pending transactions
destined to the unknown peer can be discarded."
Issue 305: Purpose of MIP-Foreign-Agent-Host
Submitter name: Johan Johansson
Submitter email address:
johanj@ipunplugged.com
Date first submitted: March 10,
2002
Reference:
Document: Mip
Comment type: T
Priority:
2
Section: 4.8 + ABNFs and occurence rules
Rationale/Explanation of
issue
The MIP-Foreign-Agent-Host avp is mandatory in both the HAR and the
HAA.
The only text covering this avp is
The MIP-Foreign-Agent-Host
AVP (AVP Code 330) is of type
DiameterIdentity and contains the identity of
the foreign agent. This
AVP is copied from the value of the Origin-Host AVP
in the AMR.
If we start with its presence in the HAA, this can't possibly
serve any
purpose since the AAAH already knows the identity of the FA. It
was
after all the one who sent it to the HA in the first place.
But
why would the HA want it at all and badly enough for it to be
mandatory in
the HAR at that? The avp is of type DiameterIdentity which
is a strong
indication that it is for the consumption of a Diameter
entity and not a
mobile ip entity. If the mobile node is supposed to
carry this information
for some reason there is ample opportunity for
the FA to provide it directly
to the mobile node.
The avp is not present in accounting
messages.
I am quite ignorant about CMS, but it seems unlikely that the
HA could
have a conceivable need to establish a DSA with the FA.
The
avp must come from somewhere though since it must have been actively
introduced. Can someone please shed some light on why it was
defined?
Requested change:
Explain the avp's use or remove
it.
j
Issue 306: Session-Timeout vs
Authorization-Lifetime vs MIP-Key-Lifetime
Submitter name: Johan
Johansson
Submitter email address: johanj@ipunplugged.com
Date first
submitted: March 11, 2002
Reference:
Document: Mobile IP
Comment type:
T
Priority: 1
Section: 2.2, 2.3, 5.1, 8.1
Rationale/Explanation of
issue:
If there is to be any hope for interoperability the use
of
Session-Timeout must be defined in the MIP draft.
The base draft
defines Session-Timeout as
8.13 Session-Timeout AVP
The
Session-Timeout AVP (AVP Code 27) [RADIUS] is of type Unsigned32
and contains
the maximum number of seconds of service to be provided
to the user before
termination of the session. When both the Session-
Timeout and the
Authorization-Lifetime AVPs are present in an answer
message, the former MUST
be equal to or greater than the value of the
latter.
---
A
Session-Timeout AVP MAY be present in a re-authorization message,
and
contains the number of seconds from the beginning of the re-auth.
A value
of zero, or the absence of this AVP, means that this session
has an unlimited
number of seconds before termination.
Section 8.9 of the base draft has
this to say about Authorization-Lifetime:
An Authorization-Lifetime AVP
MAY be present in re-authorization
messages, and contains the number of
seconds the user is authorized
to receive service from the time the re-auth
answer message is
received by the access device.
The MIP draft
contains no references to Session-Timeout beyond the
occurence rules and the
ABNFs and they are contradictory.
The occurence rules of the MIP draft
states
+-----------------------+
| Command-Code
|
|-----+-----+-----+-----+
Attribute Name | AMR | AMA | HAR | HAA
|
------------------------------|-----+-----+-----+-----+
Session-Timeout
| 0 | 1 | 1 | 0 |
The ABNFs for AMA and HAR list it as optional. Looking
solely at the
base draft the ABNF would seem to be correct.
But this
still does not settle the issue of the semantics of its
presence. Section 5.1
of the mip draft states
The Diameter Mobile IP application makes use of
two timers - the
Authorization-Lifetime AVP [DIAMBASE] and the
MIP-Key-Lifetime AVP.
The Authorization-Lifetime contains the number of
seconds before the
Mobile Node must issue a subsequent MIP registration
request. The
content of the Authorization-Lifetime AVP corresponds to the
Lifetime
field in the MIP header [MOBILEIP].
The MIP-Key-Lifetime AVP
contains the number of seconds before
session keys destined for the Mobility
Agents and the Mobile Node
expire. A value of zero indicates infinity (no
timeout). If not zero,
the value of the MIP-Key-Lifetime AVP MUST be at least
equal to the
value in the Authorization Lifetime AVP.
If the application doesn't use Session-Timeout it should not be
optional
or mandatory but banned. The section quoted above inevitably leads
to
the the termination of the user session after at
least
Authorization-Lifetime seconds and at most Authorization-Lifetime
+
MIP-Key-Lifetime seconds.
Requested change:
Remove
Session-Timeout from AMA and HAR.
Modify the first paragraph of section
5.1 to:
The Diameter Mobile IP application makes use of two timers -
the
Authorization-Lifetime AVP [DIAMBASE] and the MIP-Key-Lifetime AVP.
The
Session-Timeout AVP [DIAMBASE] does not apply to this application.
Issue 307: Diameter CMS Security - Remove DSA-TTL
from PDSA message
Submitter name: Don Zick
Submitter email address:
dzick@interlinknetworks.com
Date first submitted: March 11,
2002
Reference:
Document: cms
Comment type: T
Priority:
1
Section:
Rationale/Explanation of issue
A diameter agent may
establish security associations on behalf of access
devices. The access
devices issue the PDSR message to request this. It
is simpler for the access
devices if they do not have to re-issue the
PDSR because of DSA-TTL expiry.
Also, the diameter agent may make use of
the same DSA for more than one
access device; in this case it doesn't
make much sense for multiple access
devices to be responsible for
re-establishing the same DSA.
Requested
change:
Replace text from section 1.3:
The PDSA MUST
contain
the TTL setting agreed by the proxy agent for its DSA.
This information will
allow the access device to re-issue a PDSR
prior to the proxy's DSA expiry if
it needs the DSA to remain
active.
with this text:
The proxy
agent is responsible for re-establishing the DSA
prior to expiration without
any involvement by the access
device.
Also, remove DSA-TTL from PDSA
ABNF definition.
Issue 308: Support for Originating-Line-Info AVP
missing from NASREQ
Submitter name: Bernard Aboba
Submitter email
address: aboba@internaut.com
Date first submitted: 2001-3-18
Reference:
Document: nasreq-09
Comment type: T
Priority: 1
Section:
Rationale/Explanation of issue:
The Diameter NASREQ application
currently does not support the
RADIUS Originating-Line-Info AVP, attribute
#94. Below is information
provided by Nenad Trifunovic relating to the
definition of that AVP.
1.0 Introduction
Signaling System 7 (SS7)
network is used in Public Switched Telephone
Network (PSTN) for call
management. SS7 messages carry a number of
information elements related to a
particular circuit switched call.
The originating line information (OLI)
information element indicates
the nature and/or characteristics of the line
from which a call
originated (e.g. payphone, hotel, cellular). Telephone
companies are
starting to offer OLI to their customers as an option over
Primary
Rate Interface (PRI). Internet Service Providers (ISPs) can use OLI
in
addition to Called-Station-Id and Calling-Station-Id attributes
to
differentiate customer calls and define different services.
2.0
Originating-Line-Info Attribute
A summary of the Originating-Line-Info
attribute format is shown
below. The fields are transmitted from left to
right.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type
| Length | Value
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
94
for Originating-Line-Info.
Length
4
Value
The Value field is two octets (00-99). ANSI T1.113 and
BELLCORE 394 can be used for additional information about
those values
and their use.
p.s.
this is my private copy for those values (i don't know how well
it
matches ANSI T1.113 or BELLCORE 394 since i only found references
to them).
00 Plain Old Telephone Service (POTS) - non-coi service
requiring no
special treatment with ANI identified.
01 Multiparty Line (more than 2)
or Operator Number
Identification (ONI)
02 ANI Failure
03 ANI
Observed
04 ONI Observed
05 ANI Failure Observed
06
Hotel/Motel without room identification
07 Coinless, Hospital, Inmate,
etc.
08 InterLATA Restricted
09 Unassigned
10 Test
Call
11 Unassigned
12-19 Not assignable - conflict with
international outpulsing code
20 Automatic Identified Outward Dialing
(AIOD)
21-22 Unassigned
23 Coin or non-coin (identified line) Line
Status Unknown
24 800 Service Call
25-26 Unassigned
27 Coin
28 Unassigned
29 Prison/Inmate Service
30-32 Intercept.
30 Intercept (blank) - for calls to unassigned DN
31 Intercept
(trouble) - for calls to DNs that have been
manually placed in trouble-busy
state by Telco Personnel
32 Intercept (regular) - for calls to recently
changed or
disconnect numbers
33 Unassigned
34 Telco Operator
Handled Call
35-39 Unassigned
40-49 Unrestricted Use - locally
determined by carrier
50-51 Unassigned
52 Outward Wide Area
Telecommunications Service (OUTWATS)
53-59 Unassigned
60
Telecommunications Relay Service (TRS)
61 Cellular Service (Type 1)
62 Cellular Service (Type 2)
63 Cellular Service (Roaming)
64-65 Unassigned
66 Telecommunications Relay Services (TRS)
67 Telecommunications Relay Services (TRS)
68 InterLATA
Restricted - Hotel Line
69 Unassigned
70 Private Pay-stations
71-77 Unassigned
78 InterLATA Restricted - Coinless Line,
etc.
79 Unassigned
80-89 Reserved for Future Expansion
90-92 Unassigned
93 Access for private virtual network types of
service
94 Unassigned
95 Test Call
96-99
Unassigned
---------- Forwarded message ----------
Date: Thu, 14 Mar
2002 09:25 -0800 (PST)
From: Nenad Trifunovic
<nenad.trifunovic@wcom.com>
To: Bernard Aboba
<aboba@internaut.com>
Subject: Re: Spec for the Originating-Line-Info
AVP
Hello,
After some inquiry I got this
pointer:
http://www.nanpa.com/number_resource_info/ani_ii_assignments.html.
so,
people can synchronize to these secret numbers (although winning
lotto
numbers seem to be much more in demand :-) ).
regards,
nenad
Issue 309:Fix conflicting AVP codes in
NASREQ
Submitter name: David Spence
Submitter email address:
DSpence@Interlinknetworks.com
Date first submitted: February 25,
2002
Reference:
Document: NASREQ
Comment type: T
Priority:
S
Section: various
Rationale/Explanation of issue:
In NASREQ-08,
AVP Code 409 is assigned to two different
AVPs:
CHAP-Auth
NAS-Key-Lifetime
AVP Code 410 is also assigned
to two different AVPs:
CHAP-Ident
NAS-IV
Requested
change:
I have assigned a new AVP Code to NAS-Key-Lifetime: 413
I have
assigned a new AVP Code to NAS-IV: 414
Issue 310:Ambiguities in AVP Flag rules tables
Submitter name: David Spence
Submitter email address:
DSpence@Interlinknetworks.com
Date first submitted: 2/22/02
Reference:
http://www.merit.edu/mail.archives/aaa-wg/2002-02/msg00147.html
Document:
base, cms-sec
Comment type: T
Priority: 1
Section: base sec. 4.6,
cms-sec sec. 6.0
Rationale/Explanation of issue:
Several AVPs listed
in the table in sec. 4.6 of the base draft do not
include all three flags in
the AVP Flag rules columns. This leads to
ambiguities. For example, how
should I set the 'M' flag in the
Error-Message AVP? 'M' is not listed in the
MAY column so I guess I
can't set it, but then 'M' is not listed in the MUST
NOT column so
perhaps I can set it.
In the AVP Flag rules table in
sec. 6.0 of the cms-sec draft, in the
DSA-TTL row, the 'P' flag is listed
twice. It appears in both the
MAY and MUST NOT columns.
Requested
change:
The following rows in the table in sec. 4.6 of the base draft
need to
be
fixed:
Error-Message
Error-Reporting-Host
Product-Name
Redirect-Host
The
following row in the table in sec 6.0 of the cms-sec draft needs
to be
fixed:
DSA-TTL
Issue 311:Acct-Application-Id and
Vendor-Specific-Application-Id in ACR
Submitter name: Tony Johansson
(originally Lollo Tonnesson)
Submitter email address:
tony.johannson@ericsson.com
Date first submitted: March 13,
2002
Reference:
Document: Base
Comment type: E
Priority:
1
Section: 9.7.1 Accounting-Request
Rationale/Explanation of
issue
Lollo Toennesson (QPK) wrote:
The usage of
Acct-Application-Id and
Vendor-Specific-Application-Id for vendor
specific
accounting application is unclear.
I'd like to specify a
vendor specific accounting application
by using ACR and ACA commands in the
Diameter Base Protocol
and add on some optional service specific
AVPs.
How do you specify the application Id in the ACR and ACA commands if
you
are using a vendor specific accounting application?
Should
Acct-Application-Id and/or Vendor-Specific-Application-Id be
used?
1) Alternative 1:
<ACR> ::= < Diameter Header: 271,
REQ, PXY >
< Session-Id >
{ Acct-Application-Id }
{
Origin-Host }
.......
Question: What Acct-Application-Id should be
used?
2) Alternative 2:
<ACR> ::= < Diameter Header: 271,
REQ, PXY >
< Session-Id >
{ Acct-Application-Id }
{
Vendor-Specific-Application-Id }
{ Origin-Host }
.......
Question: What
Acct-Application-Id should be used?
3) Alternative 3:
<ACR> ::=
< Diameter Header: 271, REQ, PXY >
< Session-Id >
{
Vendor-Specific-Application-Id }
{ Origin-Host
}
.......
Question: Acct-Application-Id is defined as mandatory for
ACR.
Is it appropriate to replace the mandatory
Acct-Application-Id with
Vendor-Specific-Application-Id.
This is not explicitly stated anywhere in the
draft (09).
According to 09 draft of the Diameter Base Protocol:
*
6.10 Vendor-Specific-Application-Id
AVP
Format
<Vendor-Specific-Application-Id> ::= < AVP Header: 260
>
1* [ Vendor-Id ]
0*1{ Auth-Application-Id }
0*1{
Acct-Application-Id }
The vendor-Id is assigned by IANA.
The
Acct-Application-Id is defined by the vendor (private use).
*Is chapter
1.2.4, 2.4 applicable for vendor specific
accounting applications, i.e. that
an Acct-Application-Id
should be assigned by IANA?
* According to e.g.
chapter 6.10 in the base protocol, the
Vendor-Specific-Application-Id AVP
should be used for advertise
support for vendor specific diameter
applications, but this AVP
is not mentioned in the ACR or ACA, only for CER
and CEA (table in 10.1, 10.2)
The only application Id AVP required for ACR
and ACA are the
Acct-Application-Id.
??: Implication: During capability
exchange (CER/CEA) you advertise
support for the vendor specific application
but the vendor
specific application id is not included in the ACR/ACA
commands.
Can this really be correct?
??: Should both the
Acct-Application-Id and
Vendor-Specific-Application-Id be part of
CER/CEA?
* Acct-Application-Id AVP is mandatory in ACR and
ACA (9.7.1, 9.7.2, 10.2)
Best regards Lollo
Requested
change:
Change the ABNF in 9.7.1
Accounting-Request
from:
<ACR> ::= < Diameter Header:
271, REQ, PXY >
< Session-Id >
{...}
{ Acct-Application-Id
}
[...]
To:
<ACR> ::= < Diameter Header: 271, REQ, PXY
>
< Session-Id >
{ ... }
[ Acct-Application-Id ]
[ ...
]
Since you may run only the base protocol, your own vendor specifc
application and no relay agent
support. In such a case your ACR messages will
only include the Vendor-Specific-Application-Id and
no
Acct-Application-Id.
[Notes from Bernard Aboba follow]
I think that this issue is in part engendered by a lack of clarity in
the
spec about when a new Acct-Application-Id is needed.
Accounting
is somewhat different from Authentication in that in many cases
the
accounting server only writes the AVPs to disk, and therefore doesn't
need to
understand them. As a result, one can send vendor-specific AVPs to
an
accounting server without the server needing to "support" them. Thus,
section
1.2.4 was written to try to discourage gratuitous use of
new
Acct-Application-Ids:
1.2.4 Creating New Accounting
Applications
There are services that only require the use of Diameter
accounting.
Since such services need to define the service specific AVPs
that
must be carried in the Accounting-Request/Answer messages, but do
not
need to define command codes, the rules on allocation of
Accounting
Application Identifiers is different from the ones defined in
section
2.3.3.
When possible, a new Diameter accounting application
SHOULD attempt
to re-use any existing Diameter AVP, in order to reduce
the
possibility of having multiple AVPs that carry similar
information.
Every Diameter accounting application specification MUST
have an IANA
assigned Application Identifier (see section
2.4).
------------------------------------------
Note that section 1.2.4
says that rules on allocation of Accounting
Applications Identifiers [sic] is
different, but doesn't say *how* it is
different. My understanding is that it
is different because there is even
less reason to create a new
Acct-Application-Id than a new Auth
Application. Thus, it would seem that
adding Vendor-Specific AVPs may not
be a good enough reason to create a new
Acct-Application-Id. To resolve
this issue, I think we need to specify when
new Accounting Applications
are created in more detail.
Here is what
section 2.3.3. says about Authentication Applications:
2.3.3 Creating New
Auth Applications
Should a new application require Diameter support, but
it cannot fit
within an existing application without requiring major changes
to the
specification, it may be desirable to create a new
Diameter
application. Major changes to an application include:
- Requiring
a whole different set of mandatory AVPs to a command
- Requiring a command
that has a different number of round trips
to satisfy a request (e.g.
application foo has a command that
requires one round trip, but new
application bar has a command
that requires two round trips to
complete).
- The method used to authenticate the user is
drastically
different from any existing application, and the
authentication
information cannot be carried within the AVPs defined in
the
application.
Note that the creation of a new application should be
viewed as a
last resort.
New Diameter applications MUST define at
least one Command Code, the
expected AVPs in an ABNF [ABNF] grammar (see
section 3.2), and MAY
also define new AVPs. If the Diameter application has
any accounting
requirements, it MUST also specify the AVPs that are to be
present in
the Diameter Accounting messages (see section 9.3).
When
possible, a new Diameter application SHOULD attempt to re-use
any existing
Diameter AVP, in order to reduce the possibility of
having multiple AVPs that
carry similar information.
Every Diameter application specification MUST have an IANA
assigned
Application Identifier (see section 2.4).
[Notes from Jari Arkko follow]
Date: Thu, 28 Mar 2002 21:44:48 +0200
From: Jari Arkko
<jari.arkko@kolumbus.fi>
To: john.loughney@nokia.com
Cc:
aaa-wg@merit.edu
Subject: Re: [AAA-WG]: Issue 311:Acct-Application-Id and
Vendor-Specific-Application-Id in ACR
I have a somewhat modified
proposal. Removing the acct-application-id
is a nice idea, but unfortunately
it runs into trouble with the capability
discovery process and in particular
with the contents of section 6.1. So,
I'm proposing we keep the acct
application ids, but allow for vendor specific
values as well. This allows
also at the same time that the accounting servers
will be able to know the
application type immediately, without trying to infer
it from the
AVPs.
My proposed solution contains the following changes:
1)
Section 2.3.3 should be renumbered in base to 1.3.3. (!)
2) References to
section 2.5 throughout the base are wrong, and should
probably point to
2.4
3) 2.5 Connections vs. Sessions is missing from the contents
table.
(It seems like going through the whole contents table as well
as
all references would make sense.)
4) Relay app id (0xffffffff) can be
used also by "dumb" file writing accounting
servers. Add text to just before
"while" in 2.4: ", accounting servers capable
of storing any records MUST
advertise the Relay Application Identifier for
accounting".
5) Modify ANF
for ACR as follows:
<ACR> ::= < Diameter Header: 271, REQ, PXY
>
< Session-Id >
{ ... }
[ Acct-Application-Id ]
[
Vendor-Specific-Application-Id ]
[ ... ]
And add text: "One of
Acct-Application-Id and Vendor-Specific-Application-Id AVPs
MUST be present.
If the Vendor-Specific-Application-Id grouped AVP is present,
it must have an
Acct-Application-Id inside."
6) Similar modifications for ACA.
7)
Don't touch 2.3.3 (i.e. 1.2.3), it is for authentication only.
8) Add
replace the text in 1.2.4 with
Services that have an Application
Identifier MUST use the same identifier
also to identify the service when
Diameter accounting is used.
There are services that only require the use
of Diameter accounting.
Such services need to define the service specific
AVPs that must be
carried in the Accounting-Request/Answer messages, but do
not need to
define command codes. Application Identifiers are, however, still
required
for accounting due to the Diameter capability discovery
process.
Every accounting application MUST have either an IANA allocated
Application
Identifier, or a vendor specific Application Identifier.
When possible, a new Diameter accounting application SHOULD
attempt
to re-use any existing Diameter AVP, in order to reduce
the
possibility of having multiple AVPs that carry similar information.
9)
Modify AVP occurrence tables appropriately.
10) 6.1.1 add
Vendor-Specific-Application-Id to the list in the last bullet.
11) Add a
new paragraph after the first paragraph of 11.3: "Both Application-Id
and
Acct-Application-Id AVPs use the same Application Identifier space."
12)
Also add to 11 that not just zero but also 0xffffffff are reserved
values.
Issue 312:Diameter CMS Security - Require
AAA-Node-Cert in DSAR and DSAA
Submitter name: Don Zick
Submitter
email address: dzick@interlinknetworks.com
Date first submitted: March 11,
2002
Reference:
Document: cms
Comment type: T
Priority:
1
Section:
Rationale/Explanation of issue
A single occurrence of
the AAA-Node-Cert AVP should be required in the
DSAR and the DSAA.
The
Diameter CMS Security draft states (in section 3):
In order to encrypt AVPs
for a recipient, the originating Diameter
node must have a copy of the
recipient's public key. There are many
well-known key retrieval schemes (e.g.
LDAP [CERTLDAP]), but this
specification also allows for the transportation
of certificates
within Diameter AVPs, which is expected to simplify
implementations.
If inclusion of the AAA-Node-Cert AVP is optional then
the expected
simplification in implementations is lost because
compliant
implementations must be able to handle DSAR and DSAA messages that
don't
include the AAA-Node-Cert AVPs.
Requested change:
Please update the occurrence rules table and the
ABNF definitions for
the DSAR and DSAA to indicate that exactly 1 occurrence
of the
AAA-Node-Cert must be present.
Issue 313:CMS Security Questions
Submitter
name: Stephen Farrell
Submitter email address:
stephen.farrell@baltimore.ie
Date first submitted: March 14,
2002
Reference:
http://www.merit.edu/mail.archives/aaa-wg/msg03431.html
Document:
CMS
Comment type: T/E
Priority: 1
Section:
various
Rationale/Explanation of issue:
Don Zick wrote:
>
> Hi Stephen,
>
> Before I go
hog-wild submitting any more issues could you please address
> the
following questions concerning the Diameter CMS Security draft?
>
>
1. In section 3.1, it states:
>
> We use Diameter Security
Association Request (DSAR) and Diameter
> Security Association Answer
(DSAA) messages to establish a DSA,
> which
> specifies which AVPs
should be encrypted, signed or both, as well
> as
> which public
key(s) to use.
>
> Now that the expected-signed and
expected-encrypted AVPs have been
> removed, shouldn't the text "which
specifies which AVPs should be
> encrypted, signed or both" be
removed?
Yes. Will do.
>
> 2. The AVP occurrence rules
table in section 8 shows that at most 1
> AAA-Node-Cert AVP may appear in
a DSAR or a DSAA. However, the
> ABNF definition for the DSAR and DSAA
indicate that any number
> of AAA-Node-Cert AVPs may appear. Is the AVP
occurrene rules
> table correct? If so, shouldn't "public key(s)"
mentioned in
> item 1 really be "public key"?
We do want to allow
>1 certificate to be included (we're just
insisting they all be
verifiable from a single CA-Chain).
So, I'd go for changing the avp occurrence rule and leaving the
text and
abnf alone.
> 3. In section 3.1, it states:
>
> - Its
local policy allows the given TTL, realm, AVP protection
> expectations,
certification status, and other parameters.
>
> Now that the
expected-signed and expected-encrypted AVPs have been
> removed, shouldn't
the text "AVP protection expectations" be removed?
Yes.
> 4. In
section 3.1 it states:
>
> ...the destination node returns the DSAA
message which contains:
> ...
> - public key certificates for the
Diameter servers in the
> realm...
>
> This goes back to
question #2. Must a Diameter server know all of
> the certificates for all
servers in its realm? Why is that useful
> when the Diameter node is only
establishing a DSA with a single
> server?
Fixed with #2.
>
> 5. In section 3.1 it states:
>
> The DSAA MUST
include the CMS-Signed-Data, signed by a Diameter
> agent
> or
server within the user's realm, to prevent an intermediate node
> from
modifying the protection expectations for AVPs.
>
> Shouldn't this
requirement be removed now that expected-signed and
> expected-encrypted
AVPs have been removed?
Hmm...That's a reasonable point, but I'd
(somewhat less than entirely
convincingly) argue to stick with the DSAA MUST
be signed position for
the following reasons:
- A node producing a
DSAA really has to have a private key for anything
useful to subsequently
happen, therefore requiring the signature
doesn't require any additional code
or administration, just the few
additional CPU cycles required for signing
this message.
- The signed AVPs from the DSAA (in particular the DSA-TTL)
can't be
modified by intermediaies, though that's not much of a threat
compared to modifying expected-* AVPs, I agree.
- It provides some
assurance that the originator of the message is
the entity that (the CA said)
has the relevant private key. However,
for this to be better, a random
challenge should be added to
the DSAR and (that or a digest of the DSAR)
reflected back in
the DSAA as a signed AVP (I was thinking of proposing this
as
an addition to -04 but didn't).
>
> 6. In section 3.2 it states:
>
> For multiple
Diameter servers within a realm that share a public
> key,
> each
server's identity is encoded in the subjectAltName extension.
> This
allows any server within a realm to decrypt AVPs intended for
> that
realm.
>
> Why would a server that is not part of the DSA ever
decrypt AVPs?
Various forms of load-balancing I guess.
>
Wouldn't there be potential problems with content encryption key
>
reuse?
Yes. As with reboots, so nothing new there.
> 7. In
section 4.4, the PDSR is defined. When an access device sends
> a PDSR to
a local proxy, the local proxy will establish a DSA with
> a server in the
DSAR-Target-Realm. If the access device sends an
> authentication request
to the local proxy and the authentication
> request contains
Destination-Realm but does not contain
> Destination-Host, must the local
proxy add the Destination-Host
> AVP to the message to ensure that it is
routed to the server in
> the Destination-Realm that has the DSA? If this
is a requirement
> I think it should be stated explicitly.
I guess
we do need more text here and will add that. I guess I
should change
"authentication request" to "any Diameter message" in
the above though?
> 8. Section 6.3 provides some example encodings for encrypted and
>
signed AVPs. The examples indicate that different Diameter
> nodes can
have different encryption and signing requirements.
> Aren't these
examples misleading now that the expected-signed
> and expected-encrypted
AVPs have been removed? (All Diameter
> nodes share the same encryption
and signing requirements.)
The examples are based on requirements on AVPs
which can be determined
from the RFC or by an astrologer. So I disagree that
this is related
to the expected-* removal.
> 9. The AVP occurrence
rules table and ABNF message definitions
> have some
inconsistencies:
>
> DSAR ABNF DSAR Occurrence rules table
>
AAA-Node-Cert * 0-1
Was the above meant to be in your mail?
>
DSAA ABNF DSAA Occurrence rules table
> AAA-Node-Cert * 0-1
should be
0+
> OCSP-Responses * 1+
should be 0+
> Origin-Realm 0*1
1
> Redirect-Host not listed 0+
> Redirect-Host-Usage not listed
0-1
> Redirect-Max-
> Cache-Time not listed 0-1
I don't know
what's right for these. Want to suggest
something?
> 10. DSAA ABNF has Local-CA-info surrounded by curly brackets. I
>
think square brackets are correct.
Disagree. Doesn't *{foo} mean "one or
more", whereas *[foo] means
"zero or more". One or more is what's
wanted.
>
> 11.Origin-State-Id listed as Original-State-Id in
AVP occurrence table.
I'm guessing that Origin-State-Id is the right
name?
> 12.Section 3.1 states:
>
> Once the DSA is in
place, any Diameter messages created by a DSA
> peer
> that has a
private key MUST contain a signature over all AVPs whose
>
>
definition states that their 'P' bit MAY be set.
>
> I think the
CMS-Encrypted-Data AVP is an exception to this rule. It
> only requires a
signature if any of the encrypted AVPs contained in
> the
CMS-Encrypted-Data AVP require signing.
Good point. I'll add text
indicating this.
> 13.Some typos:
>
> Section 1: "two different set of
messages"
> "two different sets of messages"
>
> Section 1.2
"DSA would the NAS"
> "DSA would be the NAS"
>
> "initiate an
DSAR"
> "initiate a DSAR"
>
> Section 1.3 "such an an
aggregating relay"
> "such as an aggregating relay"
>
>
"recelived"
> "received"
>
> Section 3.1 "MUST
re-validated"
> "MUST be re-validated"
>
>
"implemetors"
> "implementors"
>
> Section 5 "CAA" (in
diagram)
> "CEA"
>
> "issues an DSAR message"
> "issues
a DSAR message"
>
> Section 6.11 "lenght"
> "length"
>
Thanks,
Stephen.
Issue 314:Minor clarifications/corrections to
Base-09
Submitter name: Bob Kopacz
Submitter email
address:bkopacz@interlinknetworks.com
Date first submitted: 03-26-2002
Reference:
Document: draft-base-09
Comment type: Technical
Priority: 1
Section:
Rationale/Explanation of issue:
Minor corrections/clarifications to base-10.
Requested
change:
In section 1.1.1 Differences from Radius
Change
"Radius" to all caps in the section title.
- - -
In section 6.1.8
Relaying and Proxying Requests
Change the first two lines of the
following paragraph:
Relay and Proxy agents MAY include the Proxy-Info
AVP in requests if
it requires access any local state information when the
corresponding
response is received. Alternatively, it MAY simply use local
storage
to store state information.
To (four changes "A"... "or"... "agent"... "to"):
A Relay or Proxy
agent MAY include the Proxy-Info AVP in requests if
it requires access to any
local state information when the corresponding
response is received.
Alternatively, it MAY simply use local storage
to store state
information.
- - -
In section 7.1 Result-Code AVP
The
Result-Code AVP (AVP Code 268) is of type Unsigned32 and
indicates whether a
particular request was completed successfully or
whether an error occurred.
All Diameter answer messages MUST include
one Result-Code AVP. A
non-successful Result-Code AVP (one containing
a non 2xxx value) MUST include
the Error-Reporting-Host AVP if the
host setting the Result-Code AVP is
different from the identity
encoded in the Origin-Host AVP.
Change the
parenthesized phrase in the preceding paragraph:
(one containing a non
2xxx value)
To:
(one containing a non 2xxx value other than
DIAMETER_REDIRECT_INDICATION)
- - -
In section 8 DIAMETER USER
SESSIONS
Services provided past the expiration of the
Authorization-
Lifetime and Auth-Grace-Period AVPs is the responsibility of
the
access device.
Change "is the responsibility" to "are the
responsibility".
- - -
In section 8.4 Session
Termination
It is also possible that a session that was authorized is
never
actually started due to action of a proxy. For example, a proxy
may
modify an authorization answer, converting the result from success
to
failure, prior to forwarding the message to the access device. A
proxy
that causes an authorized session not to be started MUST issue
an STR to the
Diameter server that authorized the session, since the
access device has no
way of knowing that the session had been
authorized.
Change the last
sentence of the preceding paragraph to:
If the answer did not contain an
Auth-Session-State AVP with the value
NO_STATE_MAINTAINED, a proxy that
causes an authorized session not to be
started MUST issue an STR to the
Diameter server that authorized the
session, since the access device has no
way of knowing that the session
had been authorized.
- - -
In
section 8.12 Re-Auth-Request-Type AVP
Following this sentence:
The
Re-Auth-Request-Type AVP (AVP Code 285) is of type Enumerated and
is included
in application-specific auth answers to inform the client
of the action
expected upon expiration of the Authorization-Lifetime.
Add the following
sentence:
If the answer message contains an Authorization-Lifetime AVP
with a
positive value, the Re-Auth-Request-Type AVP MUST be present in an
answer
message.
- - -
In section 8.13 Session-Timeout
AVP
Change the following sentence:
A Session-Timeout AVP MAY be
present in a re-authorization message,
and contains the number of seconds
from the beginning of the re-auth.
To:
A Session-Timeout AVP MAY
be present in a re-authorization answer message,
and contains the remaining
number of seconds from the beginning of the
re-auth.
- - -
In
section 8.17 Session-Binding AVP
Change:
ACCOUNTING 4
When set,
all accounting messages for this session MUST NOT
include the
Destination-Host AVP. When cleared, the default
value, the Destination-Host
AVP MUST be present in all
accounting messages for this
session.
To:
ACCOUNTING 4
When set, all accounting messages for
this session MUST NOT
include the Destination-Host AVP. When cleared, the
default
value, the Destination-Host AVP, if known, MUST be present in
all
accounting messages for this session.
The reason for adding the
"if known" phrase is this: The accounting server
may be different from the
authentication server, and if so, probably isn't
known when the first
accounting message is sent. For subsequent
accounting messages, the
accounting server is known by the client and the
Destination-Host can be
included from then on.
- - -
Throughout the
document:
Change "Accounting-Multi-Session-Id" to
"Acct-Multi-Session-Id". Since
this is an AVP inherited from RADIUS, it
should retain the RADIUS name.
- - -
In section 10.1 Base Protocol
Command AVP Table
Change:
Attribute Name
|CER|CEA|...
--------------------|---+---+...
Supported-Vendor-Id |0+ |0
|...
To:
Attribute Name
|CER|CEA|...
--------------------|---+---+...
Supported-Vendor-Id |0+ |0+
|...
- - -
In section 10.2 Accounting AVP Table
Change the
sentence:
The table in this section is used to represent which AVPs
defined in
this document are to be present in the Accounting
messages.
To:
The table in this section is used to represent which
AVPs defined in this
document are to be present in the Accounting messages.
These AVP
occurrence requirements are guidelines which may be expanded
and/or
overriden by application-specific requirements in the
Diameter
applications documents.
- - -
In section 10.2 Accounting
AVP Table
Add these entries:
Attribute Name | ACR | ACA
|
------------------------------|-----+-----+
Auth-Application-Id | 0 | 0
|
Termination-Cause | 0-1 | 0-1 |
Event-Timestamp | 0-1 | 0-1 |
- -
-
In section 10.2 Accounting AVP Table
Change:
Attribute
Name | ACR | ACA |
------------------------------|-----+-----+
User-Name |
0+ | 0+ |
To:
Attribute Name | ACR | ACA
|
------------------------------|-----+-----+
User-Name | 1 | 0-1
|
The thinking is, that since the Session-Id AVP requirement is "1",
this
means the accounting message is for a specific session and hence for
a
specific user, so the User-Name requirement is also "1". And
the
User-Name is optionally echoed back in the ACA (per issue#264), hence
the
"0-1".
- - -
Issue 315: Bug in
Acct state machine + Split State Machines into Client vs.
Server
Submitter name: Pete McCann
Submitter email address:
mccap@lucent.com
Date first submitted: 03-27-2002
Reference:
Document:
diameter-base-09
Comment type: Technical
Priority: S
Section: 8.1,
8.2
Rationale:
Currently, there is no way to enter the PendingI
state in the accounting state
machine. This is a bug.
The state
machines given in the diameter base document are confusing
to read, because
they mix client and server states.
Requested Change:
Split each
machine in two, and replace 8.1 and 8.2 with the following
text. Note the
addition of an event to the client accounting state
machine to enter the
PendingI state:
8.1 Authorization Session State Machine
This section contains a set of
finite state machines, representing the life
cycle of Diameter sessions, and
which MUST be observed by all Diameter
implementations that make use of the
authentication and/or
authorization portion of a Diameter application. The
term Service-
Specific below refers to a message defined in a Diameter
application
(e.g. Mobile IP, NASREQ).
There are four different
authorization session state machines
supported in the Diameter base protocol.
The first two describe a
session in which the server is maintaining session
state, indicated
by the value of the Auth-Session-State AVP (or its absence).
One
describes the session from a client perspective, the other from
a
server perspective. The second two state machines are used when
the
server does not maintain session state. Here again, one
describes the session
from a client perspective, the other from a
server perspective.
When a
session is moved to the Idle state, any resources that were
allocated for the
particular session must be released. Any event not
listed in the state
machines MUST be considered as an error
condition, and an answer, if
applicable, MUST be returned to the
originator of the message.
The
following state machine is observed by a client when state is
maintained on
the server:
CLIENT, STATEFUL
State Event Action New State
-------------------------------------------------------------
Idle Client or Device Requests send Pending
access service
specific
auth req
Pending Successful Service-specific Grant Open
authorization answer Access
received with default
Auth-Session-State value
Pending Successful Service-specific Sent STR Discon
authorization answer received
but service not provided
Pending Error processing successful Sent STR Discon
Service-specific authorization
answer
Pending Failed Service-specific Cleanup Idle
authorization answer received
Open user or client device send Open
requests access to service service
specific
auth req
Open Successful Service-specific Extend Open
authorization answer received Answer
Open Accounting message sent process Open
Open Failed Service-specific Discon. Idle
authorization answer user/device
received.
Open Session-Timeout Expires on send STR Discon
Access Device
Open ASR Received send ASA, Discon
STR
Open Authorization-Lifetime + send STR Discon
Auth-Grace-Period expires on
access device
Discon ASR Received None Discon
Discon STA Received Discon. Idle
user/device
The following state machine is observed by a server when it is
maintaining state for the session:
SERVER, STATEFUL
State Event Action New State
-------------------------------------------------------------
Idle Service-specific authorization send Open
request received, and successful
user is authorized serv.
specific answer
Idle Service-specific authorization send Idle
request received, and failed serv.
user is not authorized specific answer
Open Service-specific authorization send Open
request received, and user successful
is authorized serv. specific
answer
Open Service-specific authorization send Idle
request received, and user Failed serv.
is not authorized specific
answer,
Cleanup
Open Accounting message received process Open
Open Home server wants to send ASR Open
terminate the service
Open ASA Received Cleanup Idle
with Result-Code
= UNKNOWN-SESSION-ID
Open ASA Received None Open
with Result-Code (ignore)
not = UNKNOWN-SESSION-ID
Open Authorization-Lifetime (and Cleanup Discon
Auth-Grace-Period) expires
on home server.
Open Session-Timeout expires on Cleanup Discon
home server
Open STR Received Send STA Idle
Not ASA Received None No Change.
Open
Discon STR Received Send STA Idle
The following state machine is observed by a client when state is
not maintained on the server:
CLIENT, STATELESS
State Event Action New State
-------------------------------------------------------------
Idle Client or Device Requests send Pending
access service
specific
auth req
Pending Successful Service-specific Grant Open
authorization answer Access
received with Auth-Session-
State set to
NO_STATE_MAINTAINED
Pending Failed Service-specific Cleanup Idle
authorization answer
received
Open Accounting message sent process Open
Open Session-Timeout Expires on Discon. Idle
Access Device user/device
Open Service to user is terminated Discon. Idle
user/device
The following state machine is observed by a server when it is not
maintaining state for the session:
SERVER, STATELESS
State Event Action New State
-------------------------------------------------------------
Idle Service-specific authorization send serv. Open
request received, and specific
successfully processed answer
Open Accounting message received process Open
8.2 Accounting Session State Machine
For applications that only require accounting services, the following
state machines MUST be supported. The first is to be observed by
clients, the second by servers.
When a session is moved to the Idle state, any resources that were
allocated for the particular session must be released. Any event not
listed in the state machines MUST be considered as an error
condition, and an answer, if applicable, MUST be returned to the
originator of the message.
CLIENT, ACCOUNTING
State Event Action New State
-------------------------------------------------------------
Idle Client or device requests send PendingS
access accounting
start req.
Open Interim interval elapses send PendingI
accounting
interim
record
Idle Client or device requests send PendingE
a one-time service accounting
event req
Idle Records in storage Send PendingB
record
Open User service terminated send PendingL
accounting
stop req.
PendingS Successful accounting Open
start answer received
PendingS Failure to send and buffer Store Open
space available and realtime Start
not equal to DELIVER_AND_GRANT Record
PendingS Failure to send and no buffer Open
space available and realtime
equal to GRANT_AND_LOSE
PendingS Failure to send and no buffer Disconnect Idle
space available and realtime user/dev
PendingI Failure to send and (buffer Store Open
space available or old record Interim
can be overwritten) and Record
realtime not equal to
DELIVER_AND_GRANT
PendingI Failure to send and no buffer Open
space available and realtime
equal to GRANT_AND_LOSE
PendingI Failure to send and no buffer Disconnect Idle
space available and realtime user/dev
not equal to GRANT_AND_LOSE
PendingE Successful accounting Idle
event answer received
PendingE Failure to send and buffer Store Idle
space available Event
Record
PendingE Failure to send and no buffer Idle
space available
PendingB Successful accounting answer Delete Idle
received record
PendingB Failure to send Idle
PendingL Successful accounting Idle
stop answer received
PendingL Failure to send and buffer Store Idle
space available Stop
Record
PendingL Failure to send and no buffer Idle
space available
SERVER, ACCOUNTING
State Event Action New State
-------------------------------------------------------------
Idle Accounting start request send Open
received, and successfully accounting
processed. start
answer
Idle Accounting event request send Idle
received, and successfully accounting
processed. event
answer
Open Receive Interim Record send Open
accounting
answer
Open Accounting stop request send Idle
received, and successfully accounting
processed stop answer
Comments from Jari:
Date: Mon, 01 Apr 2002 14:51:41 +0300
From: Jari Arkko
<jari.arkko@kolumbus.fi>
To: mccap@lucent.com,
aaa-wg@merit.edu
Subject: [AAA-WG]: Re: Bug in Acct state
machine
Parts/Attachments:
1 Shown 26 lines Text
2 Shown 363 lines
Text
----------------------------------------
Jari Arkko
wrote:
> >Shouldn't the above be:
> > Discon ASR
Received Send STA. Discon
>
> Not quite. The STA is sent by the
server, not the client.
>
> There is an issue, however, on what to
do if we have already sent an STR,
> are waiting for the STA to arrive but
then we get an ASR from the server
> (STR and ASR meet on the wire). The
-09 state machine simply ignored the
> ASR in this case, and on the server
side was able to terminate the session
> if, while waiting for ASA would
instead get STR. I think Pete's state
> machine gets it right as
well.
On second thought, and on reading section 8.5, it seems that
the more
appropriate action is really answering the ASR also. The ASR
could
come from some other server than the one we sent the STR to. So,
if
we are in the progress of releasing the session already and we
get ASR, we
should respond with ASA Result-Code = Success.
Modified state machine
attached.
Jari
8.1 Authorization Session State Machine
This section contains a set of finite state machines, representing the life
cycle of Diameter sessions, and which MUST be observed by all Diameter
implementations that make use of the authentication and/or
authorization portion of a Diameter application. The term Service-
Specific below refers to a message defined in a Diameter application
(e.g. Mobile IP, NASREQ).
There are four different authorization session state machines
supported in the Diameter base protocol. The first two describe a
session in which the server is maintaining session state, indicated
by the value of the Auth-Session-State AVP (or its absence). One
describes the session from a client perspective, the other from a
server perspective. The second two state machines are used when
the server does not maintain session state. Here again, one
describes the session from a client perspective, the other from a
server perspective.
When a session is moved to the Idle state, any resources that were
allocated for the particular session must be released. Any event not
listed in the state machines MUST be considered as an error
condition, and an answer, if applicable, MUST be returned to the
originator of the message.
The following state machine is observed by a client when state is
maintained on the server:
CLIENT, STATEFUL
State Event Action New State
-------------------------------------------------------------
Idle Client or Device Requests Send Pending
access service
specific
auth req
Idle ASR Received Send ASA Idle
for unknown session with
Result-Code
= UNKNOWN-
SESSION-ID