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
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 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
client will comply with with
request to end the session Result-Code
= SUCCESS,
Send STR.
Open ASR Received, Send ASA Open
client will not comply with with
request to end the session Result-Code
!= SUCCESS
Open Authorization-Lifetime + Send STR Discon
Auth-Grace-Period expires on
access device
Discon ASR Received Send ASA 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 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
not = UNKNOWN-SESSION-ID
Open Authorization-Lifetime (and Cleanup Idle
Auth-Grace-Period) expires
on home server.
Open Session-Timeout expires on Cleanup Idle
home server
Open STR Received Send STA, Idle
Cleanup
Not ASA Received None No Change.
Open
Not STR Received Send STA, Idle
Open Cleanup
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 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. Idle
request received, and specific
successfully processed answer
8.2 Accounting Session State Machine
For applications that only require accounting services or
applications that have an accounting portion, 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.
In the state table, the event 'Failure to send' means that the
Diameter client is unable to communicate with the desired
destination. This could be due to the peer being down, or due to
the peer sending back a transient failure or temporary protocol
error notification DIAMETER_OUT_OF_SPACE, DIAMETER_TOO_BUSY, or
DIAMETER_LOOP_DETECTED in the Result-Code AVP of the Accounting
Answer command.
The event 'Failed answer' means that the Diameter client received a
non-transient failure notification in the Accounting Answer
command.
Note that the action 'Disconnect user/dev' MUST have an effect also
to the authorization session state table, e.g. cause the STR
message to be sent, if the given application has both
authentication/authorization and accounting portions.
CLIENT, ACCOUNTING
State Event Action New State
-------------------------------------------------------------
Idle Client or device requests Send PendingS
access accounting
start req.
Idle Client or device requests Send PendingE
a one-time service accounting
event req
Idle Records in storage Send PendingB
record
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
not equal to
GRANT_AND_LOSE
PendingS Failed accounting start answer Open
received and realtime equal
to GRANT_AND_LOSE
PendingS Failed accounting start answer Disconnect Idle
received and realtime not user/dev
equal to GRANT_AND_LOSE
PendingS User service terminated Store PendingS
stop
record
Open Interim interval elapses Send PendingI
accounting
interim
record
Open User service terminated Send PendingL
accounting
stop req.
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
PendingI Failed accounting interim Open
answer received and realtime
equal to GRANT_AND_LOSE
PendingI Failed accounting interim Disconnect Idle
answer received and realtime user/dev
not equal to GRANT_AND_LOSE
PendingI User service terminated Store PendingI
stop
record
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
PendingE Failed accounting event answer Idle
received
PendingB Successful accounting answer Delete Idle
received record
PendingB Failure to send Idle
PendingB Failed accounting answer Delete Idle
received record
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
PendingL Failed accounting stop answer Idle
received
SERVER, ACCOUNTING
State Event Action New State
-------------------------------------------------------------
Idle Accounting start request Send Idle
received, and successfully accounting
processed. start
answer
Idle Accounting event request Send Idle
received, and successfully accounting
processed. event
answer
Idle Interim record received, Send Idle
and successfully processed. accounting
answer
Idle Accounting stop request Send Idle
received, and successfully accounting
processed stop answer
Idle Accounting request received, Send Idle
no space left to store accounting
records answer,
Result-Code
= OUT_OF_
SPACE
Issue 316:CMS Editorial Issues
Submitter
name: Jari Arkko
Submitter email address: jari@arkko.com
Date first
submitted: 03-27-2002
Reference:
Document: cms-09, base-09
Comment
type: Editorial
Priority: S
Section: CMS: Abs, ToC, 1, 2, 3, 4, 5, Base:
4.6
Rationale:
1) In the abstract "... perform message routing, and
other
than routing AVPs, do not modify Diameter messages." =>
"...
perform message routing and do not modify Diameter
messages beyond routing
AVPs."
2) ToC and the document structure. I would suggest
the
following modifications:
- Since terms generally need to introduced before
they are
used, 1.1 needs to move to its own chapter before chapter 1.
- I
would add a Terms section. See attached file for initial
text.
- I would
name 2.0 "AVP Protection' and place current 2.0 under
it as '2.1. Format' and
1.7 under it as 2.3. Then I would
add some clarifying text on exactly what
the CMS spec expects
nodes to do with AVPs (I couldn't find such text before
this
point). See attached second file for initial text.
- I would name 5.0
"Example Message Flow"
3) Chapter 1. Doesn't really describe what the
functionality
provided here is, just talks about how it is provided.
Suggested
text to add before the third paragraph: "This
specification
provides an additional security mechanism to protect transport
of
Diameter AVPs through rogue Diameter agents."
4) Chapter 1.
"Redirector agent" => "redirect agent" (the term
used in base).
5)
Chapter 1.2 last paragraph only talks about signing. Why? I
suggest that we
should talk about both signing and encryption.
Here's some proposed text to
add at the end: "Similarly, participants
MAY apply encryption to protect one
or more AVPs within a message."
6) Chapter 4.6 in base. This is related
to the above issue. We
have now clarified very well what MAY ENCR means, but
we haven't
done the same for 'MAY Set P Bit'. Essentially, isn't this the
same
thing? Propose to add text after first paragraph of 4.6:
"Similarly,
for the originator of a DIameter message, a "P" in the "MAY"
column
means that if a message containing that AVP is to be sent
via a
proxy/agent then the message MUST NOT be sent unless there
is a DSA between
the originator and the recipient or the originator
has locally trusted
configuration that indicates that
CMS need not be used."
7) Chapter
1.3 "reuse the values" -- what values? I think this
is still referring to the
old Encrypted-AVPs AVP, or something like
that. Propose to delete the
sentence.
8) 1.3, "does not request a DSAR to request a DSA" => "does
not request
a DSA through sending a DSAR message"
9) 1.3, "the access device can then determine whether it is willing
to
provide service, based on its local policy". I would simply say "The
access
device can then determine whether to trust this notification,
based
on local configuration i.e. the keys of trusted agents. If the access
device
can not trust this notification, it MUST refuse the service in
question."
10) 3.1, "... which AVPs should be encrypted, signed or
both..." -- remove
this text, but keep the part about the public
keys.
11) 3.1. DSA[RA] message contents, doesn't clearly show which AVPs
are
used for which purpose, which makes the spec harder to read.
Also,
misses some of the AVPs. Proposed text in the third
attachment.
12) 4.2 Local-CA-Info appears to be unnecessary. Remove from
this
message.
13) 3.2 "capable of acting as recipients for
confidentiality" =>
"that support DSAs".
14) 3.3. AES. Replace the
current text with "It is strongly recommended
that the AES algorithm is
supported where it is available."
15) 4.1 delete the statement about the
cert distribution protocol, I don't
think we need to state that.
16)
5.0 delete the text about the bidir signatures and encryption.
17) 5.0
step h,add to the end "Those AVPs that need to be kept confidential
are
placed in CMS-Encrypted-AVP in encrypted form. Modify picture
accordingly.
18) 5.0 step i. Add before the encryption part "The message
includes the
CMS-Signed-AVP, which authenticates the AVPs that need
it".
19) 5.0 step h. "that were requested by the Home Server in the
DSAA." =>
"that need it".
20) section 4.I think CA-Chain should be a "*" instead of "0*1". THere
may
be zero chains, if the roots and the certs don't mix or if the peer
should
already know the chain. But there can be multiple chains if several
roots are
used.
CA
Certificate Authority, a trusted third party
that signs
cryptographic certificates for other
nodes.
CMS
Cryptographic
Message Syntax [CMS].
DSA
Diameter Security
Association.
OCSP
Online Certificate Status Protocol
[OCSP].
This specification allows both the encryption and signing
of
AVPs. Encryption takes place through taking the AVPs that
need
protection from the Diameter message and placing them,
concatenated
and encrypted, in CMS-Encrypted-Data AVP. The original AVPs are
not
retained in the message.
Signing takes place through signing
contents of the protected AVPs,
and placing the signature in the
CMS-Signed-Data AVP. The original
AVPs are retained in the message, except in
the case where both
encryption and signatures are needed. In this case the
CMS-Encrypted-Data
AVP is created first and this is then signed.
The
originating node sends the DSAR message to a server in the
destination realm.
The DSAR message contains:
- TTL for this DSA (seconds) in the DSA-TTL
AVP.
- The realm part of the user's NAI in the Destination-Realm
AVP.
- The list of direct trust CA's that the originating
Diameter
node has configured into it for certificate validation. A
"direct
trust" CA is one that the node is willing to use as the
"top" of a
certificate chain, sometimes confusingly known as a
"root CA". The list is
given in a sequence of Local-CA-Info
AVPs.
- Certificate chains from
each direct trust CA, in a sequence
of CA-Chain AVPs. One AVP value is needed
for each direct trust
CA. A value MAY be omitted when the peers know that
the
relevant chains already exist at the other side.
- Public key
certificates for the Diameter servers in the
sending realm, all of which MUST
validate up to one of the
CAs above, via the chain of CA certificates
above.
- A flag indicating whether the originating Diameter node
wishes
to receive certificate status information using OCSP messages.
If
this flag requires a fresh OCSP response, a nonce to be used
by the
destination Diameter node in OCSP requests MUST also be
supplied. See [OCSP]
for more details on the certificate status
protocol and messages. The flag is
given in the OCSP-Request-Flags
AVP.
- Optional nonce for OCSP, in the
OCSP-Nonce AVP.
- The DSAR message MAY include the CMS-Signed-Data AVP.
If the
originating node has a private key, and it includes AVPs
whose 'P'
bit are set, the CMS-Signed-Data AVP MUST be
present.
The destination
node MUST check that the provided elements of the
DSAR are valid. It MUST
check, at least, that:
- Its local policy allows the given TTL,
realm,
certification status, and other parameters.
- A common "top" of the
certificate chain can be found between the
home and foreign domains.
-
This certificate chain is cryptographically correct, passes
the (relevant
parts of the) path validation algorithm specified
in [CERTPROF] and
terminates at a CA mentioned in the DSAR message
- The certificate chain
between the "top" certificate and
the certificate in the AAA-Node-Cert AVP
can be cryptographically
verified.
- The signature, if any, can be
verified.
If these conditions can not be verified, the destination node
MUST
return a DSAA with the Result-Code AVP set
to
DIAMETER_NO_DSA_ESTABLISHED.
In the event the DSAR requested OCSP
validation, via the OCSP-
Request-Flags AVP, and OCSP is not locally
supported, the DSAA MUST
be returned with the Result-Code AVP set
to
DIAMETER_OCSP_NOT_SUPPORTED.
Otherwise, the destination node
returns the DSAA message which
contains:
- TTL for this DSA (seconds),
in the DSA-TTL AVP.
- One or more chains of certificates from the "top"
CAs in the
DSAR message to the certificates of this node. Each
chain
appears as a CA-Chain AVP.
- Public key certificates for the
Diameter servers in the realm
that sends the DSAA message. All the
certificates MUST
validate up to one of the CAs in the DSAR message, via
the
chain of CA certificates above.
- Optionally, if OCSP an response
was requested in the DSAR and
OCSP is supported, a list of OCSP responses for
the
certificates in question. If a fresh response was required
and a nonce
value was included, each response will contain
the nonce from the DSAR
message
- 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 falsely claiming that the DSA has
been
established.
The originating Diameter node MUST check that the provided
elements
of the DSAR are valid. Any failure results in silently
discarding
the DSAA message, auditing the event and not sending the
original
Diameter message that requested protection from a DSA. It
MUST
check, at least, that:
- the certificate chain provided in the
DSAA is cryptographically
correct, passes the (relevant parts of the) path
validation
algorithm specified in [CERTPROF] and terminates at a
CA
mentioned in the DSAR message
- the name in the certificate is
consistent with the rules
detailed in section 3.2.
- the DSAA message MUST
include the CMS-Signed-Data AVP, the
signature MUST be validated and the
signer's certificate chain
MUST terminate as a CA mentioned in the DSAR
message
- the expiration of the TTL MUST be less or equal to the
earliest
expiration of all certificates in the message, encoded in
the
notAfter field.
If the initiator's policy is such that certificate
status is
required, it MAY indicate that it requires an OCSP response from
the
DSA peer in the DSAA message, via the OCSP-Request-Flags AVP.
Further,
the initiator MAY request that the OCSP response be fresh
(non-cached) via
the OCSP-Request-Flags and OCSP-Nonce AVPs. Upon
receipt of a DSAR message
requesting an OCSP response, the receiver
issues an OCSP request and returns
the response within the DSAA
message's OCSP-Responses AVP. The sender of the
DSAA MAY included a
cached OCSP response, unless the requestor specifically
requested a
fresh response.
The nonce value is to be (the beginning
of) the nonce in the OCSP
response. The reason for this is that the responder
MAY add
additional bits to the nonce, but the nonce provided in the
OSCP-
Nonce MUST be present at the beginning of the nonce of the
OSCP
response.
If certificate revocation is enabled, anytime a
certificate is used
from the local certificate cache, a revocation check MUST
be
performed.
Issue 317:FA-HA Key
Submitter Name: Siva
Ramamurthy
Submitter email address: sivasundar_ramamurthy@hp.com
Date
first submitter: 3/27/2002
Document: Mobile IP
Comment Type:
T
Priority: 1
Section: 4.5
Explanation of Issue:
Section 4.5
has text that says:
"If the FA's local policy allows it to receive AAA
session Keys, and
it does not have any existing keys with the HA, it MAY set
the
FA-HA-Key-Request flag".
the co-existance of the phrases "any
existing keys" and "AAA session
keys" is confusing! Is the FA-HA key to be
used only for the session
from which it was obtained, or can it be used with
any other sessions
that require communciation between this FA and HA? In
other words, is
the FA-HA key session specific or not?
Requested
Change:
Please clarify, since different implementations at the FA and HA
can
lead to needless FOR_HOME authentication failures.
Issue 318:Host-IP-Address AVP in CER and CEA is
redundant
Submitter name: Ghadiyaram Venkata Kishore
Submitter email
address: Ext-Venkata.Ghadiyaram@nokia.com,
Date first submitted: March 28,
2002
Reference:
Document: Base
Comment type: T
Priority:
1
Section:
Rationale/Explanation of issue
When a peer receives a
CER, the IPAddress(IPAddresses in case of SCTP) of the host sending the message
can be obtained
from the transport layer as this information is maintained by
the transport layer as part of TCP connection or SCTP
association. So sending
this information as part of Diameter payload is redundant.
If alternate
peers have to be provided through CER/CEA then we need a list of DiameterURIs,
just the IPAddress of the
peers is of no use.
Requested
change:
Remove Host-IP-Address AVP from the specification of CER and CEA
(both in the text and te ABNF).
Issue
319:Accounting-Realtime-Required
Issue: Accounting-Realtime-Required
should appear
in Section 9.7.2, and text in Section 9.8.7
should give its
AVP Code
Submitter name: Pete McCann
Submitter email address:
mccap@lucent.com
Date first submitted: 03-28-2002
Reference:
Document:
diameter-base-09
Comment type: Editorial
Priority: 1
Section: 9.7.2,
9.8.7
Rationale:
The Accounting-Realtime-Required AVP is defined
in Section 9.8.7, but
is not mentioned in the ABNF for Accounting-Answer
messages in Section
9.7.2. Also, the description in Section 9.8.7 lists the
AVP Code as
"TBD", but the table on page 50-51 lists the AVP with Code
483.
Requested Change:
Add the following line to 9.7.2,
after
"[Accounting-Interim-Interval]":
[ Accounting-Realtime-Required
]
Change the first line of Section 9.8.7 to read:
The
Accounting-Realtime-Required AVP (AVP Code 483) is of type
Issue 320:Base-09 Nits
Submitter name: Jari
Arkko
Submitter email address: jari.arkko@kolumbus.fi
Date first
submitted: 03-28-2002
Reference:
Document: diameter-base-09
Comment
type: Editorial
Priority: 1
Abstract:
- "The Diameter base protocol is intended to provide an AAA
framework
for Mobile-IP, NASREQ and ROAMOPS." => "The Diameter base
protocol is
intended to provide an AAA framework for applications such as
network
access or IP mobility. Diameter is also intended to work both with
local
AAA and roaming situations."
- Add accounting in the list of
functions provided by the base protocol?
Put it before security
services.
Table of contents:
- You already got my fix to
this.
- Additionally, you could replace the slash in 5.5.4 with " and
"
1.1:
- Add to the list "- Basic services necessary for
applications, such
as handling of user sessions or
accounting"
1.1.1:
- "Mandatory bit" => "Bit to indicate
mandatory status of data"
1.1.2:
- "The CMS Security [CMS]
application defines how security associations
are established between two
peers and how authentication, integrity,
confidentiality and non-repudiation
can be achieved." =>
"The CMS Security [CMS] application defines how
security associations
are established even through Diameter agents, and how
authentication,
integrity, confidentialy, and data-origin authentication can
be
achieved.
1.2:
- "Creating a new Accounting Application"
=> "Creating new accounting
applications"
1.2.1:
- "If the
new AVP value changes an existing command code's ABNF, the
IANA AVP value
request MUST include the new ABNF itself.": I'm not
sure how a new AVP value
for enumerated could ever change the ABNF.
Propose to remove this
sentence.
1.4:
- "The Diameter protocol consists of a header
followed by one or more
Attribute-Value-Pair (AVP)." Add an "s" after "Pair"
and after "AVP".
- "A Diameter Agent is a host that is providing either
relay, proxy,
redirect or translation services.". Replace "is providing"
with
"provides"
- "MLP" => "Multi-link PPP"
2.1:
- "Diameter implementations SHOULD be able to interpret ICMP
protocol
port unreachable messages as explicit indications that the server
is
not reachable, in addition to interpreting ECONNREFUSED (a reset
from
the transport) and timed-out connection attempts."
=>
"Diameter
implementations SHOULD be able to interpret ICMP protocol
port unreachable
messages as explicit indications that the server is
not reachable, subject to
security policy on trusting such messages.
Diameter implementations SHOULD
also be able to interpret ECONNREFUSED
(a reset from the transport) and
timed-out connection attempts."
2.5:
- figure 1 => Figure
1
- session x => session X
3.0:
- Under Vendor-ID: "All vendor-specific Diameter commands
require
Information RFCs documenting the command.". First of all,
it's
Informational, not Information. Secondly, I really wonder about
the
usefulness of such a strong requirement. Section 11.2 talks
about 'private
use'. I would say "It is recommended that vendor-specific
Diameter commands
are documented in Informational RFCs."
- "Unsigned32 field" under
Hop-hop-hop and End-to-End identifier.
This type hasn't been defined at this
stage yet, and is anyway
for AVPs. My suggestion is to replace the text with
"an unsigned
32 bit integer field (in network byte
order)"
3.2:
- I don't understand the comment under command-name
bnf rule.
Doesn't seem to add any value, can we remove it?
-
Diameter-Name: Shouldn't "/" be "|"?
- Under header, replace
"<
Diameter-Header:"
with
"<" "Diameter-Header:"
4.0:
-
"NULL bytes" => "Zero bytes"
4.2:
- "[ASSIGN NO]" is an
undefined reference. Add the
reference to the relevant IANA SMI
registry?
- SHOULD NOT for the zero vendor id, could we make
it a MUST
NOT?
4.3:
- Add a space to "8(12"
4.4:
- Under time:
MUST be used => MUST be supported
- Under UTF8String, "Note that the size"
=>
"Note that the AVP Length field"
- Under DiameterIdentity ,"one
single" => "a single"
- The rules on DiameterIdentity contents are
really
unclear. I don't understand what the DI = fqdn
statement intends to
say, nor does it say anywhere
how the multiple DIs on multi-server nodes
are
supposed to be created. I suggest the following text
to replace this
entry:
"DiameterIdentity value is used to uniquely identify a
Diameter
node for purposes of duplicate connection and routing
loop
detection.
The DiameterIdentity format is derived from the
OctetString Base AVP
Format. It uses the UTF-8 encoding and has the same
requirements as
UTF8String.
The contents of the string MUST be the
fqdn of the Diameter node.
If multiple Diameter nodes run on the same host,
each Diameter
node MUST be assigned a unique DiameterIdentity. If a
Diameter
node can be identified by several FQDNs, a single FQDN should
be
picked at startup, and used as the only DiameterIdentity for
that node,
whatever the connection it is sent on."
- Under DiameterUri, the text is
intended too much
on the left (doesn't show it is under DiameterUri
entry
on the list).
- Also under the Uri, the comments formatting under
port is
funny. Same for transport and protocol. .nf
missing?
- Under
enumerated, 'This contains' => 'The definition contains'
- Under
filterrule, move the "any" and "assigned" explanations
to the list that
contained "ipno" and "ipno/bits".
- Under filterrule and the "assigned"
explanation, the SHOULD
remark about the first rule is confusing and
incorrect for
IPv6. Replace with the following text: "For IPv4, a
typical
first rule is often "deny in ip !assigned""
- Add after the
"ipno/bits" text: "For a match to occur, the
same IP version must be present
in the packet that was used
in describing the IP address. To test for a
particular IP version,
the bits part can be set to zero."
- Icmptypes,
add text "Both the numeric values and the symbolic
values listed below can be
used."
- Strange intendation for the last three paragraphs under
the
ipfiltterrule
- Move the frag offset 1 text as a note under the
'frag' description
and put it inside paranthesis.
- Under QoSFilterRule,
the dir, proto, and src/dst explanations
are copy-pasted from the
IPFilterrule, and somewhat incorrect
(e.g. about the advice for the first
rule). My suggestion is
to include the following text *only*:
dir The
format is as described under IPFilterRule.
proto The format is as
described under IPFilterRule.
src and dst The format is as described
under IPFilterRule.
- In QoSFilterRule, there's no similar statement as
we had for
IPFilterRule about what to do if the NAS doesn't support
this
filter. I propose the following:
An access device that is unable
to interpret or apply a QoS
rule SHOULD NOT terminate the
session.
4.5:
- name-fmt, "/" => "|" ?
- header,
replace
"<AVP-Header:"
with
"<" "AVP-Header:"
- "avp-def"
=> "grouped-avp-def" ?
- Remove all bnf starting from the "Fixed"
since that
has already been described earlier in the same way
under the
command abnf section.
5.6.4:
- "to be null-padded to the length of the
longer" =>
"to be padded with zeros so that it length is the
same as
the length of the longer"
5.1:
- How come are the failover procedures *not* implemented if
the
primary goes to suspect list? This seems to be an error,
given that
the transport draft says FailOver is called from
the OKAY state if timer
fires.
5.2:
- "(manual)" => "(manually)"
5.3.1:
-
"interfaces, hence, multiple" => "interfaces and
multiple"
5.4:
- "have recently be forwarded" => "have recently
been forwarded"
5.4.3:
- busy, "shutdown" =>
"closed"?
5.6.4:
- "Hanging octets are assumed to have value
0x80, but
dimpled octets are ignored." What is
this??!?!?
6.1:
- Bullet item "3.", add "Otherwise, " at the
beginning to
clarify when this alternative is
selected.
6.1.1:
- Regarding the application Ids that must be in
proxiable
messages, note my comment in an earlier e-mail about adding
the
vendor-specific-application id as well.
6.1.7:
- The language is
somewhat clear as to whether a single or
multiple Redirect-Host AVPs are
allowed. My suggestion is
to allow multiple. Add the following text to the
end of the
section: "Multiple Redirect-Host AVPs are allowed. The
receiver
of the answer message with the 'E' bit set selects exactly one
of
these hosts as the destination of the redirected message."
6.10:
-
"Either the Auth-Application-Id or the Acct-
Application-Id AVP MAY be
present. Both AVPs MAY be present if they
both contain the same value." This
is somewhat problematic. Useful
in CER, but not absolutely necessary. And
would present problems in
accounting or auth commands. My suggestion is to
have CER include
multiple copies if necessary. Therefore, propose the
following text:
"Exactly one of the Auth-Application-Id and
Acct-Application-Id AVPs
MAY be present."
6.11:
- "This
AVP
MUST be present if the answer message's 'E' bit is set and
the
Result-Code AVP is set to DIAMETER_REDIRECT_INDICATION.
Upon
receiving the above, the receiving Diameter node SHOULD forward
the request
directly to the host identified in this AVP. The server
contained in the
Redirect-Host SHOULD be used for all messages
pertaining to this
session."
=>
"One or more of instances of this AVP
MUST be
present if the answer message's 'E' bit is set and the
Result-Code AVP is set
to DIAMETER_REDIRECT_INDICATION.
Upon receiving the above, the receiving
Diameter node SHOULD forward
the request directly to one of the hosts
identified in these AVPs. The server
contained in the selected Redirect-Host
AVP SHOULD be used for all messages
pertaining to this session."
7:
- "There are two different types of errors in Diameter; protocol
and
applications." => "There are two different types of errors in
Diameter:
protocol and application errors."
- "creates an AVP with the
AVP Code and other fields set to the
missing AVP's" => "creates an AVP
with the AVP Code and other fields
set as expected in the missing
AVP"
7.1:
- "identified by the thousands digit" Apparently, the
point behind the
old issue hex/dec was somehow missed in the heated
discussion of
whether hex should be adopted ;-) The point was that the spec
should
say which type of numbers these are. Propose the following text
instead:
"identified by the thousands digit in the decimal
notation"
7.1.3:
- "Note that these errors" => "Note that these
and only these errors"
(to clarify that E bit errors can only be protocol
errors)
8.1:
- The auth state machines (both versions) have an action
to
send or receive an accounting message. This seems inadequate,
and is perhaps
a remnant of the old state machine which didn't
do a good job in accounting.
I propose that the two entries
in the state machine are
removed
8.2:
- Replace the first paragraph with:
"For
applications that only require accounting services or applications
that have
an accounting portion, the following
state machine MUST be
supported."
- There seems to be a problem in producing interim records
from the
client. Is there any entry in the state table for this?
8.7:
- "requested/offered/." =>
"requested/offered."
9.1:
- "Batched Accounting" => "batched
accounting"
- Add at the end of the second paragraph: "Note,
however,
that even if at the Diameter layer accounting requests
are
processed one by one, transport protocols used under
Diameter typically batch
several requests in the same packet
under heavy traffic conditions. This may
be sufficient for many
applications."
- "The server (or agents)
uses
the Accounting-Interim-Interval AVP to control the operation of
the
Diameter peer operating as a client."
=>
"The server (or agents)
uses
the Accounting-Interim-Interval and Accounting-Realtime-Required AVPs to
control
the operation of the Diameter peer operating as a
client."
And then at the end of the same paragraph,
add:
"Accounting-Realtime-Required AVP is used to control the behaviour
of
the client when the transfer of accounting records from the Diameter
client
is delayed or unsuccessful."
- "The Diameter accounting server
MAY override the interim interval by
including an Accounting-Interim-Interval
AVP in the Accounting-Answer
message. When the AVP is present, the latest
value received SHOULD be
used in the generation of interim accounting
messages.
=>
"The Diameter accounting server MAY override the interim
interval or the
realtime requirements by
including the
Accounting-Interim-Interval or Accounting-Realtime-Required AVP in the
Accounting-Answer
message. When one of these AVPs is present, the latest
value received SHOULD be
used in further accounting activities for the same
session.
9.2:
- "A rejected Accounting-Request message
SHOULD
cause the user's session to be terminated."
=>
"A rejected
Accounting-Request message MAY
cause the user's session to be
terminated,
depending on the value of the Accounting-Realtime-Required AVP
received
earlier for the session in question."
9.4:
-
"detection need" => "detection needs"
9.5:
- "If the
authorization server has directed interim
accounting to be enabled for the
session, but no interim interval was
specified"
=>
"If the
authorization server has not directed interim
accounting to be enabled for
the session"
(because we can only turn on interim accounting for a
specific
time value, we can't turn it on without the value)
- "If a
specified interim interval exists," =>
"If the authorization server has
directed interim accounting to be enabled,"
9.7.1:
- Add
"[Accounting-Realtime-Required]" to the command, after the interval
AVP
9.7.2:
- As above
9.8.1:
- "directed by the"
=> "done by the"
10.2:
- Replace the Acct Rt Req line
with:
Accounting-Realtime-Required | 0-1 | 0-1 |
11.1.1:
-
"482" => "482-483" (due to accounting-realtime-required having value
483)
11.4:
- "3001-3009" => "3001-3010"
11:
- Add
a new section 11.16:
11.16 Accounting-Realtime-Required AVP Values
As
defined in Section 9.8.7, the Accounting-Realtime-Required AVP (AVP Code
483)
defines the values 1-3. All remaining values are available for
assignment via
IETF Consensus [IANA].
Issue 321:Normative
references to CMS
Description of issue: MIPv4 draft has dependencies on
CMS
Submitter name: Greg Weber
Submitter email address:
gdweber@cisco.com
Date first submitted: March 30, 2002
Reference: URL to
e-mail describing problem, if available
http://www.merit.edu/mail.archives/aaa-wg/msg03519.html
Document:
MIPv4
Comment type: E
Priority: S
Section: 5.0, 5.2, 5.5.2, 6.0, 10.0,
11.1
Rationale/Explanation of issue:
The MIPv4 draft has several
normative references to the CMS
application draft. If the MIPv4 draft is to
be submitted to
the IESG before the CMS draft is ready, then these
references
should be removed.
Requested change:
From Bernard:
"I would suggest that MIPv4 normative references to CMS be
removed, if it
is expected that MIPv4 be approved for publication prior to
when CMS is
ready."
From Jari Arkko:
"The really crucial and useful piece of information is in the values in
the
MAY P and MAY Encr columns in AVP tables. I'd really hate to lose
this
information. Possible ways to deal with this are:
1) Retain the
information, but formulate the base text in 4.6 to
say "The originator MUST
have local configuration which indicates
that this information can be sent to
the given destination with
only hop-by-hop protection." Essentially, this
limits the base diameter
into doing transactions with just a preconfigured
set of hosts, but
allows later extension (CMS) to remove this
restriction.
2) Move the information from the base/mip/nasreq specs on
P/MAY Encr
to a normative appendix of the CMS spec. Essentially, everything
stays
as it has been, but CMS introduces even the protection policies
for
all AVPs already standardized at the time the CMS spec goes to the
RFC
editor. This approach leaves more freedom than approach 1.
3) Move the
information to a non-normative appendix of the base spec."
Issue 322:Transport nits
Submitter name:
Jari Arkko
Submitter email address: jari.arkko@kolumbus.fi
Date first
submitted: 03-28-2002
Reference:
Document: transport-05, section
3.4.1
Comment type: Editorial
Priority: 1
- "Due to Karn's
algorithm as implemented
SCTP and TCP, ..." has a missing "in" before
the
word "SCTP".
Issue 323:Session-Server-Failover and
STR
Submitter name: Jari Arkko
Submitter email address:
jari.arkko@kolumbus.fi
Date first submitted: April 1,
2002
Reference:
Document: Base
Comment type: T
Priority:
S
Section: 8.18
Rationale/Explanation of issue:
The ALLOW_SERVICE
and TRY_AGAIN_ALLOW_SERVICE cases talk
about what to do after STR fails, and
indicate that, if
the delivery of the STR fails, the session should
be
terminated.
Duh! Isn't the session terminated _anyway_ if we
are
in the progress of sending STRs?
But perhaps I'm missing
something.
Issue 324: New generic host identification
AVPs
Submitter name: Bob Kopacz
Submitter email
address:bkopacz@interlinknetworks.com
Date first submitted: 04-03-2002
Reference:
Document: Base-10, Mobile-IPv4-10
Comment type: Technical
Priority: 1
Section:
Rationale/Explanation of issue:
In
the Mobile IPv4 draft, there are various AVPs which carry the
identity, or
identity+realm, of the various participants in a mobile
session.
The
current plus proposed AVPs are:
- MIP-Home-Agent-Host ::= < Grouped
AVP:... >
{ Destination-Realm }
{ Destination-Host }
* [ AVP
]
- MIP-Home-Agent-Address AVP = IP address of HA
-
MIP-Originating-Foreign-AAA ::= < Grouped AVP:... >
{ Origin-Realm
}
{ Origin-Host }
* [ AVP ]
- MIP-Candidate-Home-Agent-Host =
diameter identity of candidate HA
- MIP-Foreign-Agent-Host = diameter
identity of FA
The existing set of identification AVPs has become
muddled: Sometimes
the realm is part of the information, sometimes the realm
is inferred
from other information. The IP address information is
carried
separately from the identity. And the original meaning of the
existing
Destination-xxx and Origin-xxx AVPs has been overloaded so that new
AVPs
needn't be created.
Requested Change:
1. Create three
generic AVPs, called "Host-Identity" and "Host-Realm"
and
"Host-IPv4-Address", which are intended to be member AVPs of a
grouped AVP.
Define these AVPs in the Base document, right after the 6.x
sections
which define the Origin-xxx and Destination-xxx AVPs. The reason
for
putting these in the Base document is so that they are made
available
to other applications.
"6.x Host-Identity AVP
"The
Host-Identity AVP (AVP Code TBD) is of type DiameterIdentity and
contains the
identity of a Diameter agent. This AVP is intended to be
a member of a
grouped AVP which carries a collection of Diameter
identification information
for a Diameter node.
"6.x Host-Realm AVP
"The Host-Identity
AVP (AVP Code TBD) is of type UTF8String and contains
the realm of a Diameter
agent. This AVP is intended to be a member of
a grouped AVP which carries a
collection of Diameter identification
information for a Diameter
node.
"6.x Host-IPv4-Address AVP
"The Host-IPv4-Address AVP (AVP
Code TBD) is of type IPAddress and
contains the IPv4 address of a Diameter
agent. This AVP is intended to
be a member of a grouped AVP which carries a
collection of Diameter
identification information for a Diameter
node."
2. In the Diameter Mobile IPv4 draft, redefine the
AVPs
which carry the identification information for the
participants in the mobile
session, as follows:
MIP-Originating-Foreign-AAA ::= < AVP Header:...
>
{ Host-Realm }
{ Host-Identity }
MIP-Candidate-Home-Agent ::=
< AVP Header:... >
{ Host-Realm }
{ Host-Identity
}
MIP-Foreign-Agent ::= < AVP Header:... >
{ Host-Realm }
{
Host-Identity }
MIP-Home-Agent ::= < AVP Header:... >
{
Host-Realm }
{ Host-Identity }
[ Host-IPv4-Address ]
Issue 325: Minor clarifications/corrections to
Base-10-2
Submitter name: Bob Kopacz
Submitter email
address:bkopacz@interlinknetworks.com
Date first submitted: 04-05-2002
Reference:
Document: draft-base-10-2
Comment type: Technical
Priority: 1
Section:
Rationale/Explanation of issue:
Minor corrections/clarifications to base-10-2.
Requested
change:
- - - -
In the Table of Contents
1.1.1 Differences
from Radius
Capitalize "Radius"
- - - -
In section 8.1
Authorization Session State Machine
Replace the two entries:
State
Event Action New
State
-------------------------------------------------------------
Open
Home server wants to send ASR Discon
terminate the service
Discon ASA
Received Cleanup Idle
With:
State Event Action New
State
-------------------------------------------------------------
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
Not ASA Received None No Change.
Open
This
per issue#275, which I think was accepted, but the changes
weren't made to
the state table.
- - - -
In section 10.1 Base Protocol Command AVP
Table
Change:
+-----------------------------------------------+
|
Command-Code |
|---+---+---+---+---+---+---+---+---+---+---+---+
Attribute
Name
|CER|CEA|DPR|DPA|DWR|DWA|RAR|RAA|ASR|ASA|STR|STA|
--------------------|---+---+---+---+---+---+---+---+---+---+---+---|
User-Name
|0 |0 |0 |0 |0 |0 |0-1|0-1|1 |1 |1 |1 |
To:
Attribute Name
|CER|CEA|DPR|DPA|DWR|DWA|RAR|RAA|ASR|ASA|STR|STA|
--------------------|---+---+---+---+---+---+---+---+---+---+---+---|
User-Name
|0 |0 |0 |0 |0 |0 |0-1|0-1|1 |0-1|1 |0-1|
This per issue#264 (which I
think was accepted but the changes weren't
made to the occurrence rule
table): "Since it is natural and harmless for
an implementation to echo back
the User-Name, allow but do not require the
User-Name AVP to appear in Answer
messages, if present in the Request."
- - - -
In 14.1 Normative
References
These have expired:
[AAATRANS]
draft-ietf-aaa-transport-04.txt, June 2001.
These are not the
latest:
[CMS] draft-ietf-aaa-diameter-cms-sec-03.txt
- - -
-
In 14.2 Non-Normative References
These are not the
latest:
[DIAMMIP] draft-ietf-aaa-diameter-mobileip-08.txt
[MIPV4]
IP Mobility Support. RFC 2002
[NASREQ]
draft-ietf-aaa-diameter-nasreq-08.txt
- - - -
In section 16
Authors' Addresses
| Questions about this memo can be directed
to:
|
| Pat R. Calhoun
| Black Storm Networks
| 250 Cambridge
Avenue, Suite 200
| Palo Alto, California, 94306
| USA
|
| Phone: +1
650-617-2932
| Fax: +1 650-786-6445
| E-mail:
pcalhoun@diameter.org
I don't think this is Pat's email address (though
it's the one
he encourages me to use :)
- - - -
In section 17
Full Copyright Statement
Copyright (C) The Internet Society (2001). All
Rights Reserved.
Should the year be (2002) ?
- - - -
Issue 326: HA can not know which ip address to
store keys on
Submitter name: Johan Johansson
Submitter email address:
johanj@ipunplugged.com
Date first submitted: 04-07-2002
Reference:
Document: draft-mip-9
Comment type: Technical
Priority: S
Section:
4.8
This is essentially a summary of the discussion regarding issue 305
(Purpose of MIP-Foreign-Agent-Host
AVP). The only possible use that has
surfaced was to enable the HA to know which ip address to use for
it's SA
with the FA.
The need for this in the first place may not be obvious,
but the MobileIP RFC 3220 section 3.2 simply
states that the sa is indexed by
the mobile entities IP address. But which ip address? After examination
of
the involved documents I can not reach any other conclusion than that the
protocols allow at least 3
different possible interfaces: the one that mobile
ip tunneling takes place on, the one that mobile ip
control traffic is sent
from and the one that diameter (control) traffic is sent from.
If we as
stated in section 4.8 simply copy the value of FA-Host from the Origin-Host
field of the incoming
AMR and then perform a DNS lookup, which in itself is
unattractive, we may at best be able to choose a
Diameter interface. If we
assume that the CoA address in the reg request is the one to use we are
choosing
the tunneling interface where a raw mobile ip client would have
access to the "real" ip address.
It seems that raw MobileIP doesn't
handle this case deterministically either and thus probably is a source
of
interopability problems in MobileIP as well. That discussion will be taken with
the MobileIP wg.
In any case we can solve the problem within Diameter
without relying on the resolution within MobileIP by
making the foreign agent
include the proper ip address in the AMR to be forwarded to the home agent.
We
should probably also revamp the FA-Host avp to be an FA-Address
AVP.
Request changes:
Change
"4.8 MIP-Foreign-Agent-Host
AVP
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."
to
"4.8 MIP-Foreign-Agent-Address AVP
The
MIP-Foreign-Agent-Address AVP (AVP Code 330) is of type
IPAddress and
contains the IP address of the foreign agent to be used in the security
association
between the FA and HA. This avp MUST be added by the FA to all
AMRs it sends and MUST be copied to the HAR
sent by the AAAH."
We
*could* make it optional if we could agree on a reasonable default interface. My
best guess for that
would be MIP tunneling interface, in which case we could
go with
"4.8 MIP-Foreign-Agent-Address AVP
The
MIP-Foreign-Agent-Address AVP (AVP Code 330) is of type
IPAddress and
contains the IP address of the foreign agent to be used in the security
association
between the FA and HA. This avp MAY added by the FA to AMRs it
sends and if present the AAAH MUST copy it
to the HAR it sends. If the AVP is
not present the HA MAY assume that the care-of-address of the mobile
node
should be used for its security association with the FA. If the FA requires
co-located mobile nodes
to register with it the MIP-Foreign-Agent-Address AVP
MUST be added to all AMRs."
Of course occurence tables and ABNFs should be
updated too.
j
Issue 327: Message routing and vendor specific
applications
Submitter name: Johan Johansson
Submitter email address:
johanj@ipunplugged.com
Date first submitted: 04-07-2002
Reference:
Document: Base
Comment type: Technical
Priority: S
Section: 2.7,
6.1, 6.1.6, 6.10, 9.7.1
Rationale/Explanation of issue:
We allow
vendor specific applications with their own "namespaces" but we
do not
perform routing on them. Section 6.1.6 simply states:
Diameter request
message routing is done via realms. A Diameter
message that is able to be
proxied MUST include the target realm in
the Destination-Realm AVP. The realm
MAY be retrieved from the User-
Name AVP, which is in the form of a Network
Access Identifier (NAI).
The realm portion of the NAI is inserted in the
Destination-Realm
AVP.
Diameter agents MAY have a list of locally
supported realms, and MAY
have a list of externally supported realms. When a
request is
received that includes a realm that is not locally supported,
the
message is routed to the peer configured in the Realm Routing
Table
table (see section 2.8).
On a side note this should probably be
section 2.7, but the important
part is that nowhere in these paragraphs is
per-application routing
mentioned, let alone vendor-specific
such.
The preceding section 6.1 states
The Destination-Realm AVP
MUST be present if the message is
proxiable. Proxiable request messages MUST
also contain either an
Acct-Application-Id AVP or an Auth-Application-Id
AVP.
while 9.7.1 happily claims
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.
Pretty contradictory if you ask
me.
Finally, the section 2.7 describing the realm based routing table
says
- Application Identifier. A route entry can have a
different
destination based on the Acct-Application-Id for
accounting
messages) or Auth-Application-Id (for non-accounting
messages)
of the message. This field MUST be used as a secondary key
field
in routing table lookups.
It seems to me that it would need to
use vendor id *and* application id
to perform a proper
lookup.
Requested change:
The solution is conceptually simple:
make the routing table store vendor
id and application id and add text to
6.1.6 to take these into account
when routing requests.
We now have
two ways to identify the application of a request. Either it
has a "naked"
Acct/Auth-Application-Id *or* it has a grouped
Vendor-Specific-Application-Id AVP where the Vendor-Id is non-zero.
Granted, the Diameter standard vendor is an important special case but
is it important enough to require a two-stage lookup?
What do you
think?
I'll sneak in an editorial side-issue. Shouldn't we
change
6.10 Vendor-Specific-Application-Id AVP
The
Vendor-Specific-Application-Id AVP (AVP Code 260) is of type
Grouped and is
used to advertise support of a vendor-specific
Diameter Application. Either
the Auth-Application-Id or the Acct-
Application-Id AVP MAY be present.
Exactly one of the Auth-
Application-Id and Acct-Application-Id AVPs MAY be
present.
to
6.10 Vendor-Specific-Application-Id AVP
The
Vendor-Specific-Application-Id AVP (AVP Code 260) is of type
Grouped and is
used to advertise support of a vendor-specific
Diameter Application. Exactly
one of the Auth-
Application-Id and Acct-Application-Id AVPs MUST be
present.
j
Issue 328: Suggestion about hierarchical realms a
poor one
Submitter name: Johan Johansson
Submitter email
address:johanj@ipunplugged.com
Date first submitted: 04-09-2002
Reference:
Document: draft-base-10-2
Comment type: Technical
Priority: 1
Section: 6.1
Rationale:
The suggestion is
that
For routing of Diameter messages to work within an
administrative
domain, all Diameter nodes within the realm MUST be peers.
If
intermediate nodes are desired (see Figure 5), the destination
node
MUST be in a subrealm and routes to that subrealm MUST exist in
the
routing table on the sending node and all intermediate nodes. Figure
5
shows an example of a hierarchical network that requires the use
of
subrealms. In such a network, routing must be performed with
longest
match from right.
Figure 5 then goes on to describe a realm
abc.com with e.g. a subrealm
called eng.abc.com and a relay node in between.
It may not be obvious
from the draft, but the original example discussed
that motivated this
text and figure in the first place as within the context
of the mobile
ip application where there was a home server in the containing
realm
abc.com and the home agents within the respective
subrealms.
Assume that there is a user called john.doe@eng.abc.com whose
AMR is
handled by the server aaah.abc.com. This is a centralized home server
that serves the entire realm abc.com and therefore it has a route for
abc.com that on longest match from right has a LOCAL_ACTION entry.
Unfortunately this will never be selected since it must have a route to
eng.abc.com in order to send the HAR to the home agent, which means that
the AMR will arrive at a very surprised home agent.
Requested
change:
Given the time constraints my suggestion is to fumble the issue
and
remove all mention of it from the document. Route configuration and
network topology, within the context of the Mobile IP Diameter
application at least, is a surprisingly non-intuitive
topic.
j
Issue 329: Minor
corrections/clarifications to base-10 about Failed-AVP
Submitter name: BG
Lee
Submitter email address: bglee@etri.re.kr
Date first submitted:
04-9-2002
Reference:
Document: draft-base-10
Comment type:
Technical
Priority: ?
Section: 7.5 Failed-AVP AVP
In section 7.5
Failed-AVP,
7.5 Failed-AVP AVP
...presence of two or more
occurrences of an AVP which is restricted to 0, 1, or 0-1
occurrences.
..
A Diameter message MAY contain one Failed-AVP AVP, containing the
entire AVP
that could not be processed successfully. If the failure reason is
omission
of a required AVP, an AVP with the missing AVP code, the missing
vendor id, and
a zero filled payload of the minimum required length for the
omitted AVP will be added.
but...
Currently, there is no way to
enter the two or more Reason Code in Result-Code AVP
and it is difficuit to
match the Result-Code AVP and Failed-AVP.
so...
Existing
:
7.5 Failed-AVP AVP
AVP Format
<Failed-AVP> ::=
< AVP Header: 279 >
1* {AVP}
Requested
change:
AVP Format
<Failed-AVP> ::= < AVP Header: 279
>
1* {
{Result-Code AVP}/*Following AVP's Error
Cause Value
included*/
{AVP}
}
Issue 330: Diameter should not require
separate TLS port
Submitter name: Allison Mankin
Submitter email
address: mankin@isi.edu
Date first submitted:
04-10-2002
Reference:
Document: draft-base-10
Comment type:
Technical
Priority: S
Section: 2.1 (contradicts section 13.3)
Justification: The IESG is encouraging WGs to enable their
applications
to negotiate an upgrade to TLS rather than requiring
a separate port.
Diameter cannot yet handle this "startTLS"
up-negotiation. Do not assume
that Diameter will be granted
an addition port for use with TLS.
Change:
Need support for TLS up-negotiation in Diameter.
Issue 331: ABNF not in RFC 2234
format
Submitter name: Allison Mankin
Submitter email address:
mankin@isi.edu
Date first submitted: 04-10-2002
Reference:
Document:
BASE, MIP, NASREQ, CMS
Comment type: Technical
Priority: S
Section:
Many
ABNF not in RFC 2234 format and not checked by an
ABNF checker, e.g.
the one to be found at www.apps.ietf.org
(I think this is true of all the
drafts and it is now
something enforced by IESG - you'll want to make 2234
normative as well...). FYI, Bill Fenner is very devoted to
ABNF checking
and would probably help out on this if asked.
Issue 332: Base introduction needs better
motivation
Submitter name: Allison Mankin
Submitter email address:
mankin@isi.edu
Date first submitted: 04-10-2002
Reference:
Document:
BASE
Comment type: Editorial
Priority: 1
Section: 1.1.1
Base Introduction - I think the introduction could include more
of the
motivation about reliability and failover. It now has a lot of possibly dated
discussion of ROAMOPS instead of more lasting context about the
quantum
advances in reliability, robustness and security.
Issue 333: IANA references
Submitter
name: Allison Mankin
Submitter email address: mankin@isi.edu
Date first
submitted: 04-10-2002
Reference:
Document: BASE
Comment type:
Editorial
Priority: 1
Section: 14.1
[RADTYPE] IANA, "RADIUS Types",
http://www.isi.edu/in-
notes/iana/assignments/radius-types
Cite this
at iana.org URL, not the old isi one.
Issue 334: Only DWR/DWA to be used to
supervise transport connection
Submitter name: Bo Landarv
Submitter
email address: bo.landarv@ipunplugged.com
Date first submitted: April 11,
2002
Reference:
Document: transport-06
Comment type: T
Priority:
1
Section: Appendix A
Rationale/Explanation of issue:
Appendix A
gives the impression that any request can be used to
supervise the
connection. If we have an outstanding session-related
request it can take the
role of the DWR.
The DWR/DWA sending and receiving is a simple mechanism
between
two neighbours. An arbitrary request/answer pair, on the other
hand,
might involve proxies, complicated processing etc and should
not
IMHO be able to in any way affect the status of the
connection.
Requested change:
State that "Pending" is set to true
if and only if there is an
outstanding, unanswered DWR.
Procedure
OnSendRequest should not call action SetWatchdog().
Date: Thu, 11 Apr 2002 08:04:57 -0700 (PDT)
From: Bernard Aboba
<aboba@internaut.com>
To: Bo Landarv
<bo.landarv@ipunplugged.com>
Cc: aaa-wg@merit.edu
Subject: Re:
[AAA-WG]: [issue 334] Only DWR/DWA to be used to supervise transport
connection
Let me see if I can summarize your issue and determine the
source of the
problem.
That goal of the heartbeat is to allow peers to
determine the
"liveness" of their neighbors without adding unnecessary
traffic. To quote
from RFC 2865, section 2.6:
" Some implementers have
adopted the practice of sending test RADIUS
requests to see if a server is
alive. This practice is strongly
discouraged, since it adds to load and harms
scalability without
providing any additional useful information."
As a
result, a heartbeat is only sent if there has been no other traffic
to verify
liveness of the peer. In a proxy or relay system, it is possible
that the
response will be delayed due to many factors, such as an
overloaded or failed
downstream proxy or server. It is important that
issues encountered
downstream not induce failover on a perfectly
functional connection, since
the immediate neighbor may have little to
do with the cause of the delay.
In the transport state machine described in Appendix A, normal traffic
sent to a peer is included as part of the watchdog activity in order
to
avoid sending additional traffic unless absolutely necessary. The
watchdog
timer is reset whenever a response is received, including receipt of
a
watchdog response. On sending a message, if the send queue is empty,
then
the watchdog timer is reset. If the watchdog timer expires and the
send
queue is empty, then a watchdog packet is sent.
If the watchdog
timer expires and a response is pending, then failover is
initiated.
Let's look at a hypothetical case:
A ------------- B
----------------- C
B' --------------- C'
Diameter client A is
using relay B as the primary to talk to server C.
However it also has relay
B' as its secondary, which it can use to talk to
server C or C'.
Let's assume that B and B' are both healthy and that the
connection
between them and A are fine, but that there is a problem with C.
Ideally,
we'd want B to failover from C to C', and have this not affect
the
connection between A and B, since there is nothing wrong with this.
If there was nothing in the send queue when A sent its request to B,
then
the watchdog timer would have been reset. Since there was a problem
with
C, B has to initiate its own failover to C', and as a result, a
response
may not be sent before A's watchdog timer expires. Since there
is
something in the send queue (A's request to B), failover will
be
initiated. This is wrong because had a watchdog been sent to B, then
it
would have received a reply and no failover would have occurred.
Therefore, I think that the requested change is that failover only
be
initiated on failure to receive a response to a watchdog packet. While
a
successful response to any Diameter request can reset the watchdog
timer,
only a failure to receive a watchdog response can cause failover.
The requested change is:
State that "Pending" is set to true if and
only if there is an
outstanding, unanswered DWR. Procedure OnSendRequest
should not call
action SetWatchdog().
I think that this is correct.
Let me describe what the overall algorithm
now looks like:
1. The
watchdog timer is reset whenever any response is received from the
peer,
including receipt of a watchdog response.
2. If the watchdog timer
expires and there is no pending watchdog
response, then the watchdog packet
is sent and the watchdog timer is
reset.
3. If the watchdog timer
expires and there is a pending watchdog response,
then failover is
initiated.
This simplifies things, since there is no need to deal with
requests other
than watchdogs. It appears to deal with the example:
1.
If no packet had been sent in a while, then a watchdog packet would
have been
sent and the timer reset. As long as B kept answering the
watchdog packets,
the connection would stay up, regardless of whether B
was failing over to
C'.
2. As long as requests sent through B were being answered, the watchdog
timer would be continuously reset and no watchdog packets would need to
be
sent. However, when C dies, the responses would stop and once the
timer
expired, then a watchdog would be sent from A to B. Since B would
respond,
the connection from A to B would stay up.
More comments on the proposed
fix:
Date: Fri, 12 Apr 2002 00:56:36 -0400
From: Allison Mankin
<mankin@isi.edu>
To: Bernard Aboba <aboba@internaut.com>
Cc:
jonwood@speakeasy.net, mankin@isi.edu, randy@psg.com
Subject: Re: Diameter
Issue #334
Bernard,
I've looked over the new text and Appendix A
and it looks like
you addressed the bug with correct changes.
I tried
to read the appendix carefully - one thing I noticed
is that send_dog is
written three different ways.
Also, the new point brings home that
there's a slightly
misleading sense to Application Layer Watchdog, if you
don't
remind readers in the start of 3.4 that the application
endpoint
being tested is that of the peer, whether it's a
server or an agent along the
way to the server.
In other words, it would probably be useful for 3.4 to
include
a drawing of the simple and complex cases so that the sense
of
"application" is clearer.
A few other notes from reading through the
draft again.
> 2.2. Slow failover
>
> Where TCP [RFC793]
is used as the transport, AAA implementations will
> experience very slow
fail over times if they wait until a TCP connection
> times out before
resending on another connection. This is not an issue
> for SCTP
[RFC2960], which enables adjustment of the failover timer at
> the
transport layer.
I've probably glanced over this in the past - it seems
to
mislead: About TCP, the failover times are pretty in line
with what's
appropriate to the net when the Watchdog is used.
About SCTP, which
adjustment is meant?
-----
3.4.1 (3)
> Multiple identical
requests
> or answers MAY be received as a result of a failover.
Seems this shouldn't be an uppercase
MAY...
-----
3.6
> since SCTP tracks the amount of data in
flight by bytes, not
> segments.
Actually for reliability, both
track in bytes, and TCP differs
from SCTP only in that it tracks the Slow
Start in segments.
So s/amount of data in flight/progress for opening of
the
congestion window/
-----
> Security
Considerations
What's here is skimpy. What about issues of attacks
possible
by causing spurious failovers, as one example of a
missing
consideration? Another bit this could mention is that
SCTP
improves on TCP's DoS resilience. More should be
considered.
-----
> Normative References
I'm afraid it's
ok to recommend using an Exper RFC in a PS,
but not ok for a PS to be
normative on an Exper . So you should shift
some of the references to
Informative (I think this rule will be
Date: Fri, 12 Apr 2002
11:31:32 +0200
From: Bo Landarv <bo.landarv@ipunplugged.com>
To:
Bernard Aboba <aboba@internaut.com>
Cc: jonwood@speakeasy.net,
mankin@isi.edu, randy@psg.com, aaa-wg@merit.edu
Subject: RE: [AAA-WG]: [issue
334] Only DWR/DWA to be used to supervise transport
connection
Hi!
I am happy with the changes.
I just have some
comments/questions.
* The base draft some versions ago made the
distinction between
Ti/Tr/Tw timer values. Maybe to separate Ti and Tr
doesn't
give that much, but how about the distinction between the
time
when to send the next DWR and when to expect a DWA?
I think it might be
useful to set different times for these.
* In chapter 3.4.1 and Appendix
A it says "Tw responses are pending",
"watchdog responses are pending",
"unanswered watchdog requests".
Always in plural and not singular. Is this
because you include
retransmissions of lower protocol layers? I would have
felt less
confused with singular.
* Chapter 3.4.1 item 2 "On sending a
watchdog request, if no watchdog
responses are pending, then Tw is
reset."
I get some bad vibrations here. Couldn't we say something like
"On
sending a watchdog request, Tw is reset" and
"We only send a watchdog request
when there is no watchdog response
pending."
* Appendix A. You
switched the order of the functional approach and
the state machine.
Perfectly fine with me.
* Appendix A. In the functional approach you
have two assignments
for variable Pending with "==". Should only be one =
token.
* Appendix A. Definition of Sendwatchdog(pcb) instead of
SendWatchdog(pcb).
* Appendix A. A new event Senddog was added. I
don't think you
need this nor the transitions for Senddog.
SendWatchdog()
does the job, doesn't it?
That's all.
/Bo Landarv
Issue 335: CMS Security does not protect against
session-key replay
Submitter: Jesse Walker
Submitter email address:
jesse.walker@intel.com
Date first submitted: April 16, 2002
Reference:
http://www.ietf.org/internet-drafts/draft-walker-aaa-key-distribution-00.txt
Document:
MIP, NASREQ, Base
Comment type: T
Priority: S
Section:
Rationale/Explanation of issue:
CMS wrapping of session keys does not
explicitly protect the
key distribution from replay.
Thus, although the
NAS itself can assume a CMS-wrapped key is genuine
and issued from the AAA
server, the NAS cannot determine that the AVP
it receives has not been
issued already for some prior session.
Instead, the NAS must assume that the
AAA server is playing by the
rules and issuing only fresh keys, and that
there is no man-in-the-
middle replacing AVPs before or after they are
unwrapped by a lower-
layer security mechanism. Many session establishment
handshakes do
not define adequate key confirmation handshakes, so the NAS
could end
up sending new data encrypted under already-used keys and IVs
before
the problem can be detected, potentially compromising previously sent
data. Relying on TLS or IPsec does not solve
the problem, because the
replay protection afforded by such low-level
mechanisms is not adequately
bound to the AVP to prevent a Trojan
horse from substituting an old AVP for
the new one without detection.
Proposed change:
What is needed to defeat this kind of attack is to require the
AAA server
to incorporate a challenge from the NAS (and/or the NAS
client) into the
NAS-Session-Key AVP prior to wrapping. (Inserting a
timestamp into the AVP
is another option, but maintaining
synchronized time in many of the
environments served by an AAA server
introduces its own problems.)
Issue 336: Clarify relationship between auth and
accounting sessions
Submitter name: Johan Johansson
Submitter email
address: johanj@ipunplugged.com
Date first submitted:
2002-April-30
Document: base (could also be that mip is the correct
one)
Comment type: T
Priority: S
Section: 9.6
Rationale/Explanation
of issue:
What is the relationship between session ids of authorizing
sessions and
accounting sessions, i.e. is there a difference between the
authorizing
session and the accounting one? There seems to be certain
advantages to
saying that they are separate sessions as I will describe
below and I am
not aware of any real benefit from saying that they are to be
regarded
as the same session. All relevant information is transported in
each ACR
and thus there seem to be little to be gained by correlating the
accounting and authorization sessions based on the value of the
Session-Id AVP.
Differences between implementations will inevitably
lead to
interopability problems.
The following scenario is from the
mip application, but it boils down to
whether accounting sessions have the
same id as authorization sessions.
The AAAH server may change for a variety
of reasons, but the home agent
(HA) must remain the same for the duration of
the Mobile IP session.
When a foreign agent (FA) sends an authorization
request the AAAH
initates a session involving the home agent. Since we have
moved to a
new AAAH the HA will receive a request for a session whose id is
different from the one already active for the same user on the HA.
According to the mip application the HA must replace it's existing
session with the new one while retaining the same Acct-Multi-Session-Id.
The follow-up question to this is what happens to the accounting. Do we
send a new start record and start from scratch or do we continue with
our existing accounting session? In many ways it would be more elegant
and leave less room for errors to keep the existing accounting session,
but this would require that it is in fact a separate session.
I am
not sure whether this is properly a base or mip issue since section
9.6.
states
A Diameter application document MUST define the exact concept of
a
session that is being accounted
but the issue itself is quite
fundamental.
Requested change:
The Diameter protocol's Session-Id
AVP, which is globally unique (see
section 8.8), is used during the
authorization phase to identify a
particular session. Services that do not
require any authorization
still use the Session-Id AVP to identify
sessions.
to:
The Diameter protocol's Session-Id AVP, which is
globally unique (see
section 8.8), is used during the authorization phase to
identify a
particular session. Services that do not require any
authorization
still use the Session-Id AVP to identify sessions. Accounting
messages
MUST use a different Session-Id from that sent in authorization
messages.
j
Issue 337:MIP-10 Nits
Submitter name:
julien Bournelle
Submitter email address: bournell@int-evry.fr
Date
first submitted: 04-28-2002
Reference:
Document: MIP-10
Comment type:
Editorial
Priority: 1
Hi,
I've just noticed 2 typos in draft 10 concerning Mobile IPv4
application:
p.6 §1.2
"When a Mobile Node node
requests..."
=> "When a Mobile Node requests"
p.19
§2.2
"An AMA message ...., MUST include the MIP-Home-Mobile-Node-Address
AVP.."
=> "An AMA message ..., MUST include the
MIP-Mobile-Node-Address AVP"
Hope it helps,
Issue 338:Diameter Mobile IP application &
backwards compatibility
Submitter name: Tony Johansson
Submitter email
address: tony.johansson@ericsson.com
Date first submitted:
2002-04-25
Reference:
Document: mip-10
Comment type: T
Priority:
S
Section:
Rationale/Explanation of issue:
In the existing
deployments of Mobile IP clients, especially those that
will soon be deployed
for IS-835 (the cdma2000 standard). There have
been concerns raised about
mandating the use of the AAA NAI extension in
the mip-10 as it requires
restrictions on the client-to-network
interface.
Requested
change:
As the mip-10 now is worded the AAA NAI is mandatory to over come
the
previous found issues, e.g. in cases of multiple AAAH's in the
same
domain, etc. However, to over come backwards compatibility issues
for
those that would like to let Mobile IP clients (i.e. those clients
that
are now deployed) run with the Diameter Mobile IPv4 application
with
limited functionality, I would like to change the text in the
mip-10
draft from a MUST to a SHOULD for the use of the AAA NAI extension.
In
other words, make the AAA NAI/HA NAI optional and the consequences
of
not using the AAA NAI/HA NAI would be beyond the scope of the draft.
Issue 339: "Closed" in peer state machine vs
"DOWN" in failover state machine
Submitter name: Qiong Bo
Liu
Submitter email address: liuqb@cwc.nus.edu.sg
Date first submitted:
April 26, 2002
Reference:
http://www.merit.edu/mail.archives/aaa-wg/msg03954.html
Document: base-10,
transport-07
Comment type: T
Priority: S
Section: 5.6 in base, 3.4.1
and appendix A in transport; also 5.6.3 in Base
Rationale/Explanation of issue:
in Diameter base protocol-10,
section5.6, the 2nd paragraph: "This state
machine is closely coupled with
the state machine described in [AAATRANS],
which is used to open, close,
failover, probe, and reopen transport
connections. Note in particular that
[AAATRANS] requires the use of
watchdog messages to probe connections. For
Diameter, DWR and DWA messages
are to be used."
in transport-07,
appendix A, there is a failover state machine with a state
of
DOWN.
In the state of DOWN, does it mean that this transport connection
is
closed, and the related socket is closed. hence when tw time expires, the
diameter node try to open another socket and try to connect to the
peer?
If it is, then what is the difference between DOWN and
closed?
Requested change:
suggest to give a complete peer state
machine combining with failover state
machine
Also:
in base-10, section 5.6.3, one action named Snd-Conn-Ack is defined, but it
doesn't appear in the peer state machine. Therefore suggest to delete this
action from the document.
Issue 340: Usage
of 'Diameter process' confusing
Submitter name: Greg Weber
Submitter
email address: gdweber@cisco.com
Date first submitted: 5/7/2002
Reference:
none
Document: base
Comment type: 'E'ditorial
Priority: '2' May fix
Section: 2.1 Transport
Rationale/Explanation of issue:
Regarding
this this text:
"A Diameter node MAY initiate connections from a source port
other
than the one that it declares it accepts incoming connections on,
and
MUST be prepared to receive connections on port TBD. A given
Diameter
process MUST NOT use more than one transport connection
to
communicate with a given peer, unless multiple processes exist on
the
peer in which case a separate connection per process is
allowed."
The term "process" seems to be used in an operating system
specific
manner. This may be confusing, e.g. what is the 'Diameter
process'
in a JVM implementation where there are no processes, only threads.
We should be explicit as we are expressing what MUST NOT be
done.
'Diameter process' is not defined elsewhere in the
draft.
Requested change:
I suggest changing "process" to "instance of
the peer state machine"
Issue 341: Realm Routing Table and Section
6.1
Submitter name: Julien Bournelle
Submitter email address:
Julien.Bournelle@int-evry.fr
Date first submitted: May 3, 2002
Document:
base
Comment type: E
Priority: 2
Section: 2.7 and
6.1
Rationale/Explanation of issue:
We have section 6.1:
"
When
a message is received, the message is processed in the following
order:
1.
If the message is destined for the local host, the procedures
listed in
section 6.1.4 are followed.
2. If the message is intended for a Diameter peer
with whom the
local host is able to directly communicate, the
procedures
listed in section 6.1.5 are followed. This is known as
Request
Forwarding.
3. The procedures listed in section 6.1.6 are
followed, which is
known as Request Routing.
4. If none of the above is
successful, an answer is returned with
the Result-Code set to
DIAMETER_UNABLE_TO_DELIVER.
"
Concerning 2.:
Maybe it could be nice
to have a clear definiton of "a Diameter peer with whom
the local host is
able to directly communicate". Is it only a peer in the
Diameter Peer table
?
Concerning 3.:
We must follow section 6.1.6
Section
6.1.6:
"
6.1.6 Request Routing
Diameter request message routing is
done via realms. A Diameter
message that is able to be proxied MUST include
the target realm in
the Destination-Realm AVP. The realm MAY be retrieved
from the User-
Name AVP, which is in the form of a Network Access Identifier
(NAI).
The realm portion of the NAI is inserted in the
Destination-Realm
AVP.
Diameter agents MAY have a list of locally
supported realms, and MAY
have a list of externally supported realms. When a
request is
received that includes a realm that is not locally supported,
the
message is routed to the peer configured in the Realm Routing
Table
table (see section 2.8).
"
It appears that the only case for
which we must use the Realm Routing Table
not need LOCAL action. So is it
useful to have this action in the Realm Routing
Table ?
May I miss
something ?
Issue 342: Vendor-Specific Application
IDs
Submitter name: Allison Mankin
Submitter email address:
mankin@isi.edu
Date first submitted: May 2, 2002
Document: base
Comment
type: T
Priority: S
Section: 1.3.3, 1.2.4
Rationale/Explanation of
issue:
Since new Diameter applications MUST define at least one
Command Code, and
Vendor-Specific command codes are not
permitted, it is not clear why
Vendor-Specific Application
IDs are needed. I thought these were to have been
removed.
If the intent is only to use some vendor-specific AVPs, why
is a
vendor-specific application ID also needed?
Change requested:
Remove support for vendor-specific application IDs.
Issue 343: Location of Proxy-Info and Route-Record
AVPs
Submitter name: Yoshihiro Ohba
Submitter email address: yohba@tari.toshiba.com
Date first submitted: May 21, 2002
Reference:
Document: base
Comment type: T
Priority: 1
Section: 8.3.1 etc.
Rationale/Explanation of issue:
In the following message format of Re-Auth-Request command described
in section 8.3.1, Proxy-Info and Route-Record AVPs, which are defined
to be optional, comes after "[ AVP ]" (this comment also applies to
other commands that define AVP(s) after "[ AVP ]"):
Message Format
<RAR> ::= < Diameter Header: 258, REQ, PXY >
< Session-Id >
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Destination-Host }
{ Auth-Application-Id }
{ Re-Auth-Request-Type }
[ User-Name ]
[ Origin-State-Id ]
* [ AVP ]
* [ Proxy-Info ]
* [ Route-Record ]
But I think this definition contains the following ambiguity.
If the intention is that those AVPs are optional but to be put at the
tail of the command, they should be defined as AVPs with fixed
position like:
<RAR> ::= < Diameter Header: 258, REQ, PXY >
< Session-Id >
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Destination-Host }
{ Auth-Application-Id }
{ Re-Auth-Request-Type }
[ User-Name ]
[ Origin-State-Id ]
* [ AVP ]
* < Proxy-Info >
* < Route-Record >
Otherwise, if those AVPs are just optional AVPs without a special
position requirement, it would be better to define the format as:
<RAR> ::= < Diameter Header: 258, REQ, PXY >
< Session-Id >
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Destination-Host }
{ Auth-Application-Id }
{ Re-Auth-Request-Type }
[ User-Name ]
[ Origin-State-Id ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ AVP ]
Requested change:
Needs more clarification or change the format to remove ambiguity.
Issue 344: Editorial issues with CMS-04
Submitter name: Russ Housley
Submitter email address:
rhousley@rsasecurity.com
Date first submitted: May 15, 2002
Document:
cms-04
Comment type: E
Priority: 1
Section: Various
Rationale/Explanation of
issue:
Dear Authors:
I have just finished going through draft-ietf-aaa-diameter-cms-sec-04, and
I have a few questions and comments.
1. On page 4, the terms MUST, SHOULD, and MAY are used before the
requirements language explanation. I suggest that section 1.1 be moved up
two paragraphs, and that those two paragraphs become section 1.2. Of
course, you then need to renumber the subsequent subsections.
2. On page 6, in the paragraph right after figure 2, you say:
This document defines the Diameter commands that are used to
establish a DSA through Diameter agents, and specifies how
encapsulating CMS objects [CMS] in Diameter AVPs can provide
authentication, integrity, confidentiality and data origin
authentication. CMS objects MAY also be used to transport X.509
certificates and revocation lists.
What is the difference between "authentication" and "data origin
authentication?" Should I interpret "authentication" as peer entity
authentication?
3. On page 7, you say:
... In the latter case, the proxy agent acts as
an access device of sorts and the rules in section 1.2 should be used
instead.
Instead of what? Can we drop the word?
4. On page 12, in the 3rd paragraph of section 3.1, you say:
Revalidations SHOULD also occur before the DSA expires according to
PKI policies. During the process of certificate path validation some
implementations will calculate a duration for which the certificate
path may be considered "safe". For example, ...
Please change "certificate path" to "certification path." This is the term
used in RFC 2459 and RFC 3280. Please ensure that the correct term is used
throughout the document.
5. On page 13, in the 3rd bullet in the middle of the page, you say:
- the list of direct trust CA's that the originating Diameter
node has configured into it for certificate validation. A
"direct trust" CA is one that the node is willing to use as the
"top" of a certificate chain, sometimes confusingly known as a
"root CA."
Please use the term "trust anchor" instead of "direct trust CA." Trust
anchor is defined in RFC 3280.
6. On page 15, in the 5th paragraph from the top of the page, please add
"checking" after "If certificate revocation."
7. On page 17, at the end of section 3.3, please add:
Implementations MAY support other algorithms.
8. On page 22, in the 1st paragraph of section 6.0, you say:
This section contains AVPs that are used to establish a Diameter
Security Association, and to transport CMS objects. Except as
specifically constrained, the profile of CMS algorithm and structure
usage is as specified in the S/MIME v3 message specification [MSG].
I have two comments. First, CMS is not an "algorithm." I suggest "... of
the CMS is specified ..." Second, I am confused about the reference to
[MSG]. You use very little that is defined there. You use different
algorithms. You do not use the MIME encoding. Why reference it at
all? The only place that it seems relevant is in the discussion of
certs-only messages.
9. On page 23, after the table, there is another use of "CMS algorithm."
Please fix it too.
10. On page 23, after the table, there is further discussion of
[MSG]. Basically, the two paragraphs after the table are saying that [MSG]
is irrelevant.
11. On page 24, in the 1st full paragraph on the page, please change
"sequentially" to either "subsequently" or "serially."
12. On page 24, 2nd to last paragraph in section 6.1, please add (at the
end):
The ciphertext is signed.
15. On page 27, in the 1st paragraph of section 6.8, the discussion of the
certs-only message should reference [MSG]. Best I can tell, this is the
only aspect of [MSG] that is being use in the specification, and it is
being used without the MIME wrapper (I think). You should be explicit
about whether the MIME wrapper is being used.
16. On page 32, in the last paragraph of section 10.0, please change "SA"
to "DSA."
17. On page 32, section 10.0, should discuss replay detection.
18. Please reference rfc2630bis and cmsalg documents instead of
[CMS]. These two documents from the S/MIME working group have finished
IETF Last Call, and I think that the last IESG DISCUSS vote was cleared
yesterday.
19. Please change [CERTPROF] to reference RFC 3279 and RFC 3280. Note
that some places [CERTPROF] is used in reference to algorithms, and these
should reference RFC 3279. One example is at the top of page
27. Other places, [CERTPROF] is used in reference to certificates, and
these should reference RFC 3280.
Thanks for you attention.
Russ
Issue 345: Usage of Id-Data
Submitter name:
Russ Housley
Submitter email address:
rhousley@rsasecurity.com
Date first submitted: May 15, 2002
Document:
cms-04
Comment type: T
Priority: S
Section: page 24
Rationale/Explanation of
issue:
On page 24, last paragraph on the page, you say:
The contentType of the EncryptedContentInfo value MUST be id-
data [MSG].
Please do not do this! The IESG complained about id-data, and the
following text was added to the update to RFC 2630 (rfc2630bis) to address
the complaint:
S/MIME uses id-data to identify MIME encoded content. The use of
this content identifier is specified in RFC 2311 for S/MIME v2
[OLDMSG] and RFC 2633 for S/MIME v3 [MSG].
Since you are not MIME encoding your content, please do not use id-data. I
will be glad to assign you a new OID for Diameter AVPs.
Issue 346: Harmonization of Public Key Hash AVP
Submitter name: Russ Housley
Submitter email address:
rhousley@rsasecurity.com
Date first submitted: May 15, 2002
Document:
cms-04
Comment type: T
Priority: S
Section: Section 6.4.2, page 26
Rationale/Explanation of
issue:
On page 26, section 6.4.2, you define an AVP that is the SHA-1 hash of
the public key. I similar construct is defined in
draft-ietf-pkix-okid-01.txt. Can we harmonize these specifications?
Issue 347: RADIUS/Diameter protocol interactions
Submitter name: David Spence
Submitter email address: DSpence@Interlinknetworks.com
Date first submitted: March 14, 2002
Reference:
Document: NASREQ
Comment type: T
Priority: S
Section: 9
Rationale/Explanation of issue:
Section 9 of the nasreq draft addresses RADIUS/Diameter Protocol
Interactions. This issue documents protocol interaction questions
that still need to be addressed in section 9.
1. I believe there are errors regarding the generation of Origin-Host
AVP when translating a RADIUS request to a Diameter request.
2. How do we translate a RADIUS accounting request with an
Acct-Status-Type of Accounting-On or Accounting-Off?
3. How do we deal with the requirement that accounting AVPs be
included in Accounting-Answer (ACA) messages when gatewaying
between RADIUS and Diameter? (By the way, I've forgotten why do
accounting AVPs appear in ACAs?)
4. Discuss how to translate a Diameter request not requiring
authentication into a RADIUS request.
5. Specify what a gateway should do if it receives an
Authorization-Lifetime AVP in a Diameter AA-Answer (AAA) message
and needs to generate a RADIUS Access-Accept. The result will not
be pretty.
6. Specify how a gateway should process a Diameter Re-Auth-Request.
It will have to generate an answer saying that re-auth is not
possible.
7. Specify how a gateway should process a Diameter
Abort-Session-Request (ASR) message. It will have to generate an
answer saying that aborting the session is not possible.
8. In Diameter, the Reply-Message AVP may have a value field longer
than 253 bytes. If so, it will have to be split into multiple
Reply-Message attributes when creating the corresponding RADIUS
message. However the converse -- recombining multiple
Reply-Message attributes into a single Reply-Message AVP -- is not
required. There may be other attributes that fall into the same
category. Generally, any Diameter AVP with a type based on octet
string where the AVP Code is less than 256 and the length of the
AVP data field is greater than 253 will need to be split into
multiple RADIUS attributes.
9. When processing a Diameter AA-Request (AAR) message containing a
Session-Timeout AVP or an Idle-Timeout AVP, drop these attributes
when generating the corresponding RADIUS Access-Request. These
attributes are allowed in Diameter requests as a hint to the
server but are not allowed in RADIUS requests.
10. Explain how to encapsulate and decapsulate the RADIUS
Vendor-Specific attribute. (This item is the same as issue 255.)
11. Add an explicit list of RADIUS attributes that MUST NOT appear in
a Diameter message. There are several of these that have been
superseded by Diameter AVPs of one sort or another. In some
cases there is already text in section 9 explaining how to handle
these attributes. We need to make sure all are covered. The
following is the list of attributes I *think* should be excluded
from Diameter.
CODE NAME RADIUS RFC
------ ---- ----------
3 CHAP-Password RFC 2865
26 Vendor-Specific RFC 2865
40 Acct-Status-Type RFC 2866
42 Acct-Input-Octets RFC 2866
43 Acct-Output-Octets RFC 2866
47 Acct-Input-Packets RFC 2866
48 Acct-Output-Packets RFC 2866
49 Acct-Terminate-Cause RFC 2866
52 Acct-Input-Gigawords RFC 2869
53 Acct-Output-Gigawords RFC 2869
80 Message-Authenticator RFC 2869
Requested change:
Just do it!
Issue 348: Fix NASREQ References
Submitter name: David Spence
Submitter email address: DSpence@Interlinknetworks.com
Date first submitted: March 14, 2002
Reference:
Document: NASREQ
Comment type: E
Priority: S
Section:
Rationale/Explanation of issue:
Requested change: Classify all references as normative/nonnormative.
Issue 349: Accounting Response Bloat
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: May 27, 2002
Reference:
Document: Base
Comment type: T
Priority: S
Section: 9.7.2 (Base)
Rationale/Explanation of issue:
Early on, Accounting Response bloating was identified as an
issue in Diameter. For example, this is cited in
Section 3.5 of draft-ietf-aaa-issues-05.txt, which
refers to "SNMP-style" response bloat within Diameter.
The problem is having the AVPs included in the Accounting-Request
echo'd in the Accounting-Answer, greatly increasing the size
of the ACA message.
Section 9.7.2 of Base states:
"The Accounting-Answer command contains the same Session-Id and
MAY contains the same Accounting Description and Usage AVPs
that were sent in the Accounting-Request command."
This is inappropriate. The only reason that the usage AVPs should
be included in the Accounting-Answer is if the NAS specifically
requests this, such as by including the CMS-Data AVP.
Issue 350: Mandatory Security
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: May 28, 2002
Reference:
Document: Base
Comment type: T
Priority: S
Section: 2.2
Rationale/Explanation of issue:
Security is mandatory to implement in Diameter Base, but not
mandatory to use. This makes little sense, since security
is mandatory to use in RADIUS.
Section 2.2 of Base states:
"Operating the Diameter protocol without any security mechanism is not
recommended."
Change to:
"The Diameter protocol MUST NOT be used without any security
mechanism (TLS or IPsec)."
Issue 351: Security review of MIP-11
Submitter name: Luis A. Sanchez
Submitter email address: lsanchez@xapiens.com
Date first submitted: July10, 2002
Reference:
Document: Base
Comment type: T
Priority: S
Section: Many
Rationale/Explanation of issue:
General Comments
----------------
- The document uses terminology used in other standards documents. For
example, in the IPsec context, security associations are simplex and
uniquely identified by the triple (IP address, SPI, protocol). It is not
clear if there is a 1 to 1 mapping between IPsec security associations
and the "security associations" between mobile nodes and AAA servers.
- There is no explanation on the KDC functionality with message
exchanges in the introduction section. This would help understand the
feature.
- The KDC part of the protocol is not symmetric. It sends keying
material to the MN and sessions keys to the FA. It is not clear why this
is the case.
- The security considerations sections does not provide any
considerations about the KDC feature of the protocol.
Specific Comments
-----------------
Section 1.0
1) Combined with the Inter-Realm capability of the base protocol, this
application allows mobile nodes to receive service from foreign
service providers.
Problem: Confusing sentence, what protocol?
Suggestion: "... capability of the Diameter base protocol...
2) Strong authentication and confidentiality of session keys is
required, and it is recommended to be provided using the CMS security
application [CMS], but may be provided via other security mechanisms,
e.g. using mutually authenticated TLS or IPsec when deployed in an
environment without Diameter agents, then hop-by-hop security is
sufficient for protecting session keys.
Problem: Missing a comma or period after "IPsec". Otherwise it reads as
a recommendation to use IPsec only when Diameter agents are *NOT* present.
Suggestion: "... but may be provided via other security mechanisms,
e.g. using mutually authenticated TLS or IPsec, when deployed in an
environment without Diameter agents, then hop-by-hop security is
sufficient for protecting session keys."
Section 1.2
1) "This means that
without support of the AAA NAI extension, the FA may not be able to
guarantee, that the AMR well be destined to the same AAAH, which
previously authenticated and authorized the mobile node, since the FA
may not know the identity of the AAAH."
Problem: extra word (well) found in sentence fragment.
Suggestion: Please delete "well" in front of "be destined"
2) "Upon receipt of the HAA, the AAAH creates the AA-Mobile-Node-Answer
(AMA) message, includes the Acct-Multi-Session-Id that was present in
the HAA, and the MIP-Home-Agent-Address, MIP-Mobile-Node-Address AVPs
in the AMA message, enabling appropriate firewall controls for the
penetration of tunneled traffic between the home agent and the mobile
node."
Problem: The authors mention firewall controls and there is no clear
understanding on what exactly does it mean in this context. For example,
does it means that one of the AVPs will include packet filtering rules
that MUST be implemented in some firewall? If so, what are the selectors
fields for these rules, what entity will push these rules to the
firewall and how one validate the authenticity of the rules. One may
also want to provide confidentiality to such rules. The latter can
piggyback on the existing secured exchanged but it needs some
clarification. As you can see this opens a can of worms.
Suggestion: Please clarify what is meant by "firewall controls" and
establish the exact operation and security model (if needed). If meant
something different please clarify too.
Section 1.4
1) If no security association
exists between the AAAH and the originating AAAF, the AAAH will make
use of the CMS application [CMS] to establish this association.
Problem: This statement seems to imply that the only mechanism that can
be used to establish a security association is CMS which contradicts
previously made statements.
Suggestion: Modify statement to include other mechanisms such as IPsec.
2) Figure 6: Mobile IP/Diameter Message Exchange
Problem: Same figure caption as in figure 2.
Suggestion: Change caption to indicated that it is "Figure 6: Mobile
IP/Diameter Message Exchange when HA is in Visited Realm" or something
similar.
3) If the mobile node is allowed to keep the home agent the AAAH then
sends a HAR, which contains the Mobile IP Registration Request
message data encapsulated in the MIP-Reg-Request AVP and the MIP-
Home-Agent-Address AVP with home agent address, as well as any
optional KDC session keys, to the AAAF in foreign network 1.
Problem: First time KDC is mentioned and no further explanation is given.
Suggestion: Introduce the entire KDC feature first. Architecture view
should suffice. Need to explain the security for each message exchange.
Section 1.6
1) Diameter Session Termination
Problem: When an STR is sent what happens to the session keys?
Suggestions: All resources (including session keys) must be deallocated
(destroy) at the AAAH.
Section 5.1
1) A value of zero indicates infinity (no time-out).
Problem: This setting is of high security risk. However useful for
debugging purposes.
Suggestion: Please make a note in the document indicating that this
setting is not recommended since keeping session keys for a long time
(no refresh) increases the vulnerability of the system.
Section 5.2
1) The key sent to the mobile node is always in the form of key
material, which the AAAH does by generating a random [RANDOM] value
of at least 64 bits.
Problem: The KDC system is asymmetric. It sends keying material in one
case (to the MN) and session keys in other cases (FA).
Suggestion. Make the system symmetric. THe home AAAH server MUST
generate all session keys and send them to the MN, FA and HA respectively.
2) The following is an example of a
session creation procedure, using MD5 as the hashing algorithm.
Additional algorithms are supported, and listed in [MIPKEYS].
MD5(AAA-Key | key material | node-address | AAA-Key)
Problem: For key derivation, this document recommends using
MD5/prefix+suffix mode. Back in 1996 Bellare, Canetti and Krawczyk
published a paper on crypto discussing how a keyed hash function used in
append/pre-append mode is more susceptible to the "divide and conquer"
attack, although impractical, than a keyed-hashed function using a
keyed-IV instead. They also proved that cryptographic ally HMAC is as
strong as the hash function used with it. One can no make such a
statement with a key-hashed function used in prefix+suffix
mode. As such, IPsec dropped RFC1828 and adopted HMAC-MD5 and HMAC-SHA1
the latter truncated to 90bits. Another potential problem with
MD5/prefix+suffix could come in if the nonsecret component of the key is
variable length. In that case, if you were using MD5(secret, nonsecret)
= newkey, then someone might be able to see newkey and later observe an
exchange where nonsecret' = nonsecret|1. Then the key would be
MD5(newkey, 1) = newkey'. You have to analyze the protocol very
carefully to assure that this doesn't happen, but if you use HMAC, you
don't have to worry about it.
**Recommendation: Advise reader to derive keys using: key =
HMAC-MD5(AAA-key,
{Key Material | node-addres}) or HMAC-SHA1. Do not recommend using
MD5/prefix+suffix.
3) "- AAA-Key is the long term secret shared between the mobile
node and the AAAH."
Problem: The AAA key need to be chosen at random (or using a
cryptographically strong pseudo-random generator seeded with a random
seed), and periodically refreshed. It is not clear that we can
recommended a specific frequency for key changes as the attacks refer to
above may seem practically unfeasible. However, periodic key
refreshment is a fundamental security practice that helps against
potential weaknesses of the function and keys, and limits the damage of
an exposed key.
**Recommendation: Add a statement to ensure that both the Mobile Node
and the AAA server refresh their shared AAA-key. THis could be done via
the AAA protocol or some other out-of-band mechanism. For in-band
refreshing the new key MUST be encrypted, authenticated and its
integrity MUST be protected while on transit.
4) "The Foreign-Home session key is shared between two mobility agents:
the FA and HA. Since this key is not destined for the mobile node,
there is no need to follow the session key generation procedures
detailed above. Instead, the AAAH generates a random [RANDOM] value
of at least 64 bits for use as the Foreign-Home session key."
Problem: This text seems to suggest that the security level required
between the FA and HA is lower hence no need to create/use a
cryptographically generated session key. What is the argument for this?
Suggestion: Please explain. A symmetric protocol is easier to analyze
and understand its security.
Section 5.5.2
1) If the session key needs to be encrypted, the AAAF will check if a
security association can be established, using the CMS security
application [CMS] with the originating host found in the MIP-
Originating-Foreign-AAA AVP.
Problem: Sessions keys MUST always be encrypted. This function seems to
be attached to CMS and this should not be the case.
SUggestion: Always encrypt the session key using permanent keys (AAA-keys)
Section 6.0
1) In other words, AAA
servers MUST be able to create three session keys: the Mobile-Home,
Mobile-Foreign, and Foreign-Home keys.
Problem: Inconsistent with previous statements. The message sent to the
MN does not contain a session key but rather the keying material.
Suggestion: Eliminate this problem by having the AAAH calculate all keys
except in the case where the HA is in the foreign realm in which case
the AAAF will calculate the session key for the HA.
Section 6.8 MIP-Algorithm-Type AVP
1) The MIP-Algorithm-Type AVP (AVP Code 345) is of type Enumerated, and
contains the Algorithm identifier used to generate the associated
Mobile IP authentication extension. The following values are
currently defined:
1 Prefix+Suffix MD5 [MOBILEIP]
2 HMAC-MD5 [HMAC]
3 HMAC-SHA-1 [HMAC]
Problem: as explained before.
Suggestion: deprecate option 1
Issue 352: Issues with Diameter-12
Submitter name: Pete McCann
Submitter email address: mccap@lucent.com
Date first submitted: 26 July 2002
Reference:
Document: base
Comment type: T/E
Priority: 1
Section: 1, 3, and 11
Rationale/Explanation of issue:
1.2.3 Creating New Authentication Applications
...
Every Diameter application specification MUST have an IANA assigned
Application Identifier (see section 2.4) or a vendor specific
Application Identifier.
...
1.2.4 Creating New Accounting Applications
...
Every Diameter accounting application specification MUST have an IANA
assigned Application Identifier (see section 2.4) a vendor specific
Application Identifier.
Last paragraph is missing the word "or".
Should we say instead, "or a vendor specific experimental Application
Identifier."? Or should we delete the last clause, as all Application
Identifiers are now assigned by IANA, regardless of whether
vendor-specific or not?
Also from Section 1.2.4:
This is why "disk writing" accounting servers should advertise
themselves as "Relays" that can handle any Application ID, including
Vendor-Specific.
There is an issue with this text that was raised by Glen Zorn but
never resolved: I think we mean to say "can handle any *Accounting*
Application ID.". A disk-writing accounting server can handle only
ACR and ACA, not just any command. Remember, the standards-track
application IDs that can appear in CER are split into normal App-IDs
and Accounting App-IDs. I think a "disk writing" accounting server
should advertise support for the Relay applicationin an Accounting
App-ID *only*. Also, I don't think such a server can handle any
Vendor-Specific application, because such an application can never
include standards-track commands such as ACR/ACA under the current
rules, as I understand them.
3.3 Diameter Command Naming Conventions
Diameter commands typically includes one or more English words
Should be, "Diameter command names typically include"
3 Diameter Header
...
Command-Code values in the range 0xfffff0 through 0xffffff are
^^^^^ this is only 16 commands. It's conceivable
that even a single application may need
more. Should we use 0xffff00 through
0xffffff instead? If so, also need to
correct the range in Section 11.2.1.
reserved for experimental use. Commands in this range MUST use an
IANA-assigned Application ID from the range 0xff00000000 -
0xfffffffe (see Section 11.3). Commands in this range MUST also
include a Vendor-Specific Application ID AVP (see section 6.11).
Should we clarify here that experimental use = vendor specific? I.e.,
"Command-Code values in the range 0xfffff0 through 0xffffff are
reserved for use by vendor specific, experimental commands."
Also, remove extra space between "ID" and "AVP" in the last line.
11.3 Application Identifiers
As defined in section 2.4, the Application Identifier is used to
identify a specific Diameter Application. There are standards-track
application ids and vendor specific application ids.
IANA [IANA] will assign the range 0x00000001 to 0x00ffffff for
standards-track applications; and 0xff00000000 - 0xfffffffe for
vendor specific applications.
Both Application-Id and Acct-Application-Id AVPs use the same
Application Identifier space.
Vendor-Specific Application Identifiers, encoded in the Vendor-
Specific-Application-Id Grouped AVP, with the Vendor-Id AVP set to
the vendor's enterprise number, is for Private Use.
I don't think this is strictly true anymore. The Vendor-Specific
Application Identifiers are now from the experimental range
0xff00000000 - 0xfffffffe and are in fact managed by IANA. Or perhaps
I've misinterpreted the intention here?
If the experimental command code space is to be managed by IANA, this
IANA Considerations section is inadequate. It needs to give the
assignment policy (Expert Review, First-come-first-served, etc.).
We could leave the space for Private Use (I actually favor this
alternative), but I think that brought up the routing concerns raised
by Bernard - then we would need to parse the AVPs to find out how to
route the command. Also such a policy conflicts with the language in
section 3 under "Command Codes", which I quoted above.
More from Pete:
Hi,
I wanted to make sure everyone is reading the IANA Considerations
section of draft-12.
I think the current text is not quite correct with respect to the new
experimental Application ID space. Because these IDs can appear by
themselves in a Diameter header, they really need to be centrally
administered, rather than for Private Use as stated in Section 11.3.
While I would personally favor First Come First Served for this space,
I don't think we could realistically expect the IESG to go along. How
about Designated Expert Review as the assignment policy?
This would work as follows. First, the existing text from 11.3:
> 11.3 Application Identifiers
>
> As defined in section 2.4, the Application Identifier is
used to
> identify a specific Diameter Application. There are
standards-track
> application ids and vendor specific application ids.
>
> IANA [IANA] will assign the range 0x00000001 to 0x00ffffff
for
> standards-track applications; and 0xff00000000 - 0xfffffffe
for
> vendor specific applications.
>
> Both Application-Id and Acct-Application-Id AVPs use the
same
> Application Identifier space.
>
> Vendor-Specific Application Identifiers, encoded in the
Vendor-
> Specific-Application-Id Grouped AVP, with the Vendor-Id AVP
set to
> the vendor's enterprise number, is for Private Use.
>
> Note that the Diameter protocol is not intended to be
extended for
> any purpose. Any applications defined MUST ensure that they
fit
> within the existing framework, and that no changes to the
base
> protocol are required.
I propose to strike the last two paragraphs above, and add instead:
> Vendor-Specific Application Identifiers, encoded in the Vendor-
> Specific-Application-Id Grouped AVP with the Vendor-Id AVP set to
> the vendor's enterprise number, and appearing in the Diameter
> header, will be assigned by IANA after review by a Designated
> Expert. The Expert will ensure that the requested application fits
> within the existing Diameter framework, does not require changes to
> the base protocol, and does not cause interoperability problems
> with any existing Diameter application before approving the
> assignment.
I hope this sort of wording would satisfy all the interested parties;
it does not allow for completely uncontrolled creation of Diameter
applications, but I think the Designated Expert Review process is the
least onerous to follow. The language should address all of the IESG
concerns regarding interoperability.
-Pete
Issue 353: Issues with EAP-00
Submitter:
Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: September 7, 2002
Reference:
Document: EAP-00
Comment type: T
Priority: 1
Section: several
Rationale/Explanation of issue:
Page 2, last sentence of the Abstract:
Change "PPP Extensible Authentication Protocol" to "Extensible
Authentication Protocol."
Page 2, section 2, last sentence:
Change "with PAP and CHAP in a roaming PPP environment." to
"with PAP, CHAP or EAP-MD5."
Page 3, Section 2.1, second paragraph, first sentence:
The first approach was described as "typical". That would imply that
additional approaches are non-typical, so that the adjective "preferred"
would not apply to them. Also, in the BNF {Section 3.1.1}, the
Destination-Realm AVP is noted as required. Where the "typical" approach
is taken, it would seem difficult to include this. So perhaps you should
describe how this is done.
Change "A preferred approach..." to "An alternate approach..."
Page 3, Section 2.1, Fourth paragraph:
Change:
" A Diameter-EAP-Answer message containing an EAP-Payload of type EAP-
Success or EAP-Failure MUST NOT have the Result-Code AVP set to
DIAMETER_MULTI_ROUND_AUTH."
To:
" A Diameter-EAP-Answer message containing an EAP-Payload of code EAP-
Success (3) or EAP-Failure (4) MUST NOT have the Result-Code AVP set to
DIAMETER_MULTI_ROUND_AUTH."
Page 3, Section 2.1, paragraph 5:
"Diameter-EAP-Answer messages whose Result-Code AVP is set to
DIAMETER_MULTI_ROUND_AUTH MAY include authorization AVPs."
You might give an example of a situation where this would occur.
Section 4.2.1 last sentence:
"If the NAS performs the
Termination-Action by sending a new Diameter-EAP-Request command upon
termination of the current service, it MUST return the State AVP
unmodified in the new Diameter-EAP-Request command."
I've never understood the purpose of the State AVP here, or why it is a
MUST for inclusion. Some additional explanation would be helpful.
Page 9, Section 4.2.5, third paragraph
"If the value of the Termaination-Action AVP is equal to AA-REQUEST
(1) then upon termination of the authorized service the NAS MAY send
a new Diameter-EAP-Request (DER) command."
This is what RFC 2865 says, but it makes more sense for the MAY to be a
SHOULD or MUST. Essentially, this becomes a way to mandate
re-authentication without a server-initiated message. By using the DEFAULT
value, it's possible to terminate the session, so a AA-REQUEST value might
as well cause something different to happen.
Section 4.2.5, page 10, third paragraph:
"When used by 802.1x access devices, the service typically
terminates due to the expiry of the Session-Timeout AVP.
The access device may then reauthenticate the user with a
new DER. The RECOMMENDED way to do this in Diameter is to
use the Authorization-Lifetime AVP rather than the
Termination-Action AVP. However, the Termination-Action AVP
MAY be used when copied from a RADIUS Access-Accept packet
to a Diameter-EAP-Answer command by a Translation Agent."
Actually, the service only terminates if Termination-Action=DEFAULT or no
Termination-Action AVP is included at all. If
Termination-Acton=AA-REQUEST, then re-authentication occurs. See:
http://www.ietf.org/internet-drafts/draft-congdon-radius-8021x-20.txt
Issue 354: Additions to EAP-00
Submitter:
Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: September 7, 2002
Reference:
Document: EAP-00
Comment type: T
Priority: 1
Section: None yet
Rationale/Explanation of issue:
Security considerations
You might consider cadging this from RFC 2869bis-03:
http://www.ietf.org/internet-drafts/draft-aboba-radius-rfc2869bis-03.txt
Usage Guidelines
Please consider the inclusion (with modifications to fit Diameter) of the
following section from RFC 2869bis-03, clarifying various aspects of
AAA/EAP interoperability:
2.5. Usage guidelines
2.5.1. Authentication completion
Within an EAP conversation, a RADIUS Access-Accept will typically
contain an EAP-Message attribute encapsulating an EAP Success packet.
Similarly, a RADIUS Access-Reject will typically contain an EAP-Message
attribute encapsulating an EAP Failure packet. However, this is not
required. For example, the RADIUS Access-Accept/Reject could contain an
EAP-Message attribute encapsulating an EAP-Request with an appropriate
Type code. This could occur, for example, where an EAP method contains
its own (protected) success or failure indications. In this case, it may
be possible to eliminate sending of the final EAP Success or EAP Failure
packet, saving a round-trip.
2.5.2. Conflicting messages
In some cases, the authentication result implied by the encapsulated EAP
packet may not match the result communicated in the RADIUS message. For
example, and EAP Failure packet may be encapsulated within an Access-
Accept message and an EAP Success packet may be encapsulated within an
Access-Reject. Alternatively, no EAP-Message attribute may be included
within a RADIUS Access-Accept or Access-Reject.
Such combinations are likely to cause confusion, because the NAS and
Peer will arrive at different conclusions as to the outcome of the
authentication. For example, if the NAS receives an Access-Reject with
an encapsulated EAP Success, it will not grant access to the Peer.
However, on receiving the Success, the Peer will be lead to believe that
it authenticated successfully.
Similarly, if the NAS receives an Access-Accept with an encapsulated EAP
Failure, it will grant access to the Peer. However, on receiving an EAP
Failure, the Peer will be lead to believe that it failed authentication.
If no EAP-Message attribute is included within an Access-Accept or
Access-Reject, then the Peer may not be informed as to the outcome of
the authentication, while the NAS will take action to allow or deny
access.
As described in [RFC2284bis], the EAP Success and Failure packets are
not acknowledged, and these packets terminate the EAP conversation. As a
result, if these packets are encapsulated within an Access-Challenge, no
response will be received, and therefore no further Access-Requests will
be sent to the RADIUS server. As a result, the NAS will not be given an
indication of whether to allow or deny access while the Peer will be
informed as to the outcome of the authentication.
To avoid these conflicts, the RADIUS server SHOULD check to make sure
that the results implied by an encapsulated EAP-Message attribute and
the RADIUS message are in agreement. The following combinations SHOULD
NOT be sent by a RADIUS server as part of an EAP conversation:
Access-Accept/EAP-Message/EAP Failure
Access-Accept/no EAP-Message attribute
Access-Reject/EAP-Message/EAP Success
Access-Reject/no EAP-Message attribute
Access-Challenge/EAP-Message/EAP Success
Access-Challenge/EAP-Message/EAP Failure
Since the responsibility for avoiding these conflicts lies with the
RADIUS server, the NAS MUST NOT "manufacture" EAP packets in order to
correct contradictory messages that it receives.
2.5.3. Priority
In addition to containing EAP-Message attributes, RADIUS messages may
also contain other attributes. In order to ensure the correct processing
of RADIUS messages, the NAS SHOULD process EAP-Message attributes last.
[This is important for 802.1aa, but it makes more sense for it to end up
in the Diameter EAP document than to put this in 802.1aa.]
2.5.4. Displayable messages
The Reply-Message attribute, defined in section 5.18 of [RFC2865],
indicates text which MAY be displayed to the user. This is similar in
concept to the EAP Notification Type, defined in [RFC2284]. When
sending a displayable message to a NAS during an EAP conversation, the
RADIUS server SHOULD encapsulate displayable messages within EAP-
Message/EAP-Request/Notification attribute(s), and SHOULD NOT use Reply-
Message attribute(s) for this purpose.
[I think that Reply-Message is already prohibited in Diameter, since it
wasn't included in the EAP Application BNF. If so, this is a good thing,
and this section isn't needed.]
A NAS receiving Reply-Message attribute(s) MAY copy the Text field(s)
into the Type-Data field of an EAP-Request/Notification packet, fill in
the Identifier field, and send this to the Peer. However, several issues
may arise from this:
[1] Unexpected Responses. On receiving an EAP-Request/Notification, the
Peer will send an EAP-Response/Notification, and the NAS will pass
this on to the RADIUS server, encapsulated within EAP-Message
attribute(s). However, the RADIUS server may not be expecting an
Access-Request containing an EAP-Message/EAP-Response/Notification
attribute.
For example, consider what happens when a Reply-Message is included
within an Access-Accept or Access-Reject packet with no EAP-Message
attribute present. If the value of the Reply-Message attribute is
copied into the Type-Data of an EAP-Request/Notification and sent
to the peer, this will result in an Access-Request containing an
EAP-Message/EAP-Response/Notification attribute being sent by the
NAS to the RADIUS server. Since an Access-Accept or Access-Reject
packet terminates the RADIUS conversation, such an Access-Request
would not be expected.
[2] Identifier conflicts. While the EAP-Request/Notification contains
an an Identifier, a Reply-Message attribute does not. As a result,
a NAS receiving a Reply-Message attribute and wishing to translate
this to an EAP-Request/Notification will need to choose an
Identifier. It is possible that the chosen Identifier will conflict
with a value chosen by the RADIUS server for another packet within
the EAP conversation. This would violate the requirement in
[RFC2284bis] that Identifier values be unique within an EAP
conversation.
2.5.5. Displayable messages
When used within an EAP conversation, a Reply-Message attribute received
by the NAS MAY be translated to an EAP-Request/Notification sent to the
peer. As a result, a Reply-Message attribute MUST NOT be included in a
RADIUS message containing an EAP-Message attribute. An EAP-Message/EAP-
Request/Notification or Reply-Message attribute SHOULD NOT be included
within an Access-Accept or Access-Reject packet representing the
conclusion of an EAP conversation.
[I think this may be irrelevant for Diameter EAP, because the BNF does not
include the Reply-Message AVP.]
Issue 355: Keying AVP definition should be in EAP
not NASREQ
Submitter: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: September 7, 2002
Reference:
Document: EAP-00, NASREQ
Comment type: T
Priority: 1
Section:
Rationale/Explanation of issue:
NAS-Session-Key AVP
I think this needs to be defined in the EAP document, not in NASREQ. Since
there is controversy about this AVP, including it in NASREQ would prevent
that document from advancing.
Issue 356: Security issues with TLS up-negotiation
Submitter: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: September 9, 2002
Reference:
Document: BASE-12
Comment type: T
Priority: S
Section: 5.6
Rationale/Explanation of issue:
"For TLS usage, a TLS handshake will begin when both ends
are in the open state. If the TLS handshake is successful,
all further messages will be sent via TLS. If the handshake
fails, both ends move to the closed state."
Unfortunately, this model of TLS up-negotiation depends on
the Diameter connection being brought up without any security,
followed by an exchange of CER/CEA (including the security
model) in the clear.
The Inband-Security-ID AVP includes a value of NO_INBAND_SECURITY,
and nothing in the specification requires that a value of TLS
MUST be exchanged by the peers if the connection is not protected
by IPsec.
So it would appear legal for the Diameter connection to reach the
open state after negotiation of NO_INBAND_SECURITY.
To fix this, add the following text to section 13, first paragraph:
"Diameter clients, such as Network Access Servers (NASes) and Mobility
Agents MUST support IP Security [SECARCH] and MAY support TLS [TLS].
Diameter servers MUST support TLS and IPsec. Diameter implementations
MUST use transmission-level security of some kind (IPsec or TLS) on
each connection.
If a Diameter connection is not protected by IPsec,
then the CER/CEA exchange MUST include an Inband-Security-ID AVP
with a vaue of TLS. For TLS usage, a TLS handshake will begin when both ends
are in the open state, after completion of the CER/CEA exchange.
If the TLS handshake is successful, all further messages will
be sent via TLS. If the handshake fails, both ends move to the
closed state.
It is suggested that IPsec be used primarily at the edges for
intra-domain exchanges. For NAS devices without certificate support,
pre-shared keys can be used between the NAS and a local AAA proxy.
For protection of inter-domain exchanges, TLS is recommended. See
sections 13.1 and 13.2 for more details on IPsec and TLS usage."
Issue 357: Inappropriate UTF-8 encoding
Submitter: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: September 9, 2002
Reference:
Document: BASE-12
Comment type: T
Priority: S
Section: 4.3
Rationale/Explanation of issue:
The DiameterIdentity type is defined to use the UTF-8 charset
and is indicated to carry a Fully Qualified Domain Name (FQDN).
Unfortunately, FQDNs are to be encoded as specified by the
Internationalized Domain Name (IDN) specification, not UTF-8.
For example, see:
http://www.ietf.org/internet-drafts/draft-ietf-idn-idna-11.txt
To fix this, the DiameterIdentity type should be defined to be of type
OctetString AVP, not UTF-8, and references
to UTF-8 in FQDNs should instead refer to the DiameterIdentity
type.
Note that there are other questionable uses of UTF-8 within
the specification. For example, why does IPFilterRule or
QoSFilterRule use UTF-8 instead of ASCII?
Indicated changes:
1. Change the following AVPs that use UTF8String to type DiameterIdentity:
Origin-Realm AVP (6.4)
Destination-Realm AVP (6.6)
2. Change the definition of DiameterIdentity to OctetString.
3. Change the type of IPFilterRule and QoSFilterRule to ASCII
instead of UTF-8.
---------- Forwarded message ----------
Date: Tue, 10 Sep 2002 10:44:32 -0400
From: Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net>
To: Bernard Aboba <aboba@internaut.com>
Cc: brunner@nic-naa.net
Subject: Re: [AAA-WG]: Issue 357: Inappropriate UTF-8 encoding
Bernard,
As an alternative, I suggest the DiameterIdentity type can be left
simply as an OctetString AVP, and reference to any charset dropped.
If you want to add details to how the DiameterIdentity value is to
be used, e.g., case-insensitive character comparison for octets in
the range 0-127, that would be consistent with 10[34/35].
The same issue came up recently in dnsext (unknown RDATA formats).
The same issue has been present in provreg (character encodings other
than UTF-8 (and UTF-16) are allowed by XML, if an encoding attribute,
or a byte order mark, or both is present, EPP is specified in XML
Schema notation, and is silent on the use of character encodings other
than UTF-8 except "in environments where parser encoding support
incompatibility might have an impact on interoperability", in which
case UTF-8 is RECOMMENDED).
Eric
Issue 358: Issues with references
Submitter: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: September 9, 2002
Reference:
Document: BASE-12
Comment type: E
Priority: 1
Section: 14.2 and others
Rationale/Explanation of issue:
Add the following non-normative references to section 14.2:
[AAAREQ] Aboba, B. et al., "Criteria for Evaluating AAA Protocols
for Network Access", RFC 2989, November 2000.
[DYNAUTH] Chiba, M., et al., "Dynamic Authorization Extensions to
RADIUS", IETF work in progress.
[RADACCT] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RADEXT] Rigney, C., Willats W., Calhoun P., "RADIUS Extensions", RFC
2869, June 2000.
[TACACS] Finseth, C., "An Access Control Protocol, Sometimes Called
TACACS", RFC 1492, July 1993.
In Sections 11.12, 11.13, 11.14 (page 129) change the reference from [TCP]
to [IANA].
In section 14.2, change reference to [IPCOMP] from non-normative to
normative. This is referred to with a MAY in Section 9.2 (page 114).
Issue 359: Terminology and organizational issues
Submitter: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: September 9, 2002
Reference:
Document: BASE-12
Comment type: E
Priority: S
Section: 1.4, 8.2
Rationale/Explanation of issue:
Several terms are not defined in the terminology section, including:
Transaction state
Session state
Quite a few terms are used prior to their definition in Section 1.4, so
that I would recommend that the terminology section (currently 1.4) be
moved up earlier in the document.
I'd also note that I found it very confusing that section 8.2 (Accounting
State machine) occurs prior to Section 9 (Accounting). I'd recommend that
8.2 be moved to Section 9.9 (after definition of the AVPs, including
Accounting-Realtime-Required AVP).
Issue 360: Accounting standalone
Submitter: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: September 9, 2002
Reference:
Document: BASE-12
Comment type: T
Priority: S
Section: 1, 2, 7.1.3
Rationale/Explanation of issue:
The specification is contradictory on whether the Accounting
functionality of the Diameter base protocol can be used without
a corresponding application (MIP, NASREQ, etc.) For example,
the SIP accounting extension does not include an authentication
application definition, yet makes use of the Base protocol:
(see http://www.ietf.org/internet-drafts/draft-narayanan-sipping-aaa-diameter-00.txt
Thus, the above specification seems to provide an example of how the Diameter
Accounting can be used by itself, and I would argue that this is to be
encouraged
instead of creating Yet Another Accounting Protocol (YAAP). The proposed fix is
to adjust the text in the following places to make this clear:
Page 14: Change definition of Diameter Server to the following:
"A Diameter Server is one that handles authentication, authorization and
accounting
requests for a particular realm."
Section 2, page 17, first paragraph.
Change the first sentence of the first paragraph to:
"The base Diameter protocol may be used by itself for accounting applications,
but for
use in authentication and authorization it is always extended for a particular
application."
Section 7.1.3, Page 81, DIAMETER_UNABLE_TO_DELIVER
Change "no host within the realm was available" to
"no host within the realm supporting the required application was available"
Page 94, last paragraph
Delete the paragraph starting with "Note that the server side state machine..."
This paragraph appears to be redundant with the first paragraph of page 93.
Issue 361: Support for TLS compression
Submitter: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: September 9, 2002
Reference:
Document: BASE-12
Comment type: T
Priority: 2
Section: 9.2
Rationale/Explanation of issue:
TLS compression is more efficient than IP compression, since TCP
is stateful. As a result, it makes sense to use TLS compression
where TLS is negotiated and it is desired to reduce the network
bandwidth used for Diameter accounting.
Replace the last paragraph of Section 9.2 with the following:
"Each Diameter Accounting protocol message MAY be compressed, in order
to reduce network bandwidth usage. If IPsec and IKE are used to
secure the Diameter session, then IP compression [IPComp] MAY be used and
IKE [IKE] MAY be used to negotiate the compression parameters. If TLS
is used to secure the Diameter session, then TLS compression [TLS] MAY
be used."
Issue 362: Clarification of
Proxy, Relay, and Redirect Usage
Submitter: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: September 9, 2002
Reference:
Document: BASE-12
Comment type: E
Priority: S
Section: many
Rationale/Explanation of issue:
Throughout the document, the term "proxy" is used when it actually applies
equally well to proxies, relays and redirects. At times the term "stateful" is unclear;
sometimes this refers to session state, sometimes to transaction state.
Below find attempts to clarify the usage of these terms.
Section 2.8.1, page 24, last paragraph, change to:
"Relays modify Diameter messages by inserting and removing routing
information, but do not modify any other portion of the message.
Relays SHOULD NOT maintain session state but MUST maintain
transaction state."
Section 2.8.2, page 25, third paragraph, change to:
"Proxies that wish to limit resources MUST maintain session state.
All proxies MUST maintain transaction state."
Section 2.8.3, page 27, first paragraph, change to:
"Since Redirect agents do not perform any application level
processing, they provide services for all Diameter applications,
and therefore MUST advertise the Relay Application Identifier."
Page 28, first second and third paragraphs, change to:
"End-to-end security services include confidentiality
and message origin authentication. These services are provided
by supporting AVP integrity and confidentiality between two
peers, communicating through agents.
End-to-end security is provided via the End-to-End security
extension, described in [AAACMS]. The circumstances requiring
the use of end-to-end security are determined by policy on
each of the peers. Security policies, which are not the
subject of standardization, may be applied by next hop
Diameter peer or by destination realm. For example, where
TLS or IPsec transmission-level security is sufficient,
there may be no need for end-to-end security.
End-to-end security policies include:"
Page 30, last paragraph. Change
"The End-to-End Identifier MUST NOT be modified by relay agents"
to:
"The End-to-End Identifier MUST NOT be modified by Diameter agents
(proxies, relays, redirects)."
Page 49, second to last paragraph:
Change
"be sent via proxy/agent"
to "be sent via a Diameter agent (proxy, redirect or relay)"
Page 68, third paragraph
Change
"Proxiable request message MUST also contain an
Acct-Application-Id AVP, an Auth-Application-Id AVP or a
Vendor-Specific-Application-Id AVP. A message that MUST NOT
be relayed, proxied or redirect MUST not include..."
To:
"Request messages that may be forwarded by Diameter agents
(proxies, redirects or relays) MUST also contain an
Acct-Application-Id AVP, an Auth-Application-Id AVP or a
Vendor-Specific-Application-Id AVP. A message that MUST NOT
be forwarded by Diameter agents (proxies, redirects or
relays) MUST NOT include..."
Page 70, Section 6.1.6
Change
"A Diameter message that is able to be proxied MUST
include..."
to:
"A Diameter message that is forwardable by Diameter
agents (proxies, redirects or relays) MUST include..."
Issue 363: IANA Considerations Issues
Submitter: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: September 9, 2002
Reference:
Document: BASE-12
Comment type: T
Priority: S
Section: 11
Rationale/Explanation of issue:
The IANA considerations section lacks some boilerplate. Also, as I recall, the
agreement
with the IESG was that standard AVP codes would be allocated via "Expert Review
with
Specification Required", and I would also recommend this for non-vendor specific
application IDs.
Change Section 11 to the following:
"This section provides guidance to the Internet Assigned Numbers Authority (IANA)
regarding
registration of values related to the Diameter protocol, in accordance with BCP
26 [IANA].
The following policies are used here with the meanings defined in BCP 26:
"Private Use",
"First Come First Served", "Expert Review", "Specification Required", IETF
Consensus",
"Standards Action".
This section explains the criteria to be used by the IANA for assignment of
numbers within
namespaces defined within this document.
Diameter is not intended as a general purpose protocol, and allocations SHOULD
NOT be made
for purposes unrelated to authentication, authorization or accounting. For
registration
requests where a Designated Expert should be consulted, the responsible IESG
area director
should appoint the Designated Expert.
For registration requests requiring Expert Review, the AAA mailing list should
be consulted."
Section 11.1.1 AVP Code
Change the last sentence of the first paragraph to:
"AVP Codes 0-254 are managed separately as RADIUS Attribute Types [RADTYPE],
while the
remaining namespace is available for assignment via Expert Review with
Specification
Required [IANA]."
Section 11.2.1, second to last paragraph, last sentence.
Change to: "The range of values will have a limited lifetime, and will
eventually be
reallocated within a range available for standardization."
Change "guarentee" to "guarantee"
Section 11.3 Application Identifiers
Second paragraph, add the following sentence:
"Assignment of standards-track application IDs are by Expert Review with
Specification
Required [IANA]."
Issue 364: Revised Introduction & Abstract
Submitter: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: September 9, 2002
Reference:
Document: BASE-12
Comment type: E
Priority: 1
Section: Abstract, 1
Rationale/Explanation of issue:
The Introduction does not include an in-depth explanation of the
issues with RADIUS, and the advantages of Diameter. The proposed
rewrite makes the case for Diameter in a more detailed way.
Page 1, Draft header, 11th line:
Delete extra "Nokia" on left hand side.
Abstract, page 2.
Rewrite to read:
"The Diameter base protocol is intended to provide an AAA framework
for applications such as network access or IP mobility. Diameter is
also intended to work in both local AAA and roaming
situations. This draft specifies the message format, transport, error
reporting, accounting and security services to be used by all
Diameter applications. The Diameter base application MUST be supported by all
Diameter implementations."
Rewrite the following portions of Section 1 to read as follows:
"1 Introduction
Authentication, Authorization and Accounting (AAA) protocols such as
TACACS [TACACS] and RADIUS [RADIUS] were initially deployed to provide
dial-up PPP [PPP] and terminal server access. Over time, with the
growth of the Internet and the introduction of new access technologies,
including wireless, DSL, Mobile IP and Ethernet, routers and network
access servers (NAS) have increased in complexity
and density, putting new demands on AAA protocols.
Network access requirements for AAA protocols are summarized in [AAAREQ].
These include:
Failover. [RADIUS] does not define failover mechanisms, and as a result,
failover behavior differs between implementations. In order to provide
well defined failover behavior, Diameter supports application-layer
acknowledgements, and defines failover algorithms and the associated
state machine. This is described in Section 5.5 and [AAATRANS].
Transmission-level security. [RADIUS] defines an application-layer
authentication and integrity scheme that is required only for use
with Response packets. While [RADEXT] defines an additional
authentication and integrity mechanism, use is only required
during Extensible Authentication Protocol (EAP) sessions.
While attribute-hiding is supported, [RADIUS] does not provide
support for per-packet confidentiality. In accounting, [RADACCT]
assumes that replay protection is provided by the backend billing
server, rather than within the protocol itself.
While [RFC3162] defines the use of IPsec with RADIUS, support for
IPsec is not required. Since within [IKE] authentication occurs
only within Phase 1 prior to the establishment of IPsec SAs in
Phase 2, it is typically not possible to define separate trust
or authorization schemes for each application. This limits the
usefulness of IPsec in inter-domain AAA applications (such as roaming)
where it may be desirable to define a distinct certificate hierarchy
for use in a AAA deployment. In order to provide universal support
for transmission-level security, and enable both intra- and
inter-domain AAA deployments, IPsec support is mandatory in
Diameter, and TLS support is optional. Security is discussed
in Section 13.
Reliable transport. RADIUS runs over UDP, and does not define
retransmission behavior; as a result, reliability varies between
implementations. As described in [ACCMGMT], this is a major issue
in accounting, where packet loss may translate directly into revenue
loss. In order to provide well defined transport behavior, Diameter
runs over reliable transport mechanisms (TCP, SCTP) as defined in [AAATRANS].
Agent support. [RADIUS] does not provide for explicit support for agents,
including Proxies, Redirects and Relays. Since the expected behavior is
not defined, it varies between implementations. Diameter defines agent
behavior explicitly; this is described in Section 2.8.
Server-initiated messages. While RADIUS server-initiated messages are
defined in [DYNAUTH], support is optional. This makes it difficult to
implement features such as unsolicited disconnect or
reauthentication/reauthorization on demand across a heterogeneous
deployment. Support for server-initiated messages is mandatory in
Diameter, and is described in Section 8.
Auditability. RADIUS does not define data-object security mechanisms, and
as a result, untrusted proxies may modify attributes or even packet headers
without being detected. Combined with lack of support for capabilities
negotiation, this makes it very difficult to determine what occurred in
the event of a dispute. While implementation of data object security is
not mandatory within Diameter, these capabilities are supported, and are
described in [AAACMS].
Transition support. While Diameter does not share a common protocol data
unit (PDU) with RADIUS, considerable effort has been expended in enabling
backward compatibility with RADIUS, so that the two protocols may be
deployed in the same network. Initially, it is expected that Diameter
will be deployed within new network devices, as well as within gateways
enabling communication between legacy RADIUS devices and Diameter servers.
This capability, described in [NASREQ], enables Diameter support to be
added to legacy networks, by addition of a gateway or server speaking
both RADIUS and Diameter.
In addition to addressing the above requirements, Diameter also provides
support for the following:
Capability negotiation. RADIUS does not support error messages, capability
negotiation, or a mandatory/non-mandatory flag for attributes. Since RADIUS
clients and servers are not aware of each other’s capabilities, they may
not be able to successfully negotiate a mutually acceptable service,
or in some cases, even be aware of what service has been implemented.
Diameter includes support for error handling (section 7), capability
negotiation (section 5.3), and mandatory/non-mandatory attribute-value
pairs (AVPs) (Section 4.1).
Peer discovery and configuration. RADIUS implementations typically require
that the name or address of servers or clients be manually configured,
along with the corresponding shared secrets. This results in a large
administrative burden, and creates the temptation to reuse the RADIUS
shared secret, which can result in major security vulnerabilities if the
Request Authenticator is not globally and temporally unique as required
in [RADIUS]. Through DNS, Diameter enables dynamic discovery of peers.
Derivation of dynamic session keys is enabled via transmission-level
security.
Roaming support. The ROAMOPS WG provided a survey of roaming implementations
[ROAMREV], detailed roaming requirements [ROAMCRIT], defined the Network
Access Identifier (NAI) [NAI], and documented existing implementations
(and limitations) of RADIUS-based roaming [PROXYCHAIN]. In order to improve
scalability, [PROXYCHAIN] introduced the concept of proxy chaining via an
intermediate server, facilitating roaming between providers. However, since
RADIUS does not provide explicit support for proxies, and lacks auditability
and transmission-level security features, RADIUS-based roaming is vulnerable
to attack from external parties as well as susceptible to fraud perpetrated
by the roaming partners themselves. As a result, it is not suitable for
wide-scale deployment on the Internet [PROXYCHAIN]. By providing explicit
support for inter-domain roaming and message routing (Sections 2.7 and 6),
auditability [AAACMS], and transmission-layer security (Section 13)
features, Diameter addresses these limitations and provides for secure
and scalable roaming.
In the decade since AAA protocols were first introduced, the capabilities
of Network Access Server (NAS) devices have increased substantially.
As a result, while Diameter is a considerably more sophisticated protocol
than RADIUS, it remains feasible to implement within embedded devices,
given improvements in processor speeds and the widespread availability
of embedded IPsec and TLS implementations.
1.1 Diameter Base Protocol
The Diameter base protocol provides the following facilities:
- Delivery of AVPs (attribute value pairs)
- Capabilities negotiation
- Error notification
- Extensibility, through addition of new commands and AVPs (required in [AAAREQ]).
- Basic services necessary for applications, such as handling of
user sessions or accounting
All data delivered by the protocol is in the form of an AVP. Some of
these AVP values are used by the Diameter protocol itself, while
others deliver data associated with particular applications that
employ Diameter. AVPs may be added arbitrarily to Diameter messages,
so long as the required AVPs are included and AVPs that are
explicitly excluded are not included. AVPs are used by the base
Diameter protocol to support the following required features:
- Transporting of user authentication information, for the
purposes of enabling the Diameter server to authenticate the
user.
- Transporting of service specific authorization information,
between client and servers, allowing the peers to decide whether
a user's access request should be granted.
- Exchanging resource usage information, which MAY be used for
accounting purposes, capacity planning, etc.
- Relaying, proxying and redirecting of Diameter messages through
a server hierarchy.
The Diameter base protocol provides the minimum requirements needed
for a AAA protocol, as required by [AAAREQ]. The base protocol may be
used by itself for accounting purposes only, or it may be used with a
Diameter application, such as Mobile IP [DIAMMIP], or network access
[NASREQ]. It is also possible for the base protocol to be extended for
use in new applications, via the addition of new commands or AVPs.
At this time the focus of Diameter is network access and accounting
applications. A truly generic AAA protocol used by many applications
might provide functionality not provided by Diameter. Therefore, it
is imperative that the designers of new applications understand their
requirements before using Diameter. See section 2.4 for more information on
Diameter applications.
Any node can initiate a request. In that sense, Diameter is a peer-
to-peer protocol. In this document, a Diameter Client is a device at
the edge of the network that performs access control, such as
a Network Access Server (NAS) or a Foreign Agent (FA). A Diameter
client generates Diameter messages to request authentication,
authorization, and accounting services for the user. A Diameter agent
is a node that does not authenticate and/or authorize messages
locally; agents include proxies, redirects and relay agents. A Diameter
server performs authentication and/or authorization of
the user. A Diameter node MAY act as an agent
for certain requests while acting as a server for others.
The Diameter protocol also supports server-initiated messages,
such as a request to abort service to a particular
user.
1.1.2 Description of the Document Set
Currently, the Diameter specification consists of a base
specification (this document), Transport Profile [AAATRANS]
and applications: Mobile IPv4 [DIAMMIP], and NASREQ [NASREQ].
The Transport Profile document [AAATRANS] discusses transport layer
issues that arise with AAA protocols and recommendations on how to
overcome these issues. This document also defines the Diameter
failover algorithm and state machine.
The Mobile IPv4 [DIAMMIP] application defines a Diameter application
that allows a Diameter server to perform AAA functions for Mobile
IPv4 services to a mobile node.
The NASREQ [NASREQ] application defines a Diameter Application that
allows a Diameter server to be used in a PPP/SLIP Dial-Up and
Terminal Server Access environment. Consideration was given for
servers that need to perform protocol conversion between Diameter and
RADIUS.
In summary, this document defines the base protocol specification for
AAA, which includes support for accounting. The MIPv4 and the NASREQ
documents describe applications that
use this base specification for Authentication, Authorization
and Accounting.
Issue 365: Revised Extensibility Section
Submitter: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: September 9, 2002
Reference:
Document: BASE-12
Comment type: T
Priority: S
Section: 1.2
Rationale/Explanation of issue:
This revision is designed to clarify the issue of
extensibility to make it clear that addition of
non-mandatory AVPs does not require definition of a
new application ID.
Replace section 1.2 with the following:
"1.2 Approach to Extensibility
The Diameter protocol is designed to be extensible, using
several mechanisms, including:
- Defining new AVP values.
- Creating new AVPs
- Creating new authentication/authorization applications
- Creating new accounting applications
- Application authentication procedures
Reuse of existing AVP values, AVPs, applications and command codes
are strongly recommended. Reuse simplifies standardization and
implementation and avoids potential interoperability issues.
1.2.1 Defining New AVP Values
New applications should attempt to reuse AVPs defined in existing
applications when possible, as opposed to creating new AVPs. For AVPs
of type Enumerated an application may require a new
value to communicate some service-specific information.
In order to allocate a new AVP value, a request MUST be
sent to IANA [IANA], along with an explanation of the new
AVP value. IANA considerations for Diameter are discussed
in Section 11.
1.2.2 Creating New AVPs
When no existing AVP can be used, a new AVP should
be created. The new AVP being defined MUST use one of the
data types listed in section 4.3.
In the event that a logical grouping of AVPs is necessary, and
multiple "groups" are possible in a given command, it is
recommended that a Grouped AVP be used (see Section 4.5).
In order to create a new AVP, a request MUST be sent to IANA,
with a specification for the AVP. The request MUST include
the commands that would make use of the AVP.
1.2.3 Creating New Authentication Applications
Every Diameter application specification MUST have an IANA assigned
Application Identifier (see section 2.4) or a vendor specific
Application Identifier.
Should a new Diameter usage scenario find itself unable to 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:
- Adding new mandatory AVPs to the command. A mandatory AVP is
defined as one which has the "M" bit set when sent within a command,
regardless of whether it is required or optional within the ABNF.
- 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).
- Adding support for an authentication method requiring definition of
new AVPs for use with the application. Since a new EAP authentication
method can be supported within Diameter without requiring new AVPs,
addition of EAP methods does not require the creation of a new authentication
application.
Creation of a new application should be viewed as a last resort.
An implementation MAY add arbitrary non-mandatory AVPs to any
command defined in an application, including vendor-specific AVPs without
needing to define a new application. Please refer to section 11.1.1 for details.
In order to justify allocation of a new application identifier, Diameter
applications
MUST define one Command Code, or add new AVPs to the ABNF which have the
"M" bit set.
The expected AVPs MUST be defined in an ABNF [ABNF] grammar (see section 3.2).
If the Diameter application has accounting requirements, it
MUST also specify the AVPs that are to be present in the Diameter
Accounting messages (see section 9.3). However, just because a new
authentication
application id is required, does not imply that a new accounting application id
is
required.
When possible, a new Diameter application SHOULD reuse
existing Diameter AVPs, in order to avoid defining
multiple AVPs that carry similar information.
1.2.4 Creating New Accounting Applications
There are services that only require Diameter accounting.
Such services need to define the AVPs carried in the ACR/ACA messages,
but do not need to define new command codes. An implementation MAY add
arbitrary non-mandatory AVPs (AVPs with the "M" bit not set) to any
command defined in an application, including vendor-specific
AVPs, without needing to define a new accounting application. Please
refer to section 11.1.1 for details.
Application Identifiers are still required for Diameter capability
exchange. Every Diameter accounting application specification MUST
have an IANA assigned Application Identifier (see section 2.4)
or a vendor specific Application Identifier.
Since every Diameter implementation MUST support accounting, there
is no need to advertise support for the Base accounting application
within the CER/CEA, since this is implicit. This basic accounting
support is sufficient to handle any application that uses the
ACR/ACA commands defined in this document, as long as no new
mandatory AVPs are added. A mandatory AVP is defined as one
which has the "M" bit set when sent within an accounting command,
regardless of whether it is required or optional within the ABNF for
the accounting application.
The creation of a new accounting application should be viewed as a
last resort and MUST NOT be used unless a new command or additional
mechanisms (e.g. application defined state machine) is defined within
the application, or new mandatory AVPs are added to the ABNF.
Within an accounting command, setting the "M" bit implies that
a backend server (e.g. billing server) or the accounting server itself MUST
understand the AVP in order to compute a correct bill. If the AVP is not
relevant to the billing process, when the AVP is included within an
accounting command, it MUST NOT have the "M" bit set, even if the "M" bit is
set when the same AVP is used within other Diameter commands (i.e.
authentication/authorization commands).
A DIAMETER base accounting implementation MUST be configurable to advertise
supported accounting applications in order to prevent the accounting
server from accepting accounting requests for unbillable services. The
combination of the home domain and the accounting application Id can
be used in order to route the request to the appropriate accounting server.
When possible, a new Diameter accounting application SHOULD attempt
to reuse existing AVPs, in order to avoid defining multiple AVPs
that carry similar information.
If the base accounting is used without any mandatory AVPs, new commands or
additional mechanisms (e.g. application defined state machine), then the
base protocol defined standard accounting application Id (section 2.4) MUST
be used in ACR/ACA commands."
Issue 366: Vendor-specific Result AVP
Submitter: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: September 9, 2002
Reference:
Document: BASE-12
Comment type: T
Priority: S
Section: 7.6
Rationale/Explanation of issue:
It would appear that this AVP was created for use with
Vendor-specific Commands, which are no longer supported
in the protocol. Should this be renamed to
"Experimental Result AVP" with the appropriate changes in text?
Issue 367: Editorial issues with MIP-12
Submitter: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: September 13, 2002
Reference:
Document: MIP-12
Comment type: E
Priority: S
Section: many
Rationale/Explanation of issue:
Overall comments:
This draft needs a terminology section. Feel free to steal this from the
Diameter Base document. The terminology section should include a definition
of the terms "session state" and "transaction state".
The terms Mobile Node, Home Agent and Foreign Agent are inconsistently capitalized.
The term "key" appears to be used incorrectly in places within the draft.
It would appear that the "key" distributed by the AAAH to the Mobile Node
is in fact a nonce, which is combined with the long term pre-shared key
to generate the session key. Below I have added text to differentiate between
nonces and session keys. Similarly, use of the term "security association"
is not always clear, since we have end-to-end SAs, hop-by-hop SAs, and Mobile IP
SAs. Specific instances where this occurs are pointed out below.
Detailed comments below
Section 1.0, page 4, second paragraph:
"This document specifies an Application of 4 to the Diameter base
protocol [DIAMBASE] that allows a Diameter server to authenticate,"
Change to:
"This document specifies a Diameter application that allows a Diameter
server to authenticate,"
Section 1.0, page 5, first paragraph:
"Strong authentication and confidentiality of session keys is
required, and it is recommended to be provided using the CMS security
application [CMS], but may be provided via other security mechanisms,
e.g. using mutually authenticated TLS or IPsec, when deployed in an
environment without Diameter agents, then hop-by-hop security is
sufficient for protecting session keys. (It should be noted that the
CMS security application is referenced as informative in this
application and the usage is only a recommendation.) However, if a
home AAA server is explicitly configured to need the CMS security
application for this domain/transaction then it will not proceed
without it, that is, the requested service MUST fail if CMS isn't
available."
The "keying material" is actually a Nonce. Since [CMS] is a work
in progress, I'd reword this paragraph as
follows in order to emphasize what can be done without it:
" In order to provide authentication, integrity protection and confidentiality
of session keys and nonces, transmission-level security (IPsec or TLS) is sufficient
when deployed in an environment without Diameter agents. Where Diameter
agents are present, then it is recommended that end-to-end security be
employed, such as via the CMS security application under development [CMS].
If a home AAA server is explicitly required to require end-to-end security
for a particular domain/transaction, then the requested service MUST fail
if end-to-end security is not available (e.g. [CMS] is not supported).
Since end-to-end security is not required in all scenarios, references
to this functionality, or to the [CMS] work in progress are informative."
Section 1.0, page 5, second paragraph:
" As with the Diameter base protocol, AAA servers implementing the
Mobile IP application can process users' identities supplied in a
Network Access Identifier (NAI) format [NAI], which is used for
Diameter message routing purposes. Mobile nodes include their NAI in
Registration messages, as defined in [MIPNAI]."
The first sentence is a bit awkward. Suggest change to:
" AAA servers implementing the Mobile IP application utilize
user identities supplied in the format of a Network Access
Identifier (NAI), described in [NAI]. Mobile nodes include their NAI in
Registration messages, as defined in [MIPNAI], and the NAI
realm is used for routing of Diameter messages."
Section 1.0, page 5, last paragraph:
"The Diameter Mobile-IP Application meets the requirements specified
in [MIPREQ, CDMA2000]. "
It also satisfies the AAA requirements as well, so I'd add the following reference too:
"The Diameter Mobile-IP Application meets the requirements specified
in [MIPREQ, CDMA2000, RFC2989]. "
Section 1.2
The first paragraph launches into an example without introducing the
elements first. Before going into what happens when the mobile node
issues the Registration Request, I'd start off by describing the
components of Figure 1, their relationship, and the assumptions.
For example:
"Figure 1 describes the architecture for Inter-Realm Mobility.
This is comprised of several elements:
- The Mobile Node. The function of the Mobile Node is described
in [Reference]. While it is assumed that the Mobile Node does
not implement Diameter [DIAMBASE], it is assumed that it implements the
following Mobile IP extensions <reference these here>.
- The Foreign Agent. The function of the Foreign Agent is described
in [Reference]. In this model it is assumed that the Mobile Node
does not implement a co-located Foreign Agent, and therefore that
the Mobile Node and Foreign Agent are separate entities.
- The AAA Foreign server (AAAF). The purpose of the AAAF is...
- The AAA Home Server (AAAH). The purpose of the AAAH is...
- The Home Agent. The function of the Home Agent is described in
[Reference]. <A brief description of the Home Agent interaction with
the HAAA goes here>.
In this model, the Mobile Node communicates to the Foreign Agent
using Mobile IPv4 [reference]. It is assumed that the
AAA Foreign (AAAF), AAA Home (AAAH), and Home Agent all
implement the Diameter Base protocol [DIAMBASE] as well as the
Diameter Mobile IPv4 Application.
In Figure 1, the elements may be located within different administrative
domains. For example, the AAAF may be located in a different administrative
domain than the AAAH when the Mobile Node is roaming between providers.
In addition, it is possible for the AAAH and Home Agent to be located
in different administrative domains, such a when <give example here>.
However, it is assumed that the Foreign Agent and AAAF are located within
the same administrative domain [true?]. "
Section 1.4, first paragraph:
"The Diameter Mobile IP application allows a home agent to be
allocated in a foreign network, as required in [MIPREQ, CDMA2000]."
Change to:
The Diameter Mobile IP application allows a home agent to be
allocated in a foreign network, as required in [MIPREQ, CDMA2000, RFC2989]."
Section 1.4, Page 12, last two paragraphs:
""If the AAAH's local policy determines that the generated session keys
must be encrypted to protect against untrusted intermediate Diameter
agent(s) between the visited and the home realm, the AAAH will make
use of the CMS application [CMS] to establish a security association.
If no security association can be established the AAAH MUST return an
AMA with the Result-Code AVP set to
DIAMETER_ERROR_END_TO_END_MIP_KEY_ENCRYPTION. Otherwise, upon
completion of the security association, the AAAH sends the HAR to the
originating AAAF. In this HAR the Destination-Host AVP is set to the
value found in the AMR's MIP-Originating-Foreign-AAA AVP, and the
MIP-Home-Agent-Host AVP or the MIP-Candidate-Home-Agent-Host AVP
found in the AMR are copied into the HAR.
If the AAAH's local policy determines that session keys can be
encrypted using mechanisms defined in [DIAMBASE] as in Figure 5, the
HAR is sent by the AAAH back to the foreign realm with the
Destination-Host AVP set to the home agent's identity. This HAR may
not necessarily be received by the same AAAF, which sent the AMR.
Therefore the AAAH MUST always copy the MIP-Originating-Foreign-AAA
AVP from the AMR message to the HAR message. In cases when another
AAAF receives the HAR, this new AAAF will use the MIP-Originating-
Foreign-AAA AVP for policy decisions, such as determining if the FA-
HA Key should be encrypted or not."
To avoid appearing to depend on CMS, I'd recommend rephrasing this to:
"Diameter supports two mechanisms for protecting session keys and nonces
in transit. [DIAMBASE] supports transmission-level security using TLS
or IPsec. This mechanism provides hop-by-hop confidentiality,
authentication and integrity protection, but is not appropriate
for protection of session keys and nonces transmitted through untrusted
intermediate Diameter agents, since they will
be available to those agents in cleartext.
If the AAAH's local policy requires session keys and nonces to be encrypted
to prevent disclosure to untrusted intermediate Diameter
agent(s) between the foreign and the home realm, the AAAH will make
use of end-to-end security to establish a security association.
This can be accomplished via mechanisms such as the CMS
application [CMS], that is a work in progress.
If no end-to-end security association can be established the
AAAH MUST return an AMA with the Result-Code AVP set to
DIAMETER_ERROR_END_TO_END_MIP_KEY_ENCRYPTION. Otherwise, upon
completion of the security association, the AAAH sends the HAR to the
originating AAAF. In this HAR the Destination-Host AVP is set to the
value found in the AMR's MIP-Originating-Foreign-AAA AVP, and the
MIP-Home-Agent-Host AVP or the MIP-Candidate-Home-Agent-Host AVP
found in the AMR are copied into the HAR.
If the AAAH's local policy determines that session keys and nonces can be
encrypted using the transmission-level security mechanisms defined
in [DIAMBASE] (see Figure 5), the
HAR is sent by the AAAH back to the foreign realm with the
Destination-Host AVP set to the home agent's identity. This HAR may
not necessarily be received by the same AAAF, which sent the AMR.
Therefore the AAAH MUST always copy the MIP-Originating-Foreign-AAA
AVP from the AMR message to the HAR message. In cases when another
AAAF receives the HAR, this new AAAF will use the MIP-Originating-
Foreign-AAA AVP for policy decisions, such as determining if the FA-
HA Key should be encrypted or not."
Page 15, second to last paragraph:
"If the AAAH's local policy determines that the MN-HA keying material must be
encrypted to protect against untrusted intermediate Diameter agent(s)
between the foreign network 1 realm and the home realm, the AAAH will
make use of the CMS application [CMS]."
Change to:
"If the AAAH's local policy determines that the MN-HA nonce must be
encrypted to protect against untrusted intermediate Diameter agent(s)
between the foreign network realm and the home realm, the AAAH will
make use of end-to-end security, such as the CMS application [CMS], which
is a work in progress."
Section 1.6, first paragraph:
"In order to allow the scaling of wireless data access across
administrative domains, it is necessary to minimize the specific
security associations required. This means that each Foreign Agent
should not be required have a pre-configured shared security
association with each Home Agent on the Internet, nor should the
mobile node be required to have a pre-configured shared security
association with any specific home agent or any specific foreign
agent, as defined in [MOBILEIP]."
It is not clear what kind of security associations are being referred to.
Change to:
"In order to allow the scaling of wireless data access across
administrative domains, it is necessary to minimize the
Mobile IP security associations required. This means that each Foreign Agent
should not be required to have a pre-configured Mobile IP security
association with each Home Agent on the Internet, nor should the
mobile node be required to have a pre-configured Mobile IP security
association with any specific home agent or any specific foreign
agent, as defined in [MOBILEIP]."
Page 17, third paragraph:
"Specifically, three keys are generated and are
required by [MOBILEIP]:
- K1 - the MN-HA Key, which will work as security association between
the Mobile Node and the
Home Agent.
- K2 - the MN-FA Key, which will work as the security association
between the Mobile Node
and the Foreign Agent
- K3 - the FA-HA Key, which will work as the shared between the
Foreign Agent and the
Home Agent."
Keys and security associations are not the same thing. Please reword to:
""Three keys are generated, and are used within [MOBILEIP] to
authenticate and integrity protect the Mobile IP registration
request and response:
- K1 - the MN-HA Key, between the mobile node and the Home Agent,
a nonce subsequently used
in derivation of the MN-HA session key.
- K2 - the MN-FA Key, between the mobile node and the Foreign Agent,
a nonce subsequently used
in derivation of the MN-FA session key.
- K3 - the FA-HA Key, the session key between the
Foreign Agent and the
Home Agent."
(Did I correctly describe what K1, K2 and K3 are?
If not, can you substitute the correct descriptions?)
Section 1.6, last few paragraphs:
" If the home agent is assigned in the home network, each key is
generated and encrypted by the home Diameter server. If instead the
home agent is assigned in the foreign network the K3 key is generated
and encrypted by the foreign network's local Diameter server, while
the K1 and K2 is still generated and encrypted by the home Diameter
server.
The keys destined for the foreign and home agent are propagated to
the mobility nodes via the Diameter protocol, and the keys must be
encrypted either by IPSec or TLS when deployed in an environment
without Diameter agents. When deployed in an environment with
Diameter agents, the keys must be encrypted by means described in
[CMS].
The keys destined for the mobile node must also be propagated via the
Mobile IP protocol and must therefore instead follow the mechanisms
described in [AAAKEY]]. This means that the keys distributed to the
mobile node are instead sent as key material, and the mobile node and
the home Diameter will use the material and the long term shared
secret to create the keys (see section 5.2).
Once the session keys have been established and propagated, the
mobility devices can exchange registration information directly as
defined in [MOBILEIP] without the need of the Diameter
infrastructure. However the session keys have a lifetime, after
which the Diameter infrastructure must be invoked again to acquire
new session keys."
The term "home network" appears to mean something different here than
in [MOBILEIP], where the home agent *always* exists on the home network.
Also, the conditions under which CMS is used appear to contradict earlier
parts of the draft. Also, it is not clear which keys (K1, K2?) constitute
keying material and which keys are raw session keys.
Please reword to:
"If the home agent is assigned in the home adminstrative domain, session keys
and nonces generated and encrypted by the home Diameter server. If instead the
home agent is assigned in the foreign administrative domain the K3 session key
is generated
and protected by the foreign network's local Diameter server, while
the K1 and K2 nonces are still generated and encrypted by the home Diameter
server.
The session keys destined for the foreign and home agent are propagated to
them via the Diameter Mobile IPv4 application, and MUST be protected by
transmission-level
security (IPsec or TLS) as specified in [DIAMBASE].
When deployed in an environment with untrusted Diameter agents,
the session keys MUST be protected using end-to-end security, such as
via the mechanisms described in the CMS application [CMS], a work in progress.
The K1 and K2 nonces destined for the mobile node MUST be propagated via
the Mobile IP mechanisms described in [AAAKEY]. This means that the mobile
node and the home Diameter server will combine the K1 and K2 nonces
with the long term shared secret to generate session keys (see section 5.2).
Unlike the K1 and K2 nonces, K3 represents a session key.
Once the session keys have been established and propagated, the
mobile node, foreign agent and home agent can exchange Mobile
IP registration messages. The session keys have a lifetime, after
which the Diameter infrastructure MUST be invoked again to acquire
new session keys."
Page 32.
This page only includes "* [AVP]" on the page. Please reformat.
Section 5.0:
" The mobile node and mobility agents use session keys to compute
authentication extensions applied to registration messages, as
defined in [MOBILEIP]: Mobile-Foreign, Foreign-Home and
Mobile-Home.
If session keys are requested the AAA server(s) MUST return the key
material after the mobile node is successfully authenticated and
authorized.
The SPI values are used as key identifiers, meaning that each
session
key has its own SPI value; nodes that share a key also share an SPI.
The mobile node proposes SPIs for use in computing the
Mobile-Foreign
and Mobile-Home authentication extensions, via the Mobile IP AAA
Key
Request extensions [MIPKEYS], while the home agent allocates the
Mobile-Foreign, Mobile-Home and Foreign-Home SPIs.
Once the session keys have been distributed, subsequent Mobile IP
registrations need not invoke the AAA infrastructure until the keys
expire. These registrations MUST include the Mobile-Home
authentication extension. In addition, subsequent
registrations MUST
also include Mobile-Foreign authentication extension if the Mobile-
Foreign key was generated and distributed by AAA; similarly for
subsequent use of the Foreign-Home authentication extensions."
Again, the role of the keys is somewhat confusing here. The term
"mobility agent" is not defined (does this mean home agent and
foreign agent?) It would also be helpful for key-related discussions to
to be consolidated into a single section, towards the front of the draft. Reword
to:
"The mobile node, Home Agent and Foreign Agent use session keys to compute
message integrity checks within the Mobile registration messages, as
defined in [MOBILEIP]. This provides authentication and message integrity
protection via the MN-FA, FA-HA, and MN-HA authentication extensions.
In order to enable the derivation of session keys, the AAA server(s)
MUST return nonces and session keys after the mobile node is successfully
authenticated and authorized. (Aren't session keys always required?
If not, can you describe when they are required, and when they aren't?)
The SPI values are used as key identifiers, so that each session
key has its own SPI value; nodes that share a key also share a SPI.
The mobile node proposes SPIs for use in computing the Mobile-Foreign
and Mobile-Home authentication extensions, via the Mobile IP AAA Key
Request extensions [MIPKEYS], while the home agent allocates the
Mobile-Foreign, Mobile-Home and Foreign-Home SPIs.
Once the nonces have been distributed, and session keys have
been generated, subsequent Mobile IP registrations need not invoke the
AAA infrastructure until the session keys expire. These registrations
MUST include the MN-HA authentication extension. In addition,
subsequent registrations MUST also include MN-FA authentication
extension if the MN-FA session key was generated from a nonce
distributed by the Mobile IPv4 Diameter application; similarly for
subsequent use of FA-HA authentication extensions."
Question: aren't the MN-FA session keys always
generated from nonces distributed by
Diameter? If not, when aren't they?
Section 5.3:
"If the mobile node does not have a Mobile-Home session key, then the
AAAH is likely to be the only entity trusted that is available to the
mobile node. Thus, the AAAH has to generate the Mobile-Home session
key, and encode it for eventual consumption by the mobile node and
home agent.
If the home agent is in the home realm, then the AAAH can directly
encode the Mobile-Home session key into a MIP-HA-to-MN-Key AVP and
include that AVP in the HAR message for delivery to the home agent.
If, on the other hand, the home agent is to be allocated in the
visited realm, the AAAH transmits the HAR to the foreign home agent,
where, prior to delivery to the home agent, it is perused by the AAAF
hosting the home agent. If the session key needs to be encrypted the
AAAH will encrypt the MIP-HA-to-MN Key AVP and the MIP-FA-to-MN AVP
with help of CMS security application [CMS] using the security
association with the AAAF associated with the home agent. If no
security association exists between the AAAH and the AAAF associated
with the home agent, the AAAH will check if a security association
can be established. If no security association exists and cannot be
created, the AAAH MUST return a Result-Code AVP with
DIAMETER_ERROR_END_TO_END_MIP_KEY_ENCRYPTION.
The AAAH also has to arrange for the key to be delivered to the
mobile node. Unfortunately, the AAA server only knows about Diameter
messages and AVPs, and the mobile node only knows about Mobile IP
messages and extensions [MOBILEIP]. For this purpose, AAAH encodes
the Mobile-Home session key material into a MIP-MN-to-HA-Key AVP,
using its security association with the mobile node, which is added
to the HAR message, and delivered either to a local home agent, or to
the AAAF in the case where the home agent is in the visited network.
The AAAH has to rely on the home agent (that also understands
Diameter) to transfer the keying information into a Mobile IP
Generalized MN-HA Key Reply extension [MIPKEYS] in the Registration
Reply message, using the SPI proposed by the Mobile Node in the MN-HA
Key Request From AAA Subtype extension. The home agent can format the
Reply message and extensions correctly for eventual delivery to the
mobile node. The resulting Registration Reply is added to the HAA's
MIP-Reg-Reply AVP.
After the HAA message is parsed by the AAAH, and transformed into an
AMA, the AMA message containing the MIP-Reg-Reply AVP will eventually
be received by the the foreign agent. The foreign agent can then use
that AVP to recreate a Registration Reply message, containing the
Generalized MN-HA Key Reply extension, for delivery to the mobile
node.
In summary, the AAAH generates the Mobile-Home key material, which is
added to the MIP-MN-to-HA-Key AVP. The key material is then used to
compute the home agent's session key as specified in [MIPKEYS], which
is then added to the MIP-HA-to-MN-Key AVP. These AVPs are delivered
to a home agent by including them in a HAR message sent from either
AAAH or AAAF. The home agent decodes the key for its own use. The
home agent also copies the encoded key material from the MIP-MN-to-
HA-Key AVP into a Generalized MN-HA Key Reply extension appended to
the Mobile IP Registration Reply message. This Registration Reply
message MUST also include the Mobile-Home authentication extension,
created using the newly allocated Mobile-Home session key. The home
agent then encodes the Registration Reply message and extensions into
a MIP-Reg-Reply AVP included as part of the HAA message to be sent
back to the AAA server."
More confusion between session keys, keying material and nonces here. Try this on for size:
"If the mobile node does not have an MN-HA session key, then the
AAAH is likely to be the only entity trusted by the mobile node.
Thus, the AAAH has to assist the nobile node in generating the
MN-HA session key, by transmitting nonces to the mobile node
and Home Agent.
If the home agent is in the home realm, then the AAAH can directly
encode the Mobile-Home nonce within the MIP-HA-to-MN-Key AVP and
include that AVP in the HAR message for delivery to the home agent.
If, on the other hand, the home agent is to be allocated in the
visited realm, the AAAH transmits the HAR to the foreign home agent,
where, prior to delivery to the home agent, it is inspected by the AAAF,
hosting the home agent. If the session key needs to be
protected using end-to-end security, the AAAH will
encrypt the MIP-HA-to-MN Key AVP and the MIP-FA-to-MN AVP
using end-to-end security mechanisms, using the end-to-end
security association between the AAAH and the AAAF associated
with the home agent. If no such security association exists,
the AAAH will check if a security association
can be established. If no security association exists and cannot be
created, the AAAH MUST return a Result-Code AVP with
DIAMETER_ERROR_END_TO_END_MIP_KEY_ENCRYPTION.
The AAAH also has to arrange for the nonce to be delivered to the
mobile node. The AAA server communicates via Diameter
messages and AVPs, and the mobile node communicates via Mobile IP
messages and extensions [MOBILEIP]. As a result, the AAAH encodes
the MN-HA nonce into a MIP-MN-to-HA-Key AVP,
using its security association with the mobile node, which is added
to the HAR message, and delivered either to a local home agent, or to
the AAAF in the case where the home agent is in the visited network.
The AAAH has to rely on the home agent, which supports Diameter
to encode the nonce within a Mobile IP Generalized MN-HA Key Reply
extension [MIPKEYS] in the Registration Reply message,
using the SPI proposed by the Mobile Node in the MN-HA Key Request
From AAA Subtype extension. The home agent can format the
Reply message and extensions correctly for eventual delivery to the
mobile node. The resulting Registration Reply is added to the HAA's
MIP-Reg-Reply AVP.
After the HAA message is parsed by the AAAH, and translated to an
AMA, the AMA message containing the MIP-Reg-Reply AVP will eventually
be received by the the foreign agent. The foreign agent can then use
that AVP to recreate a Registration Reply message, containing the
Generalized MN-HA Key Reply extension, for delivery to the mobile
node.
In summary, the AAAH generates the MN-HA nonce, which is
added to the MIP-MN-to-HA-Key AVP. The nonce is then used to
compute the MN-HA session key as specified in [MIPKEYS], which
is then added to the MIP-HA-to-MN-Key AVP.
[I'm confused. Is both keying material *and* session keys transmitted?
This seems to contradict the earlier discussion. Please clarify.]
These AVPs are delivered to a home agent by including them in a HAR
message sent from either AAAH or AAAF. The home agent decodes the key
for its own use. [What key? The session key? The nonce?]
The home agent also copies the nonce from the MIP-MN-to-
HA-Key AVP into a Generalized MN-HA Key Reply extension appended to
the Mobile IP Registration Reply message. This Registration Reply
message MUST also include the Mobile-Home authentication extension,
created using the newly allocated Mobile-Home session key. The home
agent then encodes the Registration Reply message and extensions into
a MIP-Reg-Reply AVP included as part of the HAA message to be sent
back to the AAA server."
Section 5.4:
" 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.
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."
Again, lack of clarity with respect to session keys and nonces. Try this:
" The MN-FA nonce is 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
computed 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.
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."
Section 5.5.2, third and fourth paragraphs:
"If the AAAF's local policy determines that the session key needs to
be encrypted by means other then through IPSec or TLS, as defined
in
[DIAMBASE], due to involvement of more then one local Diameter
server
or any intermediate Diameter agents, the AAAF will check if a
security association can be established, using the CMS security
application [CMS] with the originating host found in the MIP-
Originating-Foreign-AAA AVP. If the security association
establishment is successful, the AAAF will encrypt the MIP-FA-to-HA
Key AVP with help of the CMS security application [CMS] with the
AAAF
as originator and the recipient copied from the MIP-Originating-
Foreign-AAA AVP. The encrypted FA-HA Key is included by the AAAF in
the HAA destined for the AAAH. Otherwise, if the security
association
cannot be created, the AAAF MUST return a Result-Code AVP with
DIAMETER_ERROR_END_TO_END_MIP_KEY_ENCRYPTION.
If the session key does not need to be encrypted, the AAAF will add
MIP-FA-to-HA Key to the HAA, upon reception from the HA and forward
the HAA to the AAAH.
In either case, the AAAF removes the MIP-FA-to-HA-SPI AVP from
the
HAA returned to the AAAH.
Upon reception of the HAA, the AAAH MUST copy either the
MIP-FA-to-HA
Key AVP if present or the CMS-Encrypted-data AVP if present and not
destined for the AAAH into the AMA.
If a Foreign-Home session key was present in the AMA, the foreign
agent MUST include the Mobile-Foreign authentication extension in
the
Registration Reply, using the newly distributed key."
Issues with CMS dependence. Reword to:
"If the AAAF's local policy determines that the session key needs to
be protected using end-to-end security, the AAAF will check if an
end-to-end security association can be established with the
originating host found in the MIP-Originating-Foreign-AAA AVP.
If end-to-end security association establishment is successful, the
AAAF will encrypt the MIP-FA-to-HA
Key AVP using end-to-end security, with the AAAF
as originator and the recipient copied from the MIP-Originating-
Foreign-AAA AVP. The encrypted FA-HA Key is included by the AAAF in
the HAA destined for the AAAH. Otherwise, if the end-to-end security association
cannot be created, the AAAF MUST return a Result-Code AVP with
DIAMETER_ERROR_END_TO_END_MIP_KEY_ENCRYPTION.
If the session key does not need to be encrypted, the AAAF will add
MIP-FA-to-HA Key to the HAA, upon reception from the HA and forward
the HAA to the AAAH.
In either case, the AAAF removes the MIP-FA-to-HA-SPI AVP from the
HAA returned to the AAAH.
Upon reception of the HAA, the AAAH MUST copy end-to-end security
AVPs into the AMA.This includes either the MIP-FA-to-HA Key AVP
if present. If end-to-end security AVPs are present and not
destined for the AAAH, these are also copies into the AMA
(e.g. the CMS-Encrypted-data AVP).
If a Foreign-Home session key was present in the AMA, the foreign
agent MUST include the MN-FA authentication extension in the
Registration Reply, computed using the newly distributed session key."
Section 6.0, first few paragraphs:
" The Mobile-IP protocol defines a set of security associations
shared
between the mobile node, foreign agent and home agents. These three
security associations (Mobile-Home, Mobile-Foreign, and
Foreign-Home)
can be dynamically created by the AAAH, known as session key and
key
material, and has previously been described in section 1.6 and 5.2.
AAA servers supporting the Diameter Mobile IP Application MUST
implement the KDC AVPs defined in this document.
The names of the KDC AVPs indicate the two entities sharing the
security association defined by the key or the key material; the
intended receiver of the AVP is the first named entity. So, for
instance, the MIP-MN-to-HA-Key AVP contains the Mobile-Home key
material, which the mobile node will use to derive the Mobile-Home
Key, and the MIP-HA-to-MN-Key AVP contains the Mobile-Home key for
the home agent.
If strong authentication and confidentiality of the session keys is
required, due to involvement of intermediate Diameter agents, it is
recommended that the CMS security application [CMS] be used.
The following table describes the Diameter AVPs defined in the
Mobile
IP application, their AVP Code values, types, possible flag values
and whether the AVP MAY be encrypted."
More confusion between session keys and nonces. Reword as follows:
"The Mobile-IP protocol defines a set of security associations shared
between the mobile node, foreign agent and home agents. These three
security associations (MN-HA, MN-FA, FA-HA)
can be dynamically created by the AAAH, as described in sections 1.6 and 5.2.
AAA servers supporting the Diameter Mobile IP Application MUST
implement the KDC AVPs defined in this document.
The names of the KDC AVPs indicate the two entities sharing the
security association defined by the session key or nonce; the
intended receiver of the AVP is the first named entity. So, for
instance, the MIP-MN-to-HA-Key AVP contains the MN-HA nonce,
which the mobile node will use to derive the Mobile-Home session key,
and the MIP-HA-to-MN-Key AVP contains the MN-HA nonce for
the home agent.
If end-to-end protection of session keys and nonces is required, then
end-to-end security mechanisms are required, such as the CMS
security applicatoin [CMS], a work in progress.
The following table describes the Diameter AVPs defined in the Mobile
IP application, their AVP Code values, types, possible flag values
and whether the AVP MAY be encrypted."
Section 9 (IANA considerations).
Please add the following boilerplate:
"The IANA considerations relating to assignment of Diameter parameter are
described in [DIAMBASE]. This section describes the parameter values assigned
for use with the Diameter Mobile IPv4 application."
11.1 Normative references.
Add reference to [RFC2989].
Issue 368: Security issues with MIP-12
Submitter: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: September 17, 2002
Reference:
Document: MIP-12
Comment type: T
Priority: S
Section: 5.2, 10
Rationale/Explanation of issue:
There is a potential weakness in the generation of MN session keys.
The size of the MN-HA long term shared secret is not specified.. Recommend
requiring this to be randomly chosen and at least 96-bits.
There is also no requirement that the session keys be temporally and
globally unique, and since they are only dependent on a 64-bit nonce, the
MN IP address, and the long-term secret, they could repeat.
While the keys are all encrypted, I'd suggest a larger nonce (128-bits),
and some additional mixing (such as by adding the FA IP address to the
hash).
Specific suggested changes below:
Section 5.2:
"5.2 Key Material vs. Session Key
As described in section 1.6, each mobile IP security association that
is generated by the AAAH will be propagated to the mobility agents
and the mobile node in two different ways. All security associations
destined for the home and foreign agents are sent as session keys,
protected by IPSec or TLS as defined in the [DIAMBASE]. If strong
authentication and confidentiality of the session keys is required
due to involvement of intermediate Diameter agents, it is recommended
that the CMS security application [CMS] be used.
Since the security associations for the mobile node are propagated
through the mobile IPv4 protocol, the security associations are
always sent in the form of key material, which the AAAH computes by
generating a random [RANDOM] value of at least 64 bits. The mobile
node will then use the key material to derive the session key to be
used for the security associations.
The following is an example of a session creation procedure, which
the mobile node has to comply with, using HMAC-MD5 as the hashing
algorithm to derive the key (of course the same session creation
procedure must also be used by the AAAH for the opposite key sent to
the home agent and foreign agent). Additional algorithms are
supported, and listed in [MIPKEYS], where also the HMAC-SHA1
algorithm is recommended to be used.
key = HMAC-MD5(AAA-key,{Key Material | node-address})
Where:
- AAA-Key is the long term secret shared between the mobile
node and the AAAH.
- Key material is a random [RANDOM] value of at least 64 bits.
- node-address is the mobile node's identity. This is the
contents of the MIP-Mobile-Node-Address AVP, unless the value
of the AVP is all zero or ones, in which case of value of the
User-Name AVP is used instead."
Some references to CMS need to be cleaned up, and
a 64-bit nonce is probably not enough. Reword to:
"As described in section 1.6, session keys and nonces are generated
by the AAAH and are transmitted to the home agent, foreign agent
and mobile node. Security associations destined for the home and
foreign agents are established via transmission of session keys and SPIs,
protected by transmission-level security as defined in [DIAMBASE].
Where it is necessary to protect the nonces, session keys and SPIs from
untrusted Diameter agents, end-to-end security mechanisms are required,
such as the CMS application [CMS], a work in progress.
The mobile node security associations are established via
nonces transmitted to the mobile node via Mobile
IPv4. To provide the nonces, the AAAH generates
a random [RANDOM] value of at least 128 bits. The mobile
node then uses the nonce to derive the MN-HA and
MN-FA session keys.
The session key creation procedure is described below in more
detail. HMAC-MD5 is used as the hashing algorithm to enable
session keys to be derived from the long term shared secret and the nonce.
The same procedure is used by the AAAH for creation of the session keys
sent to the home and foreign agent. Additional supported algorithms are
listed in [MIPKEYS], where the HMAC-SHA1 algorithm is recommended. (so why
is HMAC-MD5 used in the examples?)
key = HMAC-MD5(AAA-key,{Nonce | MN-address | FA-address})
Where:
- AAA-Key is the pre-shared key between the mobile
node and the AAAH.
- Nonce is a random [RANDOM] value of at least 128 bits.
- FA-address is the address of the foreign agent.
- MN-address is the mobile node's identity. This is the
contents of the MIP-Mobile-Node-Address AVP, unless the value
of the AVP is all zero or ones, in which case of value of the
User-Name AVP is used instead."
Section 10, security considerations:
" This specification describes the Diameter Application necessary to
authenticate and authorize a Mobile IP mobile node. The
authentication algorithm used is dependent upon the transforms
available by the Mobile IP protocol, and [MIPCHAL]. This
specification also defines a method by which the home Diameter server
can create and distribute session keys to be used to authenticate
Mobile IP registration messages [MOBILEIP]. The key distribution is
asymmetric due to the fact the keys to the mobile node have to be
propagated via the mobile IP protocol [AAAKEY, MOBILEIP], while the
mobility agent keys are propagated via the Diameter protocol. This
means that the keys destined to the mobility agents are always
protected by IPSec or TLS as defined in [DIAMBASE], when deployed
without any Diameter agents, or protected using the methods defined
in [CMS], when deployed in an environment that includes Diameter
agents. The keys destined for the mobile node are always sent as key
material, which is used to derive the actual keys, which means that
it does not expose any data that could be used in an attack aimed at
recovering the long term key shared between the mobile node and the
home Diameter server.
Periodic key refreshment is a fundamental security practice that
helps against potential weaknesses of the function and keys, and
limits the damage of an exposed key. Therefore, must the long-term
shared secret between the mobile node and the home Diameter server
also be periodically refreshed, by utilizing some out-of-band
mechanism, since this shared secret cannot be refreshed by any in-
band mechanism.
It should also be noted that it is not recommended to set the MIP-
Session-Key AVP value equal to zero, since keeping session keys for a
long time (no refresh) increases the vulnerability of the system."
Clarification of vulnerabilities and keying terminology needed. Reword as
follows:
"This specification describes a Mobile IPv4 Diameter Application for
authenticating and authorizing a Mobile IPv4 mobile node. The
authentication algorithm used is dependent upon the transforms
used within the Mobile IP protocol, and [MIPCHAL]. This
specification also defines a method by which the home Diameter server
can create and distribute session keys and nonces for use in
authenticating and integrity-protecting Mobile IP registration messages
[MOBILEIP]. The key distribution is asymmetric since communication with
the mobile node occurs via the mobile IP protocol [AAAKEY, MOBILEIP],
while communication to the Home Agent and Foreign Agent occurs via the Diameter
protocol. As required by [DIAMBASE], transmission-level security (IPsec or TLS)
MUST
be used between Diameter nodes. Where untrusted Diameter agents are
present, end-to-end security MUST be used, via mechanisms such as the CMS
application [CMS], a work in progress.
Nonces are sent to the mobile node, which are used to generate
the session keys via the HMAC-MD5 one-way function. If the nonces
are compromised, then the pre-shared key between the
mobile node and the home Diameter server would be vulnerable to
an offline dictionary attack. To prevent this, the pre-shared
key between the mobile node and the home Diameter server SHOULD
be a randomly chosen quantity of at least 96 bits.
Since the session key is determined by the long-term secret and
the nonce, the nonce SHOULD be temporally and globally unique;
if the nonce were to repeat, then so would the session key.
To prevent this, a nonce of at least 128 bits is REQUIRED.
The long-term secret between the MN and HA MUST be
periodically refreshed, to guard against recovery of the long-term
secret due to nonce reuse or other factors. This is accomplished
using out-of-band mechanisms, which are not specified in this document.
It should also be noted that it is not recommended to set the MIP-
Session-Key AVP value equal to zero, since keeping session keys for a
long time (no refresh) increases the level of vulnerability."
Issue 369: Peer State Machine Bug
Submitter name: Ghadiyaram Venkata Kishore
Submitter email address: Ext-Venkata.Ghadiyaram@nokia.com
Date first submitted: September 25, 2002
Reference:
Document: Base
Comment type: T
Priority: 1
Section:
Rationale/Explanation of issue
In the peer state machine specification in the base protocol there is
a difference in handling R-Conn-CER event when the state is
R-Open and when the state is I-Open.
R-Open R-Conn-CER R-Snd-CEA R-Open
R-Reject
I-Open R-Conn-CER R-Reject R-Open
It should not be necessary to send a CEA as the state is already open
on another another connection. The incoming R_CONN_CER can be
just rejected. Moreover if a CEA is to be sent then which result code
should be used by the CEA in this case.
Requested Change :
Change
R-Open Send-Message R-Snd-Message R-Open
R-Rcv-Message Process R-Open
R-Rcv-DWR Process-DWR, R-Open
R-Snd-DWA
R-Rcv-DWA Process-DWA R-Open
R-Conn-CER R-Snd-CEA R-Open
R-Reject
Stop R-Snd-DPR Closing
R-Rcv-DPR R-Snd-DPA, Closed
R-Disc
R-Peer-Disc R-Disc Closed
R-Rcv-CER R-Snd-CEA R-Open
R-Rcv-CEA Process-CEA R-Open
To
R-Open Send-Message R-Snd-Message R-Open
R-Rcv-Message Process R-Open
R-Rcv-DWR Process-DWR, R-Open
R-Snd-DWA
R-Rcv-DWA Process-DWA R-Open
R-Conn-CER R-Reject R-Open
Stop R-Snd-DPR Closing
R-Rcv-DPR R-Snd-DPA, Closed
R-Disc
R-Peer-Disc R-Disc Closed
R-Rcv-CER R-Snd-CEA R-Open
R-Rcv-CEA Process-CEA R-Open
Issue 370: IANA considerations issues
Submitter name: Scott Bradner
Submitter email address: sob@harvard.edu
Date first submitted: October 5, 2002
Reference:
Document: Base
Comment type: T
Priority: S
Section: 11
Rationale/Explanation of issue
This issue covers IESG concerns about Diameter IANA considerations.
Date: Sat, 5 Oct 2002 12:53:38 -0400 (EDT)
From: Scott Bradner <sob@harvard.edu>
Subject: Diameter IANA Considerations Issues
I do not like ad-hoc assignments if that can lead to non-interoperable
implementations so I like to require at least a public specification.
I'd rather that the public spec be an RFC so that there is some
additional sanity check when the IESG takes a pre-publication look
but a Designated Expert is not too bad.
one nit on the IPS wording - it does not require that a reject notice
comes along with a reason and, where possible, suggestions on
how to make the request acceptable.
Scott
Proposed changes to deal with this concern:
Section 11:
Change:
" Diameter is not intended as a general purpose protocol, and
allocations SHOULD NOT be made for purposes unrelated to
authentication, authorization or accounting. For registration
requests where a Designated Expert should be consulted, the
responsible IESG area director should appoint the Designated
Expert.
For registration requests requiring Expert Review, the AAA mailing
list should be consulted. For registration requests requiring
Expert
Review, the AAA mailing list should be consulted; if the AAA WG is
disbanded, and the mailing list is no longer available, then the
Area
Director may appoint a Designated Expert."
To:
"Diameter is not intended as a general purpose protocol, and
allocations SHOULD NOT be made for purposes unrelated to
authentication, authorization or accounting.
For registration requests where a Designated Expert should be
consulted, the
responsible IESG area director should appoint the Designated
Expert.
For Designated Expert with Specification Required, the request is posted
to
the AAA WG mailing list (or, if it has been disbanded, a successor
designated by the Area Director) for comment and review, and MUST include
a pointer to a public specification. Before a period of 30 days has passed, the Designated
Expert will either approve or deny the registration request and publish a
notice of the decision
to the AAA WG mailing list or its sucessor. A denial notice must be
justified by an explanation and, in the cases
where it is possible, concrete suggestions on how the request can be modified so as to become
acceptable."
Section 11.1.1
Change:
" The AVP Code namespace is used to identify attributes. When the
Vendor ID value is set to zero (0), IANA will maintain a registry of
assigned AVP codes and in some cases also their values. AVP Codes
0-254 are managed separtely as RADIUS Attribute Types [RADTYPE],
while the remaining namespace is available for assignmetn via Expert
Review with Specification Required [IANA].
Vendor-Specific AVP Codes, where the Vendor-Id field in the AVP
header is set to a non-zero value, are for Private Use.
This document defines the AVP Codes 257-274, 276-285, 287, 291-299,
480, 483 and 485-486. See section 4.6 for the assignment of the
namespace in this specification."
To:
" The AVP Code namespace is used to identify attributes. When the
Vendor ID value is set to zero (0), IANA will maintain a registry of
assigned AVP codes and in some cases also their values.
AVP Codes 0-254 are managed separately as RADIUS Attribute Types [RADTYPE].
This document defines the AVP Codes 257-274, 276-285, 287, 291-299,
480, 483 and 485-486. See section 4.6 for the assignment of the
namespace in this specification.
AVPs may be allocated following Designated Expert with Specification
Required [IANA]. Release of blocks of AVPs (more than 3 at a time
for a given purpose) should require IETF Consensus.
Note that Diameter defines a mechanism for Vendor-Specific AVPs, where
the Vendor-Id field in the AVP header is set to a non-zero value.
Vendor-Specific AVPs codes are for Private Use and should be encouraged
instead of allocation of global attribute types, for functions specific
only to one vendor's implementation of Diameter, where no interoperability
is deemed useful. Where a Vendor-Specific AVP is implemented by more than
one vendor, allocation of global AVPs should be encouraged instead."
Section 11.2.1
Change:
" The Command Code namespace is used to identify Diameter commands.
The
values 0-255 are reserved for RADIUS backward compatibility, and
are
defined as "RADIUS Packet Type Codes" in [RADTYPE]. The values
16,777,200 to 16,777,215 (hexidecimal values FFFFF0 - FFFFFF) are
reserved for temporary, experimental commands. The remaining values
are available via Standards Action [IANA].
Experimental Command Codes, are for private, experimental usage. As
these codes are only for experimental purposes, no guarantee is
made
for interoperability between Diameter peers using experimental
commands. The range of values will have a limited lifetime,
and will
eventually be reallocated within a range available for
standardization.
This document defines the Command Codes 257, 258, 271, 274-275, 280
and 282. See section 3.1 for the assignment of the namespace in
this
specification."
To:
"The Command Code namespace is used to identify Diameter commands. The
values 0-255 are reserved for RADIUS backward compatibility, and are
defined as "RADIUS Packet Type Codes" in [RADTYPE].
Values 256-16,777,199 are for permanent, standard commands, allocated by
IETF Consensus [IANA]. This document defines the Command Codes 257,
258, 271, 274-275, 280 and 282. See section 3.1 for the assignment of
the namespace in this specification.
The values 16,777,200 to 16,777,215 (hexidecimal values FFFFF0 - FFFFFF)
are reserved for temporary, experimental commands, expected to be
used for a year or less. As these codes are only for experimental
purposes, no guarantee is made for interoperability between Diameter
peers using experimental commands. Experimental commands are
allocated by IETF Consensus [IANA]."
Section 11.4 - 11.9, 11.11 - 11.16
I'd suggest that these sections be put under a single section entitled
"AVP values". As part of this, we need a general policy for AVP values,
other than the ones specified. In RADIUS this is first come first served.
Here is suggested text for Diameter:
11.3
Change:
"Assignment of standards-track application IDs are by Expert Review
with Specification Required [IANA]."
To:
" Assignment of standards-track application IDs are by Designated
Expert
with Specification Required [IANA]."
11.4 AVP Values
Certain AVPs in Diameter define a list of values with various meanings.
For attributes other than those specified in this section, addition of
values can be done on a First Come, First Served basis by the IANA.
Review of RADIUS IANA Considerations
B. Aboba
The allocation policy for RADIUS (RFC 2865) is:
Commands: Standards Action
Attribute values: First come, first served
Attribute 26: Private Use
Attributes 92-191: Expert Review with specification required
Attributes 192-240: Private Use
Attributes 241-255: Standards Action
Blocks of attributes: IETF consensus
The currently proposed allocation policy of Diameter is:
Experimental Command Codes: Private Usage
Other Command codes: Standards Action
Application IDs: Designated Expert with Specification Required (see above)
Vendor-Specific AVPs: Private Use
Standard AVPs: Designated Expert with Specification Required (see above)
AVP values: IETF consensus for specific values, First Come, First Served for
others (see issues above)
Status of RADIUS assignments is available at:
http://www.iana.org/assignments/radius-types
Command Codes
In practice, Command Codes seem to be allocated by IETF consensus, rather
than Standards Action. For example, RFC 2866 (RADIUS Accounting) was
Informational, yet was allocated a Command Code. Similarly, the Dynamic
Authorization draft is being allocated command codes and it is also
informational.
Otherwise, the policy seems to be working ok.
Attribute values
This policy seems to be working ok; there have been no issues so far.
Attributes
Prior to the publication of RFC 2865 in June 2000, the IANA was implementing
a first come, first served policy for attributes.
This caused some problems. For one attribute, no specification was
provided, and so we had to ask for it (in order to support the same attribute
in Diameter). The spec we got was unclear in parts and we've had to go
back and forth.
Since June 2000, IANA has been implementing the RFC 2865 policy. No issues
have arisen since then, partly because no attributes have been allocated.
Note that RFC 2865 does not describe what happens if the
RADIUS mailing list were to disappear; it would make sense for the
AD to either specify another list or appoint a Designated Expert.
Given that the policy has never been tested, it is not clear how well
it would work in practice. For example, how is mailing list consensus
determined (particularly if the WG is disbanded)? What happens if the
specification is unclear?
Recently IPS WG has chosen Designated Expert with Specification Required
in similar circumstances. This allows the Designated Expert to deny the request
if the
specification was not made available/was unclear, and also allows the AD
some flexibility. For example, here is some language from the IPS Security
document:
"Designated Expert with Specification Required. The request is posted to
the IPS WG mailing list (or, if it has been disbanded, a successor
designated by the Area Director) for comment and review, and MUST include
a specification. After a period of one month as passed, the Designated Expert
will either approve or deny the registration request."
Issue 371: Editorial Comments on draft-13
Submitter name: Pete McCann
Submitter email address: mccap@lucent.com
Date first submitted: October 7, 2002
Reference:
Document: Base-13
Comment type: E
Priority: S
Section: 6, 11
I spotted a few editorial issues in draft-13:
Section 6.1, page 69: it looks like steps 2 and 3 of the message
processing rules have been munged together. Maybe some nroff needs
fixing.
Section 11, 1st paragraph: "IETF Consensus" needs a leading quotation
mark.
Section 11.3, 2nd paragraph, the wording is a little confusing. I
suggest changing from this:
IANA [IANA] will assign the range 0x00000001 to 0x00ffffff for
standards-track applications; and 0xff00000000 - 0xfffffffe for
vendor specific applications, on a first-come, first-served basis.
Assignment of standards-track application IDs are by Expert Review
with Specification Required [IANA].
To this:
IANA [IANA] will assign the range 0x00000001 to 0x00ffffff for
standards-track applications; and 0xff00000000 - 0xfffffffe for
vendor specific applications. Assignment of standards-track
application IDs is by Expert Review with Specification Required
[IANA]. Assignment of vendor specific application IDs is on a
First Come First Served [IANA] basis.
[BA] - note that "Expert Review" conflicts with the "Designated Expert"
allocation recommended by Scott Bradner in Issue 370. Recommend using
"Designated Expert".
Issue 372: Real-time duplicate detection
Submitter name: Marco Stura
Submitter email address: marco.stura@nokia.com
Date first submitted: 11/10/2002
Document: draft-ietf-aaa-diameter-13.txt
Comment type: T
Priority: 1
Section: Several
Rationale/Explanation of issue:
I apologize about opening this discussion so late, but our colleagues at Nokia just notice
d
this problem while discussing the possible error cases for the
draft Diameter Credit Control Application. This is used in 3GPP
Rel5 IMS (IP Multimedia subsystem) to realize real-time credit based
accounting (i.e prepaid accounting, sometime called "token based accounting").
The problem we have is related to real-time duplicate detection of event
accounting requests. I briefly summarize the problem below.
In the Credit Control Application it is possible for a one-time event to be used for three
different purposes: direct debiting, refunding and balance checks. The problem
appears with direct debiting and refunding.
One time events use accounting request [event] messages and when the
action is direct debiting, the corresponding amount of money is directly
deducted from the user's account. When the action is refunding, the corresponding
amount of money is credited to the user's account.
These use cases require real-time duplicate detection of event requests
in order to avoid duplicate debiting or refunding of the same request.
The duplicate detection must be performed and the answer
returned immediately so as to grant or not grant the service to the end user
within few seconds. If the end user has to wait too
long before being able to use the requested service (e.g. Instant messaging)
the user experience will suffer.
With the current Diameter base protocol, the Credit Control Server would
need to check each request for duplicate, by searching within a time window (e.g a day).
In GSM networks there are several milion prepaid subscribers and it is a very
difficult task for the CC servers to perform real-time duplicate detection with
this
approach. As a result, we fear that performance will suffer and the answer
will be sent too late to the client.
Use of hashing techniques or other schemes help to eliminate the need to do
a
full search of received accounting requests within a time window as mentioned
in AnnexC.
However, the hashing approach hasn't
been
tried in practise or evaluated in full.
We believe that hashing introduces additional complexity to server implementation
and
there are details that need to be worked out, such as finding the proper hashing function, hash table size etc. to minimize collision cases. In contrast other techniques for duplicate
detection
are proven to work and operational in live networks with millions
of
subscribers(e.g. 3GPP GPRS charging protocol).
In those networks, the client marks the possible duplicate upon
message re-transmission.
For those not familiar with this technique, I suggest reading
the 3GPP technical specifications 32.215
(http://www.3gpp.org/ftp/Specs/archive/32_series/32.215/). 3GPP implementations use
this mechanism to support hot-billing where real-time duplicate detection
is required.
For these reasons we think that there might be implementations
that do not plan to
support hashing techniques in the near future and would desire a simpler
approach to
real-time duplicate detection to be offered as part of the base protocol in
addition to more complex techniques.
We propose that the base protocol mark re-transmitted messages by dedicating
one
reserved bit of the Diameter header to this purpose. Server behavior is
implementation dependent; the server may use the D-bit or
hashing for their implementation, since this does not affect
interoperability at all.
This proposal was discussed some time ago and was
rejected because
real-time duplicate detection was not seen necessary. We beleive that there is
now a
requirement for this and a proven, simple algorithm should be offered.
Requested change:
Change chapter 3 as follows:
3 Diameter Header
A summary of the Diameter header format is shown below. The fields
are transmitted in network byte order.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R P E T r r r r| Command-Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Application-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop-by-Hop Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| End-to-End Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVPs ...
+-+-+-+-+-+-+-+-+-+-+-+-+-
Version
This Version field MUST be set to 1 to indicate Diameter Version
1.
Message Length
The Message Length field is three octets and indicates the length
of the Diameter message including the header fields.
Command Flags
The Command Flags field is eight bits. The following bits are
assigned:
R(equest) - If set, the message is a request. If cleared, the
message is an answer.
P(roxiable) - If set, the message MAY be proxied, relayed or
redirected. If cleared, the message MUST be
locally processed.
E(rror) - If set, the message contains a protocol error,
and the message will not conform to the ABNF
described for this command. Messages with the 'E'
bit set are commonly referred to as error
messages. This bit MUST NOT be set in request
messages. See section 7.2.
T(Potentialy re-transmitted message)
This flag is defined only for request messages sent by Diameter clients or
agents.
This flag is used as an indication of an application layer retransmission event,
e.g. due to failover to an alternate server.
If a Diameter client or agent knows that it is sending this
request or accounting record contained in the request for the first time,
it MUST reset this flag. Diameter agents only need to be concerned
about the number of requests they send based on a single received
request; retransmissions by other other enties need not be tracked.
However, Diameter agents that receive a request with the T flag set,
MUST keep the T flag set in the forwarded request.
If request is either known to be a retransmission or the Diameter
client or agent is unable to assure that it is the first such request,
it MUST set this flag. For instance, after a reboot, a client may not
know whether it has already tried to send the accounting records
in its non-volatile memory before the reboot occurred.
Diameter servers MAY use the T flag as an aid when processing
requests and detecting duplicate messages. However, servers
that do this MUST ensure that duplicates are found even when
the first transmitted request arrives at the server after the
retransmitted request.
This flag MUST NOT be set if an error answer message
(e.g. a protocol error) has been received for the earlier
message. It can be used only in cases where no
answer has been received from the Server for a request and the request
is sent again, (e.g. due to a failover to an alternate peer, due
to a recovered primary peer or due to a client re-sending a stored
record from non-volatile memory such as after reboot of a client or agent).
This flag MUST NOT be set in answer messages.
r(eserved) - these flag bits are reserved for future use, and MUST be set to
zero, otherwise an error MUST be sent to the sender.
5.5.4 Failover and Failback Procedures
Change the paragraph
When a transport failure is detected, all messages in the queue are
sent to an alternate agent, if possible.
.....etc..
to
When a transport failure is detected, if possible all messages in the queue are
sent to an alternate agent with the T flag set. On booting a Diameter client or
agent,
the T flag is also set on any records still remaining to be transmitted in
non-volatile storage.
8.2 Accounting Session State Machine
Change the line
Idle Records in storage Send PendingB
record
of CLIENT, ACCOUNTING to
Idle Records in storage Send PendingB
record
with T
flag set
[BA - does this make sense? I think not, because "storage" here may not mean
non-volatile storage, just placement in the buffer. This would result in many,
many more records marked with the T flag than is really necessary.]
Change appendix C as follows:
Appendix C. Duplicate Detection
As described in section 9.4, accounting record duplicate detection is
based on session identifiers. Duplicates can appear for various
reasons:
- Failover to an alternate server. Where close to real-time
performance is required, failover thresholds need to be kept low
and this may lead to an increased likelihood of duplicates. Failover can occur
at the client or within Diameter agents.
- Failure of a client or agent after sending of a record from non-volatile memory, but
prior to receipt of an application layer ACK and deletion of the record.
record to be sent. This will result in retransmission of the record soon after the client
or agent has rebooted.
- Duplicates received from RADIUS gateways. Since the retransmission
behavior of RADIUS is not defined within [RFC2865], the likelihood of
duplication will vary according to the implementation.
- Implementation problems and misconfiguration.
In some cases the Diameter accounting server can delay the duplicate
detection and accounting record processing until a post-processing
phase takes place. At that time records are likely to be sorted
according to the included User-Name and duplicate elimination is easy in this case.
In other situations it may be necessary to perform real-time duplicate
detection, such as when credit limits are imposed or real-time fraud
detection is desired.
In general, only generation of duplicates due to failover or re-sending of
records in non-volatile storage can be reliably detected by Diameter
clients or agents. In such cases the Diameter client or agents can mark
the message as possible duplicate by setting the T flag. Since the
Diameter server is responsible for duplicate detection, it can choose to
make use of the T flag or not, in order to optimize duplicate detection.
Since the T flag does not affect interoperability, and may not be needed
by some servers, generation of the T flag is REQUIRED for Diameter clients
and agents, but MAY be implemented by Diameter servers.
As an example, it can be usually be assumed that duplicates appear
within a time window of longest recorded network partition or device fault,
perhaps a day. So only records within this time window need to be
looked at in the backward direction. Secondly, hashing techniques
or other schemes, such as the use of the T flag in the received
messages, may be used to eliminate the need to do a full search
even in this set except for rare cases.
The following is an example of how the T flag may be used by the server to
detect duplicate requests.
A Diameter server MAY check the T flag of the received message to determine
if the record is a possible duplicate. If the T flag is set in the request
message, the server searches for a duplicate within a configurable duplication
time
window backward and forward. This limits database searching to those records
where the T flag is set. In a well run network, network partitions and device
faults will presumably be rare events, so this approach represents a substantial
optimization of the duplicate detection process. During failover, it is possible
for the original record to be received after the T flag marked record, due to
differences in network delays experienced along the path by the original and
duplicate transmissions. The likelihood of this occurring increases as the
failover interval is decreased.
In order to be able to detect out of order duplicates, the Diameter
server should use backward and forward time windows when performing
duplicate checking for the T flag marked request. For example,
in order to allow time for the original record to exit the network and be
recorded by the accounting server, the Diameter server can delay processing
records with the T flag set until a time period TIME_WAIT +
RECORD_PROCESSING_TIME
has elapsed after the closing of the original transport connection. After this
time period has expired, then it may check the T flag marked records against
the database with relative assurance that the original records, if sent,
have been received and recorded.
Issue 373: Some NITs in -14
Submitter name: Allison Mankin
Submitter email address: mankin@isi.edu
Date first submitted: 11/15/2002
Document: draft-ietf-aaa-diameter-14.txt
Comment type: T
Priority: S
Section: 1.2, 2.1
Rationale/Explanation of issue:
I found these bits, little fixes, that could get tucked into -15.
1.2
The Diameter protocol is designed to be extensible, using several
mechanisms, including:
- Defining new AVP values.
- Creating new AVPs
- Creating new authentication/authorization applications
- Creating new accounting applications
- Application authentication procedures
Reuse of existing AVP values, AVPs, applications and command codes
are strongly recommended. Reuse simplifies standardization and
implementation and avoids potential interoperability issues.
### It should no longer say "and command codes" in this context
### because command codes aren't part of the extensibility framework...
### I think the words are hangovers from the past.
[John Loughney] I'd propose stating something like this:
"Reuse of existing AVP values, AVPs, applications are strongly
recommended. Reuse simplifies standardization and
implementation and avoids potential interoperability issues.
It is expected that command codes are reused; new command
codes can only be created by IETF Consensus (see section 11.2.1)."
-------
Section 2.1 should normatively ref AAATRANS, as 5.1 does.
-------
To save you some round trips:
Diameter nodes MUST be able to negotiate the following TLS cipher
suites:
TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
Diameter nodes MAY negotiate other TLS cipher suites.
The SEC ADs now require AES in place of 3DES. TLS actually
has a finished RFC for AES, rfc3268.txt, so substitute;
TLS_RSA_WITH_AES_128_CBC_SHA or 256?
All 3DES refs have been pretty much been swapped out of TSV specs, even
though none of the specs but TLS are done ;}
[John Loughney] So I will add:
"Diameter nodes SHOULD be able to negotiate the following TLS cipher suite:
TLS_RSA_WITH_AES_128_CBC_SHA "
Issue 374: CMS Sec cut and paste attack
Submitter name: Jari Arkko
Submitter email address: jari.arkko@kolumbus.fi
Date first submitted: 11/15/2002
Document: draft-ietf-aaa-diameter-cms-sec-04.txt
Comment type: T
Priority: S
Section: several
Rationale/Explanation of issue:
I think that the CMS Security application, when ready, should include the command
code and other stuff from the header (otherwise you'll see attacks where
you have the same protected AVPs, but replace resource allocation request with
accounting request etc). As this text in the CMS application is being
developed, we could take care of not including the D bit there.
This can be achieved by defining appropriate MIC AVPs.
Issue 375: Command code allocations for 3GPP Releases
5 and 6
Submitter name: Thomas Narten
Submitter email address: narten@us.ibm.com
Date first submitted: October 21, 2002
Reference:
Document: Base-14
Comment type: T
Priority: S
Section: 11.2.1
Rationale/Explanation of issue
Section 11 of the Diameter Base document uses the term "experimental"
in a confusing way, since "experimental codes" have a different meaning
per draft-narten-iana-experimental. For example, experimental codes are
not for permanent use, and revoking the allocation after a year
is not likely to satisfy 3GPP/3GPP2.
Resolution (discussed by IESG, AAA editors, 3GPP):
Allocate permanent command codes to 3GPP Release 5 via a separate
document:
http://www-nrc.nokia.com/sua/draft-loughney-aaa-cc-3gpp-00.txt
Command codes for 3GPP Release 6 to be allocated from the non-experimental command
space, with IETF documentation. The current intent as agreed with 3GPP is to
develop a standards track application addressing the needs of AAA for SIP/SDP
and encompassing the requirements of the cellular community.
Change Section 11.2.1 as described in
http://www-nrc.nokia.com/sua/draft-ietf-aaa-diameter-15.txt :
(changes highlighted)
11.2.1 Command Codes
The Command Code namespace is used to identify Diameter commands. The
values 0-255 are reserved for RADIUS backward compatibility, and are
defined as "RADIUS Packet Type Codes" in [RADTYPE]. Values
256-16,777,213 are for permanent commands, allocated by
IETF Consensus [IANA]. This document defines the Command Codes 257,
258, 271, 274-275, 280 and 282. See section 3.1 for the assignment of
the namespace in this specification.
---> 2 experimental command codes.
The values 16,777,214 and 16,777,215 (hexidecimal values FFFFFE -
FFFFFF) are reserved for experimental commands. As these codes are
only for experimental and testing purposes, no guarantee is made for
interoperability between Diameter peers using experimental commands,
as outlined in [IANA-EXP].
Issue 376: Base-15 Nits
Submitter name: David Mitton
Submitter email address: david@mitton.com
Date first submitted: October 23, 2002
Reference:
Document: Base-15
Comment type: E
Priority: 1
Section: Several
Rationale/Explanation of issue:
- "Acct-Interim-Interval" has lower case "interim" in two places
- "Accounting-RADIUS-Session-Id" (44) is a really silly name change.
I have a line in NASREQ now that says basically insert the value of
attribute 44, into AVP 44 with a different name. Eg, no value change.
The RADIUS attribute 44 as defined in RFC 2866 is "Acct-Session-Id"
and we have not changed the semantics (just added behaviors to some other
AVPs elsewhere)
Can we just revert to the old name? it does not conflict.
In general, I would think that all RFC 2866 accounting attributes keep
their Acct-* names, and any new Diameter Accounting AVPs are named Accounting-*
This has been true except for this case and Acct-Application-Id (259)
{I guess because it pairs well with Auth-Application-Id (258)}
which really doesn't offer a dictionary conflict.
Dave.
Issue 377: More Base-15 Nits
Submitter name: Mikael Jakobsson
Submitter email address: Mikael.Jakobsson@epk.ericsson.se
Date first submitted: October 28, 2002
Reference:
Document: Base-15
Comment type: T
Priority: 1
Section: Several
Rationale/Explanation of issue:
2.8.3 Redirect Agents
First paragraph states
"Since Redirect agents do not perform any application level
processing, the provide services for all Diameter applications, and
therefore MUST advertise the Relay Application Identifier."
which is the same as last paragraph (except for spelling error in the first one)
"Since Redirect agents do not perform any application level
processing, they provide relaying services for all Diameter
applications, and therefore MUST advertise the Relay Application
Identifier."
Suggestion is to remove the first one.
8.6 Inferring Session Termination from Origin-State-Id
Correct CER/CAA to CER/CEA in the following paragraph (the second one).
"By including Origin-State-Id in CER/CAA messages, an access device
allows a next-hop server to determine immediately upon connection
whether the device has lost its sessions since the last connection."
11.3 Application Identifiers
Second paragraph states 0xff00000000 - 0xfffffffe for vendor specific
applications.
There are too many zeros in 0xff00000000 so correct to 0xff000000 - 0xff000000.
"IANA [IANA] will assign the range 0x00000001 to 0x00ffffff for
standards-track applications; and 0xff00000000 - 0xfffffffe for
vendor specific applications, on a first-come, first-served basis.
Assignment of standards-track application IDs are by Designated
Expert with Specification Required [IANA]."
11.4.1 Result-Code AVP Values
Correct value ranges for result codes from
"As defined in Section 7.1, the Result-Code AVP (AVP Code 268) defines
the values 1001, 2001-2002, 3001-3010, 4001-4002 and 5001-5017."
to
"As defined in Section 7.1, the Result-Code AVP (AVP Code 268) defines
the values 1001, 2001-2002, 3001-3010, 4001-4003 and 5001-5016."
Best Regards
Mikael Jakobsson
-----------------------------------------
Mikael Jakobsson
Ericsson AB
Core Unit Service Network & Applications
Tel: +46 455 39 52 81
Fax: +46 455 815 10
Mobile: +46 703 10 52 81
mailto:Mikael.Jakobsson@epk.ericsson.se
http://www.ericsson.com
Issue 378: Yet More Base-15 Nits
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: November 3, 2002
Reference:
Document: Base-15
Comment type: E
Priority: S
Section: Several
Rationale/Explanation of issue:
Since we agreed to adopt a base protocol standard accounting
application Id, the value needs to be included somewhere and
statements about support being implicit within CER/CEA need
to be removed.
Section 1.2.4, Page 14:
Change:
"Since every Diameter implementation MUST support accounting, there is
no need to advertise support for the Base accounting application
within the CER/CEA, since this is implicit. This basic accounting
support is sufficient to handle any application that uses the ACR/ACA
commands defined in this document, as long as no new mandatory AVPs
are added. A mandatory AVP is defined as one which has the "M" bit
set when sent within an accounting command, regardless of whether it
is required or optional within the ABNF for the accounting
application."
To:
"Every Diameter implementation MUST support accounting.
Basic accounting support is sufficient to handle any application
that uses the ACR/ACA commands defined in this document, as long
as no new mandatory AVPs are added. A mandatory AVP is defined as
one which has the "M" bit set when sent within an accounting
command, regardless of whether it is required or optional
within the ABNF for the accounting application."
Section 1.2.4, last paragraph:
"If the base accounting is used without any mandatory AVPs, new
commands or additional mechanisms (e.g. application defined state
machine), then the base protocol defined standard accounting
application Id (section 2.4) MUST be used in ACR/ACA commands."
The base protocol defined standard accounting application id is not
defined in section 2.4, 11.3 or anywhere else for that matter.
Suggest the value 0x00000000 be allocated in Section 11.3:
"IANA [IANA] will assign the range 0x00000001 to 0x00ffffff for
standards-track applications; and 0xff00000000 - 0xfffffffe for
vendor specific applications, on a first-come, first-served basis.
The value 0x00000000 is allocated for use within the Diameter
Base standard accounting application.
Assignment of standards-track application IDs are by Designated
Expert with Specification Required [IANA]."
Section 3, Application-ID
"See Section 11.3 for the possible values that the application-id may use."
Section 11.3 doesn't contain any such values. Should this section include values
for NASREQ or MIP?
Section 6.8 (Auth-Application-Id AVP) and 6.9 (Acct-Application-ID AVP)
"This AVP SHOULD be placed as close to the Diameter header as possible."
The ABNFs show this AVP 6th in commands such as RAR. Is this "as close as
possible"? Or was this a typo, made unnecessary by including the application-Id
in the header?
Section 3:
" Command-Code values in the range 0xfffffe through 0xffffff are
reserved for experimental use (see Section 11.3). Commands in
this range MUST also include a Vendor-Specific Application ID AVP
(see section 6.11)."
There are only two experimental AVPs now, and this space is to be used
for experimental, not vendor-specific purposes. Please change to:
"Command-Code values 16,777,214 and 16,777,215 (hexidecimal values FFFFFE -
FFFFFF) are reserved for experimental use (See Section 11.3). "
6.11 Vendor-Specific-Application-Id AVP
"Exactly one of the Auth-Application-Id and
Acct-Application-Id AVPs MAY be present."
Shouldn't this statement have occurred earlier, such as in section 6.9?
Missing Non-normative Reference:
[ROAMREV] Aboba, B. et al., "Review of Roaming Implementations", RFC 2194, September 1997.
Issue 379: NASREQ-10 NITs
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: November 3, 2002
Reference:
Document: NASREQ-10
Comment type: T
Priority: S
Section: Several
Rationale/Explanation of issue:
Page 1:
The draft lists 7 authors. This exceeds the guideline of 5 established by the
RFC Editor.
Suggest that two authors be dropped.
Page 2:
"This application,
combined with the Diameter base protocol [BASE], satisfies the
requirements defined in the NAS Requirements AAA Criteria
specification [NASCrit] and the Roaming Operations AAA Criteria
specification [ROAMCrit]."
Suggest change to:
"The Diameter NAS application, when
combined with the Diameter base protocol, Transport Profile, EAP
and CMS Security specifications,
satisfies NAS-related requirements defined in [AAACRIT]."
Section 1, Page 6:
"This is achieved by re-using the RADIUS attribute space,
and eliminating the need to perform most attribute translations."
Actually, it appears that translations are required in a considerable
number of cases. Suggest that this sentence be deleted.
Page 6:
"This document describes Diameter applications that are used for AAA
in the Network Access Server (NAS) environment. This application,
combined with the Diameter base protocol [BASE] and related Diameter
Transport [DiamTrans] and Security [DiamEAP,DiamCMS] specifications,
satisfies the requirements defined in the NAS Requirements AAA
Criteria specification [NASCrit] and the Roaming Operations AAA
Criteria specification [ROAMCrit]."
Suggest change to:
"This document describes the Diameter NAS application that is used for AAA
in the Network Access Server (NAS) environment. This application,
combined with the Diameter base protocol [BASE], Transport Profile
[DiamTrans], EAP [DiamEAP], and CMS Security [DiamCMS] specifications,
satisfies NAS-related requirements defined in [AAACRIT]."
Section 1.2
The Auth-Application-Id OR Acct-Application-Id are included in the CER/CEA,
but never both.
Suggest changing:
" Diameter nodes conforming to this specification MAY advertise support
by including the value of one (1) in the Auth-Application-Id and/or
the Acct-Application-Id AVP of the Capabilities-Exchange-Request and
Capabilities-Exchange-Answer commands [BASE]."
To:
"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]."
Section 2:
"If the value of Result-
Code is DIAMETER_MULTI_ROUND_AUTH, an additional authentication
exchange is indicated, and several AAR and AAA messages may be
exchanged until the transaction completes."
Can you give a usage example (e.g. Challenge/Response token
cards)?
Section 2.2:
"the NAS is using RADIUS which does not
support re-authentication or re-authorization."
Actually, RADIUS *does* support re-authentication, just not driven
by the server (except for dynamic authorization). Change to:
"the NAS is using RADIUS which does not support server-initiated
re-authentication or re-authorization. For an exception, see [RADDYNAUTH]."
Section 3.1 and 3.2
EAP-Payload is included in the AAR/AAA messages. Isn't this
reserved for the EAP application only? If not, can you provide
guidelines as to which application ID (NASREQ or EAP) is used
with EAP?
Section 4.1
AVPs NAS-Port-Id, Called-Station-Id, Calling-Station-ID are listed
as type UTF8String. Is this correct? These AVPs typically only contain
numbers and a few other characters. If so, they should contain
ASCII characters only.
Section 4.1.6
An example of the Connect-Info AVP would be helpful.
Section 4.1.9
" Note: The Termination-Action AVP is typically used for the login
service (Service-Type = 1 or "Login") or by 802.1X supplicants
[802.1X] (e.g., NAS-Port-Type = 19 or "Wireless - IEEE 802.11").
When used for the login service, the service typically terminates
when the login host clears the connection. The NAS may prompt the
user for a new connection and issue a new AA-Request.
When used by 802.1X supplicants, the service typically terminates due
to the expiry of the Session-Timeout AVP. The access device may then
reauthenticate the user with a new AA-Request. The RECOMMENDED way
to do this in Diameter is to use the Authorization-Lifetime AVP
rather than the Termination-Action AVP. However, the Termination-
Action AVP MAY be used when copied from a RADIUS Access-Accept to a
Diameter AA-Answer by a Translation Agent."
If the Termination-Action AVP contains a value other than DEFAULT,
shouldn't a Translation Agent use Authorization-Lifetime AVP instead
of copying the Termination-Action AVP into the Diameter AA-Answer?
Section 4.2
EAP-Payload included here again. Is this for use in NASREQ or EAP applications
(or both)?
Section 4.2.1
" The User-Password AVP MUST be encrypted using the methods described
in [DiamSEC], or where [DiamSEC] isn't applied, the whole DIAMETER
message flow MUST be encrypted using IPsec and/or TLS as described in
[BASE]. Unless this AVP is used for one-time passwords, the User-
Password AVP SHOULD NOT be used in untrusted proxy environments."
DiamSEC isn't an alternative to use of IPsec or TLS. Change to:
" The User-Password AVP contains a user password or one-time
password and therefore represents sensitive information.
As required in [BASE], Diameter messages are encrypted using
IPsec or TLS. Unless this AVP is used for one-time passwords, the User-
Password AVP SHOULD NOT be used in untrusted proxy environments
without encrypting it using end-to-end security techniques, such
as CMS Security [DiamSEC], a work in progress."
Section 4.2.9
I thought that EAP-Payload was supposed to be defined within the
EAP Application. If it is defined in both NASREQ and EAP applications,
which application-id is used when EAP authentication is desired?
Section 4.3.10.3 and 4.3.10.7
Framed-IPv6-Route and Framed-Route AVP should be ASCII not
UTF8String.
Section 4.4.5
" This AVP MUST only be present in authorization responses in an
encrypted form, using one of the methods described in [BASE] and
[DiamSEC]."
Change to:
" The Tunnel-Password AVP contains sensitive information.
As required in [BASE], Diameter messages are encrypted using
IPsec or TLS. The Tunnel-Password AVP SHOULD NOT be used in
untrusted proxy environments
without encrypting it using end-to-end security techniques, such
as CMS Security [DiamSEC], a work in progress."
Section 6.2.5
" >From RFC 2866, the termination causes are as follows:"
Change to:
" From RFC 2866, the termination causes are as follows:"
Section 8.3:
"8.3. Application Identifier
This specification assigns the value one (1) to the Application
Identifier namespace defined in [IANAConsid]. See section 1.2 for
more information."
Is a separate application-Id needed for NASREQ authentication and
accounting?
Section 9:
" This specification also defines a method by which the home Diameter
server can create and distribute registration keys to be used to
authenticate link layer messages (e.g. PPP ECP). The keys SHOULD be
be protected using the methods defined in [DiamSEC]."
Since keying AVPs are no longer in the specification, this paragraph
should be deleted.
Section 10.1
References need to be updated:
[BASE] - Draft 15 is the latest.
[AAATrans] - Draft 8 is the latest.
[DiamMIP] - Draft 13 is the latest.
Issue 380: NASREQ-10 Questions
Submitter name: Sukjoon Lee
Submitter email address: junny@etri.re.kr
Date first submitted: November 5, 2002
Reference:
Document: NASREQ-10
Comment type: T
Priority: S
Section: Several
Rationale/Explanation of issue:
I have some questions about nasreq-10 preview...
1. In Section 6.1,
"- If state information regarding the RADIUS request was saved in a
Proxy-Info AVP, the RADIUS Identifier and UDP IP Address and
port number are extracted and used in issuing the RADIUS reply."
I think this sentence must be changed to :
"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."
2. Multi-Round-Time-Out AVP is refered in section 6.1 & 6.1.1,
but in 7.1 we can't find this AVP from AAR/A AVP table.
3. In Section 6.1.1
"- The Route-Record AVPs MUST be added to the Diameter message, in
the same order they were present in the request."
Why the Route-Record AVP MUST be added in Diameter answer?
4. Why is the NAS-Session-Key AVP omitted in this draft?
It will be only in aaa-diameter-eap draft?
5. In Section 6.1.1, what is Acct-Session-Id AVP?
where is it defined?
+------------------------------------------------------------+
+ Lee, Sokjoon (ICQ No : 69347005)
+ Office : +82-42-860-5455 Fax : +82-42-860-5611
+ Cell : +82-17-344-1295 E-Mail : junny@etri.re.kr
+ Wireless Internet Security Research Team
+ Electronics and Telecommunications Research Institute
+ 161 Gajeongdong, Yuseonggu, Daejeon, 305-350, Korea
+------------------------------------------------------------+
Issue 381: NASREQ-10 Questions
Submitter name: Valery Kholodkov
Submitter email address: valery@penza.com.ru
Date first submitted: November 7, 2002
Reference: http://home.attbi.com/~dmitton/draft-ietf-aaa-diameter-nasreq-10.txt
Document: NASREQ-10
Comment type: t
Priority: S
Section: Several
Rationale/Explanation of issue:
Hello!
I examined NASREQ 10 and found some disadventages, which had not been
eliminated since the first RADIUS accounting RFC. While the speed of access
servers increasing there should arise a problem of traffic limitation. To
increase finacial mobility traffic limits should be specified by AAA server
in authorization messsages explicitly.
As an example 6 AVPs to AA-Answer message:
Input-Octets-Limit
This attribute specifies maximum number of octets to be received from user
before termination of session or prompt. If this attribute is not specified
and Input-Gigawords-Limit attribute is not specified the maximum number of
octets to be received from user is unlimited.
Output-Octets-Limit
This attribute specifies maximum number of octets to be sent to user before
termination of session or prompt. If this attribute is not specified and
Output-Gigawords-Limit attribute is not specified the maximum number of
octets to be sent to user is unlimited.
Input-Gigawords-Limit
This attribute specifies maximum number of gigawords to be received from user
before termination of session or prompt. If this attribute is not specified
the maximum number of octets to be received from user is defined by
Input-Octets-Limit attribute.
Output-Gigawords-Limit
This attribute specifies maximum number of gigawords to be sent to user
before termination of session or prompt. If this attribute is not specified
the maximum number of octets to be sent to user is defined by
Output-Octets-Limit attribute.
Input-Packets-Limit
This attribute specifies maximum number of packets to be received from user
before termination of session or prompt.
Output-Packets-Limit
This attribute specifies maximum number of packets to be sent to user before
termination of session or prompt.
And another question: will be there a dedicated Diameter application for
authenticaton, authorization and accounting of E-mail services?
--
Valery Kholodkov | Golden Line Communications Company
52 Chkalova, st | Russian Federation, Penza 440052
Issue 382: Transport-08 NITs
Submitter name: Steve Bellovin
Submitter email address: smb@research.att.com
Date first submitted: November 9, 2002
Reference:
Document: Transport-08
Comment type: E
Priority: 1
Section: 3.4.1
Rationale/Explanation of issue:
3.4.1 I'm not sure what is meant by "cyclic". PRNGs have repetition
periods; apart from that, if you seed two with the same value,
they'll stay in lock-step. I suggest that "random" be
defined as "generated by a PRNG seeded per RFC 1750".
--Steve Bellovin, http://www.research.att.com/~smb (me)
http://www.wilyhacker.com ("Firewalls" book)
Issue 383: Base-15 Review
Submitter name: Steve Bellovin
Submitter email address: smb@research.att.com
Date first submitted: November 9, 2002
Reference:
Document: Base-15
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:
In a number of places below, I'm not necessarily asking for changes to
the text. But there are some things that need justification, either
within the document or just in email to me and the IESG.
1.4 It would be good to define "user". I *think* that "user" means
"the entity requesting or using some resource, in support of which
a Diameter client has generated a request" or some such. I'm
trying to avoid confusion in discussions of authentication -- is
it the Diameter node or the resource-requesting entity that is
being authenticated?
The definition of "end-to-end security" needs to be improved.
2.1 ECONNREFUSED is a Unix errno value. Probably, OS-independent
terminology should be used.
Does "RESET call" mean "send a TCP RST bit" (or the SCTP
equivalent? Or does it mean that a connection should be
terminated without benefit of the DPR exchange?
2.1.1 How many SCTP streams should be created? May be created?
2.8.1 Use example.net and example.com? (Same in 4.5.1)
2.8.3 It is very far from clear to me that redirect agents are or should
be application-agnostic. Is routing on the contents of
application-specific fields to be disallowed? I note that
6.13 permits per-user redirection, and user names are not
in the routing table defined earlier. (I'm perfectly
happy with the answer "the WG has considered and rejected this
point".)
2.8.4 The description here makes it clear that the phrase "end-to-end
security" is not, in fact, accurate. If that transform can (or
should) be applied by an intermediate node, which is strongly
suggested by this section, it is not "end-to-end". I suspect
that something like "object security" is closer, though still
not quite right.
3 What purpose is served by the T bit? Given that the underlying
network may be duplicating packets -- a few months ago, I was
seeing up to 90% duplicates on my local loop, with no apparent
ill effects on the stack -- why is there some advantage to
trying to convey that information in Diameter? It almost makes
sense if set only when the application has switched peers before
the retranmission, though it's still not clear to me what
the receiver of such a message would do with the information.
Should the spec indicate that the reserved bits MUST be ignored
by receivers, rather than sending an error? It makes it hard to
start using those bits, given the current language. "Be liberal
in what you receive", etc.
4.1 Same comment about the reserved bits.
4.6 Why is the flag "MAY Encr" when confidentiality is mandatory?
What is the SHLD NOT column? It's never used in that table.
I don't see the reasoning for some of the settings of that
flag. For example, I would think that the authentication- and
authorization-related flags would require protection, to guard
against deletion to prevent the operation from taking place,
or to spoof the result. This also illustrates confusion between
the need for integrity protection vs. confidentiality. It
would be good to give some general guidance, for the benefit
of people defining Diameter applications.
5.2, search rule 3.2, last paragraph: Unless I'm misreading something,
it says that the domain suffixes SHOULD and need not match
the original query.
3.3 should probably be numbered 4.
Discuss DNSsec? What TLS or IPsec certificates should be
checked for? More specifically: the peer discovery mechanisms
MUST be tied to a security authorization model. Each peer to
which a node speaks must be authorized for some role. The
Diameter implementation must have some list of credentials
that are acceptable *for this role*. That point should probably
be discussed here, and possibly in the Security section as well.
(Note that suitable checking in this fashion relegates DNSsec
issues to availability, and not even much of that -- an attacker
can't impersonate a legimate peer, because it lacks the right
credentials.)
5.3 May CER or CEA messages be relayed?
5.3.1 Why is the IP address in the message, when it should be
available via the local incarnation of getpeername()?
5.6.4 What is a "hanging octet"?
6.1.8 Proxy-Info has security implications, and probably requires an
embedded HMAC with a node-local key.
8.3 The RAA message is curious, and perhaps the answer to my
question is in another AAA document. That said -- in general,
something like a NAS can't do user authentication by itself.
Instead, it's going to use Diameter facilities to send something
upstream. Ultimately, it's the Diameter server that is going to
make the decision. That suggests that reauthenticate is more
of a command from the server to the client, where the server
will, at some point, issue a disconnect message. The current
model seems to suggest a sequence of
server->client: RAR
client->server: authentication info } repeated
server->client: authentication info }
client->server: success/failure
In other words, there's a nested exchange. Is that intended?
What Session-ID should be used? Will Diameter implementations
be confused by that sort of sequence? There's a state machine
lurking in the background here, I think.
9 I'm concerned that I don't see a way for a server to detect
a total ordering of accounting records for a session. This
would be useful, for example, when processing interim records.
The situation I'm concerned about is as follows. Suppose a
client sends an interim record to a proxy or relay agent. The
upstream link from the agent is experiencing a transient
problem. Or perhaps the agent crashes and reboots, but has
stored the pending records in non-volatile storage. In the
meantime, the client sends another interim message via another
path, either because it suspects a failure or because it is
using multiple peers for load-sharing. This second record
can be received first. I suspect that the easiest solution is
to require that Accounting-Record-Number be monotonically
increasing within a session.
13 Is there some document that discusses the end-to-end (and I mean
that literally here) Diameter authorization model? I know that
it was discussed in the WG, but I don't see anything on that
here. What's I'm looking for -- somewhere -- is some discussion
on how, say, a NAS "knows" that it will be paid when an
authorization comes from five proxies away.
14 Non-ascii hyphens (which shouldn't be there anyway)
--Steve Bellovin, http://www.research.att.com/~smb (me)
http://www.wilyhacker.com ("Firewalls" book)
Issue 384: Another Base-15 Review
Submitter name: Bert Wijnen
Submitter email address: bwijnen@lucent.com
Date first submitted: November 11, 2002
Reference:
Document: Base-15
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:
I have only evaluated up to page 74 of the document, but thought I would send
this in to start with.
More or less serious
- I see (on page 11 and page 19) 3 different terms for the
same thing (or are they indeed meant to be different?). To
me it seems these all refer to the DIAMMIP document/application.
They use:
- Mobile IPv4
- MIPv4
- Mobile IP
- Is there an explanation as to how the allocations were done
in sect 2.4 ??? why jump from 1 to 4 and 5 and then to the end?
- I think SMB already mentioned it, but there are quiet a few
places where one should use example.net or example.com
instead of abc.com and mno.net
- Last sentence of sect 2.9. I think they mean RECOMMENDED
instead of recommended
- Sect 3
- In the diagram they use "Ver", in the legend below it they
use "Version"
- In the diagram they use "RPETrrrr" in the legend below they
use "Command Flags"
- I find the use of the T-flag pretty complicated.
- they specify that the reserved bits MUST be zero on sending
and that they cause an error upon receipt. I think that normally
I see that such reserved bits are ignored on receipt. If this
is intentionally, then I guess it is OK. I just wondered.
- They claim that the version field MUST be 1. I guess that it
must contain a valid version, and that at the time of this writing
there is only version 1.
- They talk about "Origin-Host" in the description of End-to-End
Identifier... but at that point I have no idea yet what "Origin-Host"
is supposed to be.
- Last para of sect 4.
"Zero bytes are added..."
Mmm... I guess that "A number of zero-valued bytes are added"
Maybe it is just me with my poor understanding of English?
- Sect 4.1 and sect 4.2
- First, I would remove the number 4.2 or otherwise renumber it to
4.1.1 It is still part of the AVP header.
- But... more importantly:
I get confused here w.r.t. the value of zero (0) for Vendor-ID.
It is not clear to me if value of zero is used ever or that instead
one always leaves out the optional Vendor-ID field if the value is
supposed to be zero.
If the latter, are they saying that the field Vendor-ID SHOULD NEVER
contain a value of zero....
As I said, I find it confusing
By the way, vendor IDs (the SMI values they are using here) cannot be
zero, cause the value zero is RESERVED, see
http://www.iana.org/assignments/enterprise-numbers
- It would be an improvement I think if they actually mentioned that
they are indeed the Enterprise-Numbers as registered by IANA
(At least that is what I understood they are meant to be). It will
make it easier to find them. the IANA registry does not talk about
Vendor-ID.
- Bullet 1) on page 37 talks about "base Diameter standard". Is that
appropriate? Should it be "base Diameter protocol" ??
- top of page 38 talks about "standard AVP". Is that appropriate?
If it is another application specific AVP, it may be a vendor specific
one and so may not be a standard AVP ??
- Section 4.4
I wonder if the use of IPAddress as a datatype may not be misleading.
MANY MANY people know this as a SNMP/SMI datatype to represent an
IPv4 address. And so I immediately jumped up and though: what about IPv6.
Turns out that they use this datatype for both IPv4 and IPv6. And one
has to figure it out based on the length.
Mmmm... is this smart? I know that we have abandoned all that in the
SMI world, and we use a discriminated union instead namely an
InetAddressType and and InetAddress.
- Section 4.4
DiameterIdentity
- This is derived from OctetString. I wonder if it should be UTF-8 based.
Are FQDNs ever gonna be internationalized in the future? If so, then
I think they should be UTF-8 based. That probably means derived from
OctetString, but having additional UTF-8 semantics as for the UTF8String.
- Now if they do give it UTF8 semantics, then sect 5.6.4, where they start
talking about comparing such strings needs work too. Ask paf all about it.
- IPFilterRule and QoSFilterRule
Are the ascii strings white space separated? Are they just one long string
without white space?
It also bothers me a bit that this is a totally different way of specifying
such filters as is done in MIBs and PIBs.... I guess such is life. People
will have to learn multiple ways of doing the same thing. Oh well.
- Page 50
I suspect that the counting for the offset went wrong. I specifically
wonder about the values 64, 68, 72. Should they possibly be 64, 72, 80 ??
- Page 52
I wonder if Error-Message should not be a UTF8String
Is such an error message never meant for Human consumption?
- Sect 5.3, first para
Mentions "security model". Of course this means something special to me
(because of teh SNMP USM security model). But this term is used here
while it has never been explained what they mean with it. WHat choices of
security models are there?
- Sect 5.3.3, last para
- This seems confusing to me. And it may cause interoperability problems,
if two or more vendors are in the same "state" of not yet having a
vendor ID assigned.
- It may also confuse people with the concept of "a zero value for Vendor-ID
is reserved for IETF standardized applications (per sect 4.2)
- And as far as I can tell, there is no need. Anyone who wants a vendor ID
(that is enterprise number) can get one within a day or two from IANA.
I don't think there are any restrictions in getting one.
- Sect 5.3.6
Do you really mean "a subset of the vendor-specific AVPs" ??
Or should it be in parentheses: "(a subset of) the vendor-specific AVPs" ??
- Sect 5.4.1. and 5.4.2.
Are the Origin-Host and Origin-Realm the same here.??
I suspect not (from later text in the document), but since the 2nd is an
answer to the first, I first thought they would be the same (or had to be
the same)... you may want to spell it out.
- Same question for 5.5.1 and 5.5.2
- Sect 5.6.4.
What are "Hanging Octets" ??
- Sect 6.1 first couple of paragraphs
What is an implementation supposed to do when a request is not conformant
to all these rules? Send an error I guess. Which error?
- Bullet 4) towards the end of page 70
and also for example sect 6.1.3
Must the E-Bit be set? I think section 7.1.3 says that it must.
But I was wondering about that at several places in the text before I
actually got to sect 7.1.3.
- section 6.1.1
bulleted list.... Are the "should" verbs not very weak? I think I would
write is as follows:
- the Command-Code is set to the appropriate value
- the R-bit is set to 1
etc...
Nits
- Missing an IPR section
- probably first AAA occurrence in abstract should be expanded
- Do we use MUST in an abstract normally
- Quite a bit of RFC2119 terms is used before it is actually
explained (in sect 1.3) that it is indeed 2119 terms
- is the first sentence of the last para of sect 1.2 really a
sentence? It sounds really weird to me.
- sect 1.2.3 acronym EAP used without expanding
- Acronyms for command-Names used before they are defined
(for example in sect 1.2.4
- Last para in sect 1.2.3 is the same as one-but-last para
in sect 1.2.4 (wel more or less)
- Sect 1.4
Accounting Record is a term they want to define, but in the
definition they seem to be talking about a session record instead?
- Sect 2.1 first sentence: s/profileis/profile is/
- Sect 2.1 1st sentence 4th para
... an attempt ... SHOULD be .. attempted
Sounds weird to me
- They are not very consistent in capitalizing things.
For example they use:
- Translation Agent and Translation agent and translation agent
- Redirect agent and redirect agent
- Proxy agent, proxies and Proxies
etc
- page 31:
s/referred to as an error messages/referred to as error messages/
- page 31 says "MUST reset this flag"... would it be better to
say "MUST clear this flag" ??
- The "(in network byte order)" seems redundant a number of times
on page 32. All fields in the header are in network byte order
according to the beginning of sect 3. I can live with it.
- page 41/42
Maybe be more consistent w.r.t. fqdn and FQDN ??
- sect 5.3.3
Speaks about a "Diameter device". Is that indeed meant? Can a vendor not
just sell a piece of "Diameter software/application" that runs on
someone else's devices, maybe on devices of multiple other vendors?
Thanks,
Bert
More on IPAddress datatype
Sent: dinsdag 12 november 2002 11:33
To: bwijnen@lucent.com
Cc: bkhabs@nc.rr.com; mwdaniele@adelphia.net;
shawn.routhier@windriver.com; randy@psg.com
Subject: Re: Question on IPAddress
Wijnen, Bert (Bert) writes:
Bert If you look at draft-ietf-aaa-diameter-15.txt, page 40, sect
Bert 4.4, then you will see that they use IPAddress to represent IPv4
Bert and IPv6 addresses.
Bert I wondered what your comments would be, given the fact that you
Bert guys took a real good look at IP (or INET) addresses when you
Bert worked on the INET-ADDRESS-MIB.
Bert For me, this use of IPAddress seems at least confusing, and it
Bert also does not seem future-proof.
I brought this issue up, probably two years ago now. The answer was
(if I recall correctly) that they do not really care about boxes at
zone boundaries and future IP address formats. I have not followed the
AAA work lately so I have no clue whether they have a union mechanism
which can be used to introduce a more generic format for addresses.
/js
-----Original Message-----
From: Brian Haberman [mailto:bkhabs@nc.rr.com]
Sent: dinsdag 12 november 2002 0:04
To: Wijnen, Bert (Bert)
Cc: Mike Daniele (E-mail); Juergen Schoenwaelder (E-mail); Shawn
Routhier (E-mail); Randy Bush (E-mail)
Subject: Re: Question on IPAddress
I agree that it is confusing. It will be broken if a new IP
address family comes along that just happens to have the same
address lengths as either v4 or v6.
Any ideas why they did not use a Type definition rather than
relying on address lengths?
Brian
Wijnen, Bert (Bert) wrote:
If you look at draft-ietf-aaa-diameter-15.txt, page 40, sect 4.4,
then you will see that they use IPAddress to represent IPv4 and
IPv6 addresses.
I wondered what your comments would be, given the fact that you
guys took a real good look at IP (or INET) addresses when you
worked on the INET-ADDRESS-MIB.
For me, this use of IPAddress seems at least confusing, and it
also does not seem future-proof.
Thanks,
Bert
Issue 385: MIP-13 NITs
Submitter name: Bert Wijnen
Submitter email address: bwijnen@lucent.com
Date first submitted: November 11, 2002
Reference:
Document: MIP-13
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:
Nits:
- document diameter-mobileip-13
- needs IPR section
- introduction 1st para:
"an Application of 4" means ???I think you mean "Application-ID" or
such, no?
- sect 9.7 referes to sect 1.7, which should be sect 1.8 I think
- [KEYWORDS] reference has been decided to be a normative reference
Issue 386: MIP-13 Security Issues
Submitter name: Steve Bellovin
Submitter email address: smb@research.att.com
Date first submitted: November 11, 2002
Reference:
Document: MIP-13
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:
1.6: What is a "preconfigured shared security association"? Do you
mean a preshared secret? A security association comprises far more
than just a key.
I have not evaluated the security of the scheme in this section, since
it depends on another draft, and possibly on the security of MobileIP
itself. Can we really even consider this draft until those are done?
1.10: What firewall rules? Are the agents supposed to tell their local
firewalls to open up some holes?
5.2: 64 bits is not sufficient for a key. Why not just mandate 128,
instead of strongly recommending it?
5: I confess that it still isn't clear to me how the home and foreign
agents know authoritatively who each other are. Then again, that's
always been my main complaint about AAA. But here they're handing out
keys.
--Steve Bellovin, http://www.research.att.com/~smb (me)
http://www.wilyhacker.com ("Firewalls" book)
Issue 387: IANA Registry
Submitter name: Michelle
Submitter email address: iana@iana.org
Date first submitted: November 11, 2002
Reference:
Document: BASE-15
Comment type: E
Priority: S
Section: 11
Rationale/Explanation of issue:
I'm getting this comment to you a little
late. This document was late night reading
for me last night.
This stuff is a bit confusing. I was wondering
if it would be possible for the authors to
include an initial registry in this document?
This would help the IANA when it comes time
to take care of the IANA actions. If that
is not possible can one of the authors assist
me in getting this registry set-up?
Suggestions?
Thanks,
Michelle
IANA
Issue 388: Diameter Peer Discovery and
Authorization
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: November 19, 2002
Reference:
Document: BASE-15
Comment type: T
Priority: S
Section: 5.2
Rationale/Explanation of issue:
While Diameter uses IPsec or TLS for transmission layer
security, successful authentication with IKE or TLS does
not imply authorization.
Therefore, with IKE it is typically necessary to manually
configure the IP address (pre-shared key) or
FQDN (certificates) of authorized NASes or AAA servers.
This means that Diameter Peer discovery, even if
secured, must be careful to make sure that the
discovered Diameter peers are actually authorized
for their roles. This is particularly important
when DNS is used for discovery, because the
use of DNSSEC does not imply authorization.
For example, a host could exist that had a TLS server
certificate (for web use), and secured DNS
RRs, but was *not* authorized to act as a Diameter
server.
Similarly, with SLPv2, security SHOULD be used,
both to validate the integrity of the advertisements
as well as to determine authorization to act as a
Diameter Peer.
Change:
"It is recommended that SLPv2 security
be deployed (this requires distributing keys to SLPv2 agents).
This is discussed further in Appendix A."
To:
"SLPv2 security SHOULD be used (requiring distribution of
keys to SLPv2 agents) in order to ensure that discovered
peers are authorized for their roles. SLPv2 is discussed
further in Appendix A."
Change:
"If the server is using a site certificate, the domain name in
the query and the domain name in the replacement field MUST
both be valid based on the site certificate handed out by the
server in the TLS exchange. Similarly, the domain name in the
SRV query and the domain name in the target in the SRV record
MUST both be valid based on the same site certificate.
Otherwise, an attacker could modify the DNS records to contain
replacement values in a different domain, and the client could
not validate that this was the desired behavior, or the result
of an attack."
To:
"If the server is using a site certificate, the domain name in
the query and the domain name in the replacement field MUST
both be valid based onthe the site certificate handed out by the
server in the TLS or IKE exchange. Similarly, the domain name in the
SRV query and the domain name in the target in the SRV record
MUST both be valid based on the same site certificate.
Otherwise, an attacker could modify the DNS records to contain
replacement values in a different domain, and the client could
not validate that this was the desired behavior, or the result
of an attack.
Also, the Diameter Peer MUST check to make sure that the discovered
peers are authorized to act in its role. Authentication via IKE
or TLS, or validation of DNS RRs via DNSSEC is not sufficient
to conclude this. For example, a web server may have obtained a
valid TLS certificate, and secured RRs may be included in the
DNS, but this does not imply that it is authorized to act as
a Diameter Server.
Authorization can be achieved for example, by configuration of a
Diameter Server CA. Alternatively this can be achieved by
definition of OIDs within TLS or IKE certificates so as to
signify Diameter Server authorization."
Issue 389: NASREQ Nits
Submitter name: Jari Arkko
Submitter email address: jari.arkko@piuha.net
Date first submitted: December 12, 2002
Reference:
Document: NASEREQ-10
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:
Here's a few comments:
- Title and abstract contain abbreviations. Consider
changing this to avoid complaints from the RFC editor.
How valid is "NASREQ" for the name of a protocol anyway?
How about "Diameter Application for Network Access Servers"?
(But this could affect base too, but perhaps it can be
done in authors 48 hours.)
Expand AAA in abstract.
- " ... satisfies NAS-related requirements defined in RFC 2989 [AAACRIT]."
=> " ... satisfies typical requirements for in the network access
domain" and then you can refer to the requirements in the intro.
- "Given that it is expected that initial deployments of the Diameter
protocol will include legacy systems. This application was ..." =>
"Initial deployments of the Diameter protocol are expected include
legacy systems. Therefore, this application was..."
- Contents indentation could be prettier, e.g not change when
the section numbers go from 9 to 10.
- Consider including only top 2..3 levels in the contents
list and making a separate List of AVP Definitions page
to follow the contents page, with each AVP definition section
listed in alphabetical order.
- Shorten the title of 6.4 to "AVPs that can be Translated"
and 6.3 to "Prohibited Attributes".
- In abstract, "re-using the RADIUS attribute space"... I
wonder if we reuse the SPACE or the ATTRIBUTES. It seems
to me that its the latter, we have a new Diameter space
for new attributes. THe reader might be confused to think
the radius avp space limitations apply here too.
- Reference [EAP] appears no longer necessary.
- Why are RADIUS references informative? We speak
of RADIUS attrs in the document and the reference
is still not normative?!
- Reference identities might be better aligned, e.g.
RADTunnels, and RADTUNNLACCT.
- Is the 8.3 reference to IANAConsid correct? IANA holds
the namespace but isn't it the Diameter base that defines
the namespace?
- Add to section 9 the following: "The security considerations
of the Diameter protocol itself have been discussed in
[DiamBASE].".
- Section 8 should contain some statement about the IANA
allocation policies of RADIUS attr enumerated values.
Reference some document(s)?
- In section 5 at the text "Authentication or Authorization
transaction or the end of a Session.": Isn't the last "or"
really an and? I mean you want ACRs on both, right?
- Also, are the ACRs sent on both auth and authz events if
they are done separately? Perhaps you should break this
text into a set of individual normative requirements.
Please make sure you say how many messages are sent if
authz and auth both happen in the same AA request.
- In 4.3.11 there's a missing space (?) in
"proprietarySingleLink/MultiLink"
- There's a concatenation procedure mentioned in 6.4. Could
we say explicitly for which attributes it can be
done?
- Missing newline after the title of section 7.
- Having the 7.1 table start on a new page is useless
because it will not fit a single page anyway.
- In 8.2. "This specification assigns the values 363-366 and
400-414 from the". I'm not sure I understand the 400-414
because only 400, 403, and 409-412 can be found from the
nasreq document.
Issue 390: Path Authorization Issues
Submitter name: Steve Bellovin
Submitter email address: smb@research.att.com
Date first submitted: November 18, 2002
Reference:
Document: BASE-15
Comment type: T
Priority: S
Section: 2.10 (new section)
Rationale/Explanation of issue:
The Base document does not explain how "willingness to pay" is
determined. This is another aspect of authorization that needs
to be clarified.
Some nits:
Correction (section 6.2)
Change:
"Note that the error messages (see section 7.2)"
To:
"Note that the error messages (see section 7.3)"
[Bernard Aboba] -- Here is some potential text:
2.10 Diameter Path Authorization
As noted in Section 2.2, Diameter requires transmission level
security to be used on each connection (TLS or IPsec). Therefore,
each connection is authenticated, replay and integrity protected
and confidential on a per-packet basis.
In addition to authenticating each connection, each connection
as well as the entire session MUST also be authorized. Before
initiating a connection, a Diameter Peer MUST check
that its peers are authorized to act in their roles. For
example, a Diameter peer may be authentic, but that does not
mean that it is authorized to act as a Diameter Server advertising
a set of Diameter applications.
Prior to bringing up a connection, authorization checks are
performed at each connection along the path. Diameter capabilities
negotiation (CER/CEA) also MUST be carried out, in order to determine
what Diameter applications are supported by each peer. Diameter
sessions MUST be routed only through authorized nodes that have
advertised support for the Diameter application required by the
session.
As noted in Section 6.1.8, a relay or proxy agent MUST append a
Route-Record AVP to all requests forwarded. The AVP contains the
identity of the peer the request was received from.
The home Diameter server, prior to authorizing a session, MUST check
the Route-Record AVPs to make sure that the route traversed by
the request is acceptable. For example, administrators within the
home realm may not wish to honor requests that have been routed
through an untrusted realm. By authorizing a request, the home
Diameter server is implicitly indicating its willingness to be
financially responsible for the costs associated with the session,
which are detailed in subsequent accounting request messages.
A DIAMETER_AUTHORIZATION_REJECTED error message
(see Section 7.1.5) is sent if the route traversed by the
request is unacceptable.
A home realm may also wish to check that each accounting
request message corresponds to a Diameter response authorizing
the session. Accounting requests without corresponding
authorization responses SHOULD be subjected to further scrutiny,
as should accounting requests indicating a difference between
the requested and provided service.
Similarly, the local Diameter agent, on receiving a Diameter response
authorizing a session, MUST check the Route-Record AVPs to make sure
that the route traversed by the response is acceptable. At each
step, forwarding of an authorization response is considered evidence
of a willingness to take on financial risk relative to the session.
A local realm may wish to limit this exposure, for example, by
establishing credit limits for intermediate realms and refusing
to accept responses which would violate those limits. By issuing
an accounting request corresponding to the authorization response,
the local realm implicitly indicates its agreement to provide the
service indicated in the authorization response. If the service
cannot be provided by the local realm, then a DIAMETER_UNABLE_TO_COMPLY
error message MUST be sent within the accounting request; a Diameter
client receiving an authorization response for a service that it
cannot perform MUST NOT substitute an alternate service, and then
send accounting requests for the alternate service instead.
[Discussion w/Jari Arkko on the above:]
Date: Sun, 8 Dec 2002 17:24:15 -0800 (PST)
From: Bernard Aboba <aboba@internaut.com>
To: Jari Arkko <jari.arkko@kolumbus.fi>
Cc: john.loughney@nokia.com, aaa-editors@internaut.com
Subject: Re: [aaa-editors] Updated Diameter Base, preview
> Just checking: we allow CER/CEA to return application Foo even
> if we don't authorize the peer to do Foo?
CER/CEA is defined to carry capabilities -- and this exchange can occur
prior to a TLS upgrade, so that the identity of the peers may not be known
at that time. So I think the answer is "yes" -- Foo is returned even if
the peer may not be authorized to do Foo.
>
> > As noted in Section 6.1.8, a relay or proxy agent MUST append a
> > Route-Record AVP to all requests forwarded. The AVP contains the
> > identity of the peer the request was received from.
>
> Hmm... are we checking the authorization at the other end based on
> these AVPs? I'm not so sure how easy it is for ISP A to know if
> ISP B who is samed by the same roaming concortium, is a trustworthy
> entity, let alone know what proxies B has.
In general, the transitive trust will be enough... but ISP B may have
gotten on a blacklist somehow (e.g. in Chapter 11 bankruptcy) and so ISP A
may wish to limit financial exposure or otherwise not deal with ISP B.
> > The home Diameter server, prior to authorizing a session, MUST check
> > the Route-Record AVPs to make sure that the route traversed by
>
> And Origin-Host AVP?
Sure.
> > the request is acceptable. For example, administrators within the
> > home realm may not wish to honor requests that have been routed
>
> Hmm.. uh oh this appears to be what I was asking about above.
> Shouldn't we base the authorization here on the transitive trust
> in the network and maybe an optional possibility to inspect
> RR AVPs?
Yes. This is more or less what Kerberos does.
> > through an untrusted realm. By authorizing a request, the home
> > Diameter server is implicitly indicating its willingness to be
> > financially responsible for the costs associated with the session,
>
> Can we soften this? Willingness to engage in the business transaction
> as specified by the contractual relationship between the server and
> the previous hop?
That's fine.
> I need to go and check my diameter server doesn't any open holes...
>
> > which are detailed in subsequent accounting request messages.
> > A DIAMETER_AUTHORIZATION_REJECTED error message
> > (see Section 7.1.5) is sent if the route traversed by the
> > request is unacceptable.
>
> Ok.
>
> > A home realm may also wish to check that each accounting
> > request message corresponds to a Diameter response authorizing
> > the session. Accounting requests without corresponding
> > authorization responses SHOULD be subjected to further scrutiny,
> > as should accounting requests indicating a difference between
> > the requested and provided service.
>
> Ok.
>
> > Similarly, the local Diameter agent, on receiving a Diameter response
> > authorizing a session, MUST check the Route-Record AVPs to make sure
> > that the route traversed by the response is acceptable. At each
> > step, forwarding of an authorization response is considered evidence
> > of a willingness to take on financial risk relative to the session.
Change "take on financial risk" to "engage in the business relationship"?
> > A local realm may wish to limit this exposure, for example, by
> > establishing credit limits for intermediate realms and refusing
> > to accept responses which would violate those limits. By issuing
> > an accounting request corresponding to the authorization response,
> > the local realm implicitly indicates its agreement to provide the
> > service indicated in the authorization response. If the service
> > cannot be provided by the local realm, then a DIAMETER_UNABLE_TO_COMPLY
> > error message MUST be sent within the accounting request; a Diameter
> > client receiving an authorization response for a service that it
> > cannot perform MUST NOT substitute an alternate service, and then
> > send accounting requests for the alternate service instead.
>
> Ok, but the above comments apply here too in part.
It wasn't entirely apparent what the appropriate error message is
in the case where the NAS receives a Response that is unacceptable in
some way (e.g. RR AVPs are unacceptable, service can't be implemented,
etc.). The accounting request is the only message in which the problem
can be indicated since there is no response to an authentication response.
In the process of reading through the error messages it also is not all
that clear which messages can be sent during authentication
request/reponse, accounting request/response, etc.
Issue 391: Base State Machine
Submitter name: Dilip Patel
Submitter email address: dilris@yahoo.com
Date first submitted: December 13, 2002
Reference:
Document: BASE-15
Comment type: T
Priority: 2
Section: 5.6
Explanation of issue:
In the peer state machine.
for the peer state Wait-Conn-Ack/Elect
The event for which the peer is waiting is an ACK or
NACK from the transport layer for the Intiator
connection (I).
In this senario a Timeout Event occuring would imply
that the ACK/NACK event didint occur in the set time
period.
The current State machine requires that in this case
action to be taken is Error and next state moved is
Closed.
The Issue is that the Responder (R) Connection has
already been established with the peer which is
waiting to receive a CEA on R connection.
With the current state machine There will be no CEA
send and that would result in a Timeout on the peers
end (peers state on the other host). And thus closing
of this R connection also.
SUGESTION:
----------
If instead of taking a Error action and making the
next state as CLOSED.
The state machine could treat the Timeout as same as a
I-Rcv-Conn-Nack and thus taking action R-Snd-CEA
changing the next state to R-Open.
This would establish an connection between the 2 peers
immediately instead of waiting another few seconds
before the 2 peers try establishing a connection
again.
Requested change:
----------------
State machine change from:
state event action next state
--------------------------------------------------------
Wait-Conn-Ack/ Timeout Error Closed
Elect
State Machine change TO:
state event action next state
--------------------------------------------------------
Wait-Conn-Ack/ Timeout R-Snd-CEA R-Open
Elect
Regards
Dilip Patel
Date: Mon, 16 Dec 2002 11:18:39 +0200
From: john.loughney@nokia.com
To: aboba@internaut.com, dilris@yahoo.com
Cc: aaa-wg@merit.edu
Subject: RE: [AAA-WG]: Suggestion to modify State Machine in base document
Hi Dilip,
As the original text doesn't seem to cause any interoperability
problems right now, I am not so comfortable with the suggested
change. We've already long past IETF Last Call, so I think we
should constrain ourselves to fixing interoperability bugs.
Anyone else have an opinion?
John
Issue 392: Ambiguity in Session-Id Description
Submitter name: Ghadiyaram Venkata Kishore
Submitter email address: Ext-Venkata.Ghadiyaram@nokia.com
Date first submitted: 13 December, 2002
Reference:
Document: Base-15
Comment type: T
Priority: S
Section: 8.8
Rationale/Explanation of issue:
Section 8.8 describing the Session-Id AVP is ambiguous about the mandatory
part and the
optional part of the Session-Id. From the description it is possible to have a
Session-Id
of the form <DiameterIdentity>[unique optional value>] where there is no
delimiter
between the DiameterIdentity and the remaining portion of the Session-Id. So it
is not
possible to validate the correctness of the Session-Id. It may not also be
possible to
specify a delimiter as the DiameterIdentity is of type UTF8String.
Is there a necessity for the mandatory part of the Session-Id. Why should it be
mandatory
that the Session-Id should start with DiameterIdentity. The whole Session-Id
could be
implementation dependant and the implementation should ensure the uniqueness.
Requested Change :
In section 8.8 remove the lines
" The Session-Id includes a mandatory portion and an implementation-defined
portion;"
and
" The Session-Id MUST begin with the sender's identity encoded in the
DiameterIdentity
type (see section 4.4)."
Issue 393: MIP-13 Nits
Submitter name: Kuntal Chowdhury
Submitter email address: chowdury@nortelnetworks.com
Date first submitted: November 27, 2002
Reference:
Document: MIP-13
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:
Section 1.4:
In the event that the mobile node with AAA NAI extension
support
[AAANAI] has been previously authorized by the AAAH and now
needs to
be re-authenticated, and requests to keep the assigned home
agent in
the foreign network, the mobile node MUST include the HA NAI
and the
AAAH NAI in the registration request to the FA. Upon receipt,
the FA
will create the AMR including the MIP-Home-Agent-Address AVP,
the <