Issue 101: Editorial changes concerning
Destination-Host
Submitter name: Guenter Schaefer
Submitter email
address: schaefer@ee.tu-berlin.de
Date first submitted: July 26, 2001
Reference: http://www.merit.edu/mail.archives/aaa-wg/msg01631.html
http://www.merit.edu/mail.archives/aaa-wg/msg01591.html
Document:
Diameter Base Specification (I) and
Mobile IPv4 Application (II)
Comment
type: ?
Priority: ?
Section: 6.6, 6.2, 5.3.2, 5.4.2, 5.5.2 in (I), 2.2,
2.4 in (II)
1.4, 2.1, 4.0. 4.5, 4.6, 8.1, 8.2 in (II)
Rationale/Explanation of issue:
- There is an inconsistency
regarding the Destination-Host AVP
in the Diameter base protocol (I) and the
Mobile IPv4
application (II)
("draft-ietf-aaa-diameter-07.txt",
"draft-ietf-aaa-diameter-mobileip-07.txt").
Sections 6.2 and 6.6 of the
base protocol specify that the
Destination Host AVP MUST NOT be present in
answer messages.
However, the base protocol requires this AVP in the DPA
and DWA
messages and lists it as optional for the CEA message.
The
Mobile IPv4 application requires this AVP in the AMA and HAA
messages.
[sections 6.6, 6.2 5.4.2, 5.5.2, 5.3.2 in (I),
2.2, 2.4, in (II)]
- The Mobile IPv4 application still mentions the AVPs
MIP-Previous-FA-Host and MIP-Previous-FA-Addr
even though fast handoff
support has been postponed
for further study.
[sections 1.4, 2.1, 4.0.
4.5, 4.6, 8.1, 8.2 in (II)]
Requested change:
1. EITHER change
section 6.6 in the diameter base specification to
"6.6 Destination-Host
AVP
The Destination-Host AVP (AVP Code 293) is of type
DiameterIdentity. This AVP MUST be present in all unsolicited
agent
initiated messages, MAY be present in request messages,
and MAY be present
in Answer messages."
and change section 6.2 in the base specification
accordingly,
OR
delete the Destination-Host AVP from
- the
DPA, DWA and CEA messages in the base specification
[sections 5.4.2, 5.5.2,
5.3.2 in (I)]
- the AMA and HAA messages in the Mobile IPv4 application
[sections 2.2, 2.4 in (II)]
2. In the Mobile IPv4 application all
paragraphs concerning
the AVPs MIP-Previous-FA-Host and MIP-Previous-FA-Addr
should be deleted in order to reflect postponing of
fast handoff support
for further study.
[sections 1.4, 2.1, 4.0. 4.5, 4.6, 8.1, 8.2 in (II)]
Issue 102: More description on Session state
machine
Submitter name: Yiwen Jiang
Submitter email address:
Yiwen.Jiang@tic.siemens.ca
Date first submitted: July 27th, 2001
Reference: N/A
Document: base
Comment type: E
Priority: 1
Section: 8.1 and 8.2
Rationale/Explanation of issue:
In Section
8.1 and 8.2, there is only a description of the Authentication
state machine
without any explaination on what the states actually means. In
addition, the
last line of the state machine, "New State" was not specified.
Requested
change:
Some text should be added in describing the individual states
mentioned,
similar to the sections after the peer state machine.
Issue 103: Inconsistencies in AVP types used
throughout base spec
Submitter name: Dave Frascone
Submitter email
address: dave@frascone.com
Date first submitted: July 27th, 2001
Reference: N/A
Document: base
Comment type: E
Priority: 1
Section:
Rationale/Explanation of issue:
In section 4.6 of the
base protocol draft, there is a table of all base
protocol AVPs. Most AVPs
are only mentioned with their Base types (with
the exception of a few
IPAddress's). But, further on when the AVPs are
described in detail, they
mention their derived types. (i.e. section 5.3.7
Product-Id is called a
UTF8String)
And finally, should Vendor-Id be considered Enumerated? In
the Ethereal
packet dissector, I've switched it to enumerated, so it can
attempt to
look up the vendor-id in it's VERY limited table.
Requested change:
Update the table in Section 4.6: (I
*think* I found them all)
Accounting-Record-Number should be Unsigned32
Acct-Application-Id should be Unsigned32
Alternate-Peer should be
DiameterIdentity
Auth-Application-Id should be Unsigned32
Destination-Host should be DiameterIdentity
Destination-Realm should be
UTF8String
Error-Message should be UTF8String
Error-Reporting-Host
should be DiameterIdentity
Origin-Host should be DiameterIdentity
Origin-Realm should be UTF8String
Product-Name should be UTF8String
Proxy-Host should be DiameterIdentity
Redirect-Host should be
DiameterIdentity
Route-Record should be DiameterIdentity
Session-Id
should be UTF8String
Source-Route should be DiameterIdentity
Also,
since it seems like things are in alphabetical order,
Session-Binding should
come before Session-Id
Issue 104: clarification on difference between
session and peer connection
Submitter name: Jacques Caron, Yiwen Jiang
Submitter email address: Yiwen.Jiang@tic.siemens.ca
Date first
submitted: July 27th, 2001
Reference: N/A
Document: base
Comment
type: E
Priority: 1
Section:
Rationale/Explanation of issue:
The relationship between peer-to-peer connection vs. user session was
not
specified in the base protocol.
Requested change:
(Below is
my first attempt at modifying the initial email that Pat sent out
to clairfy
such. Maybe we can added in section 8.0.)
While peer-to-peer connections
is a transport level connection, a user
session is a logical concept at the
application level. It exists over one or
many peer-to-peer connections.
+--------+ +-------+ +--------+
| Client | | Relay | | Server |
+--------+ +-------+ +--------+
<----------> <---------->
peer connection A peer connection B
<------------------------------>
User session x
In the
above example, peer connection A is established between the Client
and its
local Relay. Peer connection B is established between the Relay and
the
Server. User session x spans from the Client via the Relay to the
Server.
Each "user" of a service causes an auth request to be sent, with a
unique
session identifier. Once accepted by the server, both the client and
the
server are aware of the session. Because of this behaviour, all Diameter
clients will need to first initiate a peer-to-peer connection before it can
issue user requests to its immediate Diameter peer. All user sessions are
"multiplexed" through a single connection.
Issue 105: More editorial comments
Submitter name: Fredrik Johansson
Submitter email address:
fredrik@ipunplugged.com
Date first submitted: July 30th, 2001
Reference:
N/A
Document: base
Comment type: E
Priority: 1
Section:
Rationale/Explanation of issue:
Some of these comments may be
duplicates of earlier posted issues, I've
tried to find them but might have
missed a few.
Section 1.1 Last sentence
"An example of an
unsolicited message would be for a request that the client
issues an
accounting update"
If I'm not misstaken that feature was removed, if so, use
another example
e.g. "... for a request that the client re-authenticate"
Section 1.3
Reference in the NAI should be 8 instead of 3.
Section 2.1
3rd paragraph, replies MAY any -> replies MAY be any
Section 2.3.2
"Note that new AVPS to be used with an existing
application MUST NOT
be defined to have the 'M'andatory bit set."
is
contradictory with section 2.4
"An implementation MAY add arbitrary AVPs to
any command defined in an
application, including vendor-specific AVPs.
However, implementations
that add such AVPs with the Mandatory 'M' bit set
are not compliant,
and are at fault if the peer rejects the request."
remove sentence in 2.3.2
Section 2.6
- Status. This is the
state of the peer entry, and MUST match one
of the values listed in section
5.6.
Do you mean the values in 5.5.3?
Section 3.0
E(error) -
If set, the message contains a protocol error
Just a protocol error, why
not any error?
Section 4.4
"If no rule matches, the packet is
dropped if the last rule evaluated was a permit, and passed if
the last
rule was a deny."
To me it seems a bit strange that what to do with the
packet should be
determined by the last rule evaluated even if it doesn't
match that rule.
Even more strange when you decide to pass the packet based
on the fact that
the last rule was a deny even if it didn't match.
But that might be the correct behavior for ipf, just wanted to point
this
out to see if someone who perhaps knows more about this reacts to it.
Section 4.5
"All AVPs included in a Grouped AVP Every Grouped AVP
defined MUST
include a corresponding grammar, using ABNF [31] (with
modifications), as defined below."
Strange sentence.
Section
6.1.4
"A request is known to be for local consumption when one of the
following conditions occur:
- The Destination-Host AVP contains the
local host's identity,
- The Destination-Host AVP is not present, the
Destination-Realm
AVP contains a realm the server is configured to process
locally, and the Diameter application is locally supported, or
- The
Destination-Realm AVP is not present."
If the Destination-Host AVP
contains a non local host identity and the
Destination-Realm AVP is missing
this will evaluate to be a request for
local consumption. But on the other
hand, a request with a Destiantion-Host
AVP and without a Destination-Realm
AVP is considered wrong, right?!?
Section 6.3
Might want to clearify
that the route records removed must be saved with the
pending request so
that they can be restored when answering.
Section 7.0
"Figure 8
provides an example of a Diameter message that caused an
application error.
When application errors occur, the Diameter entity
reporting the error
clears the 'R' bit in the Command Flags, and adds
the Result-Code AVP with
the proper value. Application errors do not
require any proxy or relay agent
involvement, and therefore the
message would be forwarded back to the
originator of the request.
Should one realy return the whole request but
with the 'R'-bit cleared and a
result code AVP? Why not have the same abnf
for all errors, the request that
caused the error is stored as pending
anyway. Set the 'E'-bit and return the
abnf specified in section 7.2.
Section 7.2.
{Destination-Host AVP}
if I'm not
misstaken, this avp should never be present in any answers.
Section 8.4
"
When a user session that required Diameter authorization terminates,
the access device that provided the service MUST issue a Session-
Termination- Request (STR) message to the Diameter server that
authorized the service, to notify it that the session is no longer
active. An STR MUST be issued when a user session terminates for any
reason, including user logoff, expiration of Session-Timeout,
administrative action, termination upon receipt of an Abort-Session-
Request (see below), orderly shutdown of the access device, etc."
add something like: "unless an Auth-Session-State AVP was received set
to
'NO_STATE_MAINTAINED'."
Section 8.9
Authorization Lifetime is
of type Unsigned32, i.e. it can never become a
negative number remove the
(-1) or change the number.
Section 8.11
It's not clear that it's the
answer from the server that should be applied,
even if it's stated in
section 8.0
Section 10.1
Could you send a Class AVP in a DWR?
it's marked as 0+ in the table.
Can't all answers have a Failed AVP?
Issue 106: More changes to table in section
4.6
Submitter name: Dave Frascone
Submitter email address:
dave@frascone.com
Date first submitted: 31-JUL-2001
Reference:
Document: Base
Comment type: E
Priority: 1
Section: 4.6
Rationale/Explanation of issue:
Ok, I think this is the last of my
complaints about Section 4.6 :)
I think all AVPS should have all flags
defined in the table. For example,
since Acct-Application-Id no long has a P
bit in the "may" column, should we
assume that it is a "must-not" now? I
think the ambiguity needs to be cleaned
up and all three bits need to be
present under a colum for all AVPs
Requested change:
Include all
three bits under a column in the table.
Issue 107: More editorial comments
Submitter name: Tony Johansson
Submitter email address:
tony.johansson@ericsson.com
Date first submitted: July 31th, 2001
Reference: N/A
Document: base
Comment type: E
Priority: 2
Section:
Rationale/Explanation of issue:
Page 12, section 2.0,
2nd paragraph:
“The CMS Diameter security application [11]…” should be The
Diameter CMS
security application [11]….”
Page 16, section 2.5:
"The following Application Identifier values are defined:
NASREQ 1
[7]
End-to-End Security 2 [11]
Mobile-IP 4 [10]
Relay 0xffffffff"
For consistency the End-to-End Security should be changed to CMS
security.
Page 12, section 2.0, 2nd paragraph:
The two bullets
say almost the same thing. So what about deleting the
first sentence in
bullet 1 and start with “1. A set of AVPs are defined
to sign and encrypt
AVPs…” and keep bullet 2 as is.
Page 68, section 6.2.2, 3rd and 4th
paragraph:
“If the agent receives an answer message with a Result-Code AVP
indicating success, and it wishes to modify the AVP to indicate an
error, it MUST issue an STR on behalf of the access device. The agent
MUST then send the answer to the host which it received the original
request from.”
The above paragraph needs to better clarify what the
relay/proxy agent
sends back to the access device.
Suggested change:
“If the agent receives an answer message with a Result-Code AVP
indicating success, and it wishes to modify the AVP to indicate an
error, it MUST issue an STR on behalf of the access device. The agent
MUST then send the answer to the access device with the modified
Result-Code AVP indicating the error and MUST also add the
Error-Reporting-Host AVP, which will contain the identity of this
agent.”
Page 78, section 7.1.5,4th paragraph from the bottom:
”DIAMETER_NO_COMMON_APPLICATION 5012
This error is returned when a CEA
message…” should be “This error
is returned when a CER message…”
Issue 108: Errata in Mobile-IP Application
Submitter name: Dave Frascone
Submitter email address: dave@frascone.com
Date first submitted: 31-JUL-2001
Reference:
Document: Mobile-Ip
Comment type: E
Priority: 1
Section: 4.0, Throughout
Rationale/Explanation of issue:
Editorial erratta.
Requested
change:
In Section 4.0:
MIP-Filter-Rule type should be
IPFilterRule.
MIP-Foreign-Agent-Host type should be DiameterIdentity.
MIP-Previous-FA-Host type should be DiameterIdentity.
Throughout:
There is no "FilterRule" type. It should be "IPFilterRule"
Issue 109: Request for a new AVP called
Missing-AVP
Submitter name: Tony Johansson
Submitter email address:
tony.johansson@ericsson.com
Date first submitted: July 31th, 2001
Reference: N/A
Document: base
Comment type: T
Priority: 2
Section: 7.1.5
Rationale/Explanation of issue:
Page 77, section
7.1.5:
” DIAMETER_MISSING_AVP 5006
The request did not contain an AVP
that is required by the
Command Code definition. If this value is sent in
the Result-
Code AVP, a Failed-AVP AVP SHOULD be included in the message.
The Failed-AVP AVP MUST contain an example of the missing AVP”
To
reduce the amount of processing in the event of a missing AVP it
would be
better not have to create the "missing AVP" and add it in a
Failed-AVP. A
simpler approach would be to define a new AVP called
Missing–AVP, which just
includes the AVP code of the missing AVP.
Requested change:
7.6
Missing-AVP AVP
The Missing-AVP (AVP Code XXX) is of type unsigned32 and
contains the
AVP code of the missing AVP. This AVP MUST be added in an
answer where
the Result Code-AVP is set to DIAMETER_MISSING_AVP. There could
be
multiple Missing-AVP AVPs added in an answer, in cases where more than
one AVP is missing.
Issue 110: MIPv4 comments
Submitter name:
Fredrik Johansson
Submitter email address: Fredrik@ipunplugged.com
Date
first submitted: Aug 1th, 2001
Reference: N/A
Document:
draft-ietf-aaa-diameter-mobileip-07.txt
Comment type: E
Priority: S
Section:
Rationale/Explanation of issue:
Section 1.4
"Figure
7 shows the message flows for a Mobile Node requesting to keep
the Home
Agent assigned in Foreign network 1 when it moves to foreign
network 2. Upon
reception of the AMR in Foreign network 2, the AAAF
follows the procedures
described earlier and forwards AMR to the
Mobile Node's home network, i.e.
its AAAH. If the Mobile Node was
successfully authenticated the AAAH checks
for the Origin-Host and
the MIP-Previous-FA-Host AVPs. If a AAAH deduces
that the Mobile Node
has moved to a new domain, it must check whether the
Mobile can still
use the previously assigned Home Agent."
The
MIP-Previous-FA-Hoast AVP doesn't exist anymore. Remove it and perhaps
indicate that in order to determine if a mobile has moved the Origin-Host
need to be compared to the Origin-Host received in the previous request
(AMR). Or even better, it will look for the Origin-Realm AVP and compare it
to the Origin-Realm AVP received in the previous request to determine if the
Mobile Node has moved to a new domain.
Section 2.1
"If the
MIP-Previous-FA-Host AVP is found in the request, the Diameter
client
requests that the server return the registration key that was
assigned to
the previous Foreign Agent for use with the Mobile Node
and Home Agent. The
registration key is identified through the use of
the User-Name AVP."
Remove the whole paragraph, and also the MIP-Previous-XXXX AVPs from the
abnf code.
Section 2.2 and 2.4
Remove the Destination-Host AVP
from the abnf
Section 4.0
Remove the MIP-Previous-XXXX AVPs from the
table
Section 5.0
"AAA support for key distribution departs
slightly from the existing
SPI usage, as described in [4]. The SPI values
are used as key
identifiers, meaning that each registration 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
[15], while the Home Agent allocates the Mobile-Foreign,
Mobile-Home and
Foreign-Home SPIs."
Does the SPI usage really depart from the one used
in mobile ip?
Section 6.5
Is the MIP-Replay-Mode really needed
between the Mn and the FA?
Section 6.x
Do we need to change this
chapter to not refer to Session Key but to the Key
Material that is used
instead?
Section 8.1
The Destination-Host should have 0 on AMA and
HAA in the table.
remove MIP-Previous-FA-XXXX from the table
Issue 111: More editorial comments on base-07
Submitter name: Lucius Schmid
Submitter email address:
lucius.schmid@innovation.siemens.ca
Date first submitted: Aug. 1. 2001
Reference: N/A
Document: base
Comment type: E
Priority: 1
Section: 5.6
Rationale/Explanation of issue:
Hi,
since
there are Disconnect-Peer-x (DPR/DPA) commands codes I suggested to
change
the event name "Peer-Disc" to "Rcv-DPR" and the action name
from "Disc" to
"Snd-DPA".
Requested change:
pages 58/59, section 5.6: the peer
state machine table
replace all "x-Peer-Disc" with "x-Rcv-DPR" and "x-Disc"
with "x-Snd-DPA"
page 60, section 5.6.2: Events
replace "Peer-Disc"
with "Rcv-DPR" (explanation remains)
page 61, section 5.6.3: Actions
replace "Disc" with "Snd-DPA" (explanation remains)
Issue 112: More editorial comments on base-07
Submitter name: Jacques Caron
Submitter email address:
jacques_m_caron@yahoo.com
Date first submitted: August 3, 2001
Reference:
Document: Base-07
Comment type: E
Priority: 1
Section: throughout
Rationale/Explanation of issue:
In 5.3.1:
- 1st paragraph, "...is sent to inform a peer that a reboot has occurred".
I think it's just sent whenever a connection is established, and is not
linked to reboots in any way (other than reboots imply a new connection,
but not the opposite). Might be handy to know a device has rebooted, though
(by including uptime in the CER/CEA messages for instance).
In
5.3.2:
- 1st paragraph, "The Capabilities-Exchange-Request (CEA)" -> "The
Capabilities-Exchange-Answer (CEA)" :-)
In 5.4:
- 1st paragraph,
"...disconnects one *of* its transport connections..."
In 5.5.3:
-
Status, "the level of confidence in the algorithm". Needs some rewording :-)
- Pending, "This boolean field is set to TRUE when there are no outstanding
unanswered requests". For logic's sake, it should be FALSE when there
aren't any, and TRUE when there are (and modify the rest accordingly --
actually, I think the rest actually thinks pending is true when there are
outstanding unanswered requests...)
- OnReceiveDWA, not sure the "if
pcb->status = WAIT_DWA OR pcb->Status =
SUSPECT" is actually needed?
It should happen also if status is OK. Also
note the capitalization of
status is not constant.
- OnTimerElapsed, a "T = Tw" is missing in the OK
block after the
SendWatchdog(pcb)
In 5.5.4:
- 2nd paragraph,
"The Hop-by-Hop Identifier field MAY be used to match the
answer with the
queued request". Errr, I don't see any other way?
- 3rd paragraph, "it is
not possible for forward" -> "it is not possible
*to* forward".
- 4th
paragraph, "request or answer" -> "requests or answers"
In 5.6:
-
2nd paragraph, "...a connection is initiated *from* MUST NOT be the port..."
- in the state machine, I still think that (a) two state machines, one for
receiving, one for initiating, would be a lot simpler -- the only place
where they have anything in common is the election after receiving a CEA or
CER, respectively; (b) the "R-Conn-CER" event is a bit too much of a
shortcut since it actually involves multiple sub-events and states.
In 5.6.1:
- 1st paragraph, "This is because the identity of a
Diameter peer is
determined by host and port; and the source port of an
incoming connection
is arbitrary" -> "This is because the identity of a
Diameter peer is
determined by a specific protocol, transport, host and port
the peer is
listening on; and the protocol, transport, source address and
source port
of an incoming connection are arbitrary."
- 4th paragraph,
"the state machine below" -> "the state machine above".
In 5.6 &
5.6.3:
- the state machine states that if a connection is received
(R-Conn-CER)
once in Open state, then the new connection is rejected, i.e.
disconnected.
A CEA MUST be sent before the connection is disconnected. This
is to make
sure that if host A and B already talk to each other, and A finds
out it
needs to talk to host C (DNS, SLP, Redirect-Host...), which is
actually
another URI for host B, then A must know that C == B. Of course,
the CEA
must contain some Result-Code that says there already is a
connection and
that this one will be shut down.
- Also I'm not 100%
convinced the state machine isn't subject to some race
conditions, though I
didn't look into that in detail.
In 6.1:
- 5th paragraph "When a
message is received...", references are incorrect:
6.1.1 -> 6.1.4; 6.1.2
-> 6.1.5; 6.1.5 -> 6.1.6.
In 6.1.8:
- in the figure, the
Route-Record should be set to nas.mno.net, not
drl.mno.net.
In
6.1.9:
- 1st paragraph, if the AVPs are put in reverse order, then it should
be
the FIRST Souce-Route AVP, not the last. Also, that AVP must be removed
after use :-)
- also, need to update 6.1 and 6.1.5 to include
source-routing.
In 6.4:
- 1st paragraph, "or broker". I would
suppose a broker would only operate
relays, proxies, or redirectors, and
could thus never originate messages
(other than errors)? Otherwise, just
state "This AVP identifies the node
which originated the Diameter message."
- 2nd paragraph, "The value of the Origin-Host AVP is guaranteed to be
unique within a single host". I would say it must be completely unique for
any given process.
In 6.5:
- not quite sure what the
Origin-Realm is for, and not quite sure what the
"realm of the originator"
might be. For me, realms are for users, not nodes.
In 6.6 (and other
places in 6):
- 1st paragraph, "This AVP MUST be present in all unsolicited
agent
initiated messages". Not sure why. The Source-Route AVPs should be
enough.
In 6.7:
- maybe we need an AVP derived type for realms?
- "Diameter servers initiating a request message use the value of the
Origin-Realm AVP from a previous message received from the intended target
host (unless it is known a priori)". This is no longer used.
Issue 113: base draft 07 comments
Submitter name: Jacques Caron
Submitter email address:
jacques_m_caron@yahoo.com
Date first submitted: August 3, 2001
Reference:
Document: Base-07
Comment type: E
Priority: 1
Section: throughout
Rationale/Explanation of issue:
This is just
an older mail I hadn't formally filed as an issue...
In 1.1:
-
second paragraph ("All data delivered by the protocol..."): "and AVPs
which
are explicitly excluded are not included": there isn't anything in
the ABNF
to state that AVPs are excluded.
- last paragraph, "(known as a proxy)" is
not consistent with other
definitions in the draft. Should say "(known as a
proxy or relay)".
- also, that paragraph defines a server as either a
proxy/relay or as a
server. It should be called an agent, or the definition
should be changed
to only include the real "server" function.
In
1.3:
- "Accounting record" def is incomplete (ends with "or accounting
events
from several").
- the AVP definition is restrictive. It might
include protocol-specific
data (e.g. routing information), not only pure AAA
data.
- "Diameter node" suddenly mentions translation agents, while this is
not
listed in the "Diameter agent" definition
- "Redirector":
inconsistent use of "Redirect", "Redirector",
"Re-direct"... [also
throughout the draft].
- the definitions of "Upstream server" and
"Downstream server", other than
the fact that they are reversed ;-> are
incorrect: it should be "nodes" and
not servers, and the definition should
be something "a node that is closer
to the client [resp. home server] in the
routing path, relative to a given
node". It might be the client [resp. home
server] itself, so it does not
necessarily provide "routing services"
towards it.
In 2.0
- 5th paragraph ("Diameter proxies..."), "in
addition"->"In addition" :-)
- 8th paragraph ("Communication between
Diameter peers..."): you mean
nodes, not peers, right?
- in the same
paragraph, the last sentence implies that all messages are
related to a
session (those messages would actually be exchanged between a
client and a
server, not any random set of nodes/peers). This does not
apply to all the
base protocol messages such as CER/CEA, DWR/DWA, etc.).
- in the last
paragraph, the semantics of Authorization-Lifetime have not
been updated
In 2.1
- 3rd paragraph, "A Diameter node MAY initiate connections
from any source
port" *except TBD*?
- same paragraph, "...MAY *be* any
of a peer's valid IP addresses."
- where did the 4th paragraph "A given
Diameter process SHOULD use the same
port number ..." come from? That's ugly
and unnecessary, as the process
identity will be communicated in CER/CEA.
- 5th paragraph, there should be a provision for hosts marked "bad" for
some reason.
- 7th and last paragraph, there is a mix between the
sockets API
(ECONNREFUSED) and TCP/ICMP packet exchanges. Should probably
replace
"ECONNREFUSED (a reset from the transport)" with "a reset from the
transport" (I think most TCP stacks interpret the ICMP error messages
themselves and return ECONNREFUSED). Actually, this isn't that much the
Diameter implementation itself, but the platform it is using. To be
clarified.
In 2.3.1:
- 1st paragraph, "Defining a new AVP value is
the best approach when a new
application needs to make use of an existing
Diameter application..." Isn't
that recursive? :-(
- last paragraph,
"Furthermore, if the command code on which the AVP value
is to be used would
require a different set of mandatory AVPs be present
*when the new AVP value
is used*, the list of AVPs must accompany the
request." (needs some
rewording)
- should reference something in 11.x, but I don't know what :-(
In 2.3.2:
- 1st paragraph, same application/application problem.
- 2nd paragraph, why MUST it be one of the listed types? Since AVPs are
opaque to those who don't use them and the AVP type is not included in the
packet...
- should reference 11.1.1
In 2.3.3
- should
reference 11.3
In 2.4
- I guess the whole Acct-Application-Id thing
with additional AVPs to
support in the same Accounting messages invalidates
the whole ABNF
consistency thing...
In 2.5:
- I guess this is
historical, but history in a not-yet-published RFC seems
weird... Why not
move the Mobile-IP application to 3?
- I would also swap the E2E security
app and NASREQ. The first one is more
like an extension of the base draft
while the second (like Mobile-IP) are
real AAA apps.
- oh, by the way,
it's CMS, not E2E now :-) [also happens in other places
in the draft]
-
3rd paragraph, "Relay and redirect agents MUST advertise...": what should
an
agent that is a server for some requests (those for users in the local
domain) and a relay/redirector for others (users in remote domains)
advertise?
In 2.6:
- the Host identity received in CER/CEA MUST be
saved! I guess there should
actually be two values: one that is configured
(or discovered using DNS,
SLP...) until the connection is established, and
then the official unique
but consistent value advertised in CER/CEA.
Actually, there might be
several of the configured/discovered identities if
the node finds out that
multiple identities point to the same process.
-
as discussed previously, I don't think the role belongs here: a peer
might
be primary for a realm, secondary for another, alternate for yet
another...
In 2.7
- realm/domain inconsistencies (also throughout the draft),
as already
pointed out by Marta.
- Application identifier: should
clarify that accounting and auth messages
might actually be sent to
different servers
- local action/proxy: "See section 6.1.8 for *proxying*
guidelines."
- local action/redirect: why home server? Should just be
"agent"...
- "Expiration time. Specifies the time which dynamically
discovered a route
table entry expire." -> "Expiration time. Specifies
the time which *a*
dynamically discovered route table entry expireS." ("a"
moved, "s" added)
- 2nd paragraph "It is important to note...", "proxies
SHOULD NOT reorder
AVPs": I would say they MUST NOT reorder AVPs of the same
type.
- last paragraph: "When a request is routed, the target server MUST
have
advertised the Application Identifier (see section 2.5) for the given
message, or have advertised itself as a relay or proxy agent."... Mmmm.
What if the local node has not connected to that agent (not server, btw)
yet, so doesn't know if it actually advertises the said application? Also,
what should it do if there's a mismatch here?
In 2.8
- 1st
paragraph, translation agents are not defined in 1.3
- 4th paragraph "A
stateful agent...", Authorized-Lifetime -> Session-Timeout
In 2.8.1
- 4th paragraph "The example provided...", the last part "which is routed
back to NAS using Diameter routing AVPs" is no longer true -> "which is
routed back to NAS using saved transaction state"
In 2.8.2
- 2nd
and 5th paragraphs may be a bit too strong: CMS can be applied on
part of
the AVPs only (those that would not be modified, e.g.). And CMS
will most
certainly apply to AVPs that are not modified (i.e. authorization
answers
and accounting requests)
In 3.0
- "r(eserved) - this flag bit is..."
-> "these flag bits are..."
- Hop-by-Hop identifier, "The sender MUST
ensure that the Hop-by-Hop
identifier in a request is locally unique (to the
sender)". This might be
too strong: it actually needs to be unique on a
per-connection basis only.
- End-to-End identifier, I guess the method
described should only be a
recommendation, not part of the spec (which
should state that it must be
unique for a given Origin-Host ID for the
lifetime of the message)?
- same paragraph, should mention here that a
server is supposed to answer
the same thing it did upon reception of a
duplicate, and not take any
action that would affect state again?
In
3.1
- should renumber everything so that we have something consistent and
contiguous rather than this sparse table?
In 3.2
- diameter-name
= ALPHA *(ALPHA / DIGIT / "-") should probably be
diameter-name = ALPHA
*(ALPHA / DIGIT / "-") (ALPHA / DIGIT)
(I suppose we don't want command
names ending with a dash?)
In 5.3.*:
- I guess we should add some
AVPs to advertise the local values of the
timers (Ti, Tr, Tw, Td...) so that
incompatible values are detected
immediately and the connection torn down
with a nice log (a la OSPF IIRC -
or is it IS-IS?)
In 11.3:
-
All values, other than zero... -> All other values, except 0...
On a
different subject, something I've been thinking about some time ago,
but
didn't check against the docs: in a roaming environment, what is
important
to an ISP is not that the accounting data from the original
client be signed
by that client (it might not know the client at all, and
doesn't care). What
they care about is that the accounting data be signed
by their roaming
"peer" (partner), i.e. the one that will pay them.
Actually, if the
accounting data includes money (you know, $$$), proxies
might change that
amount on the way (to reflect margins of brokers), but it
should
nevertheless be signed at some point... Some AVPs might actually
have
multiple signatures, or be signed, then checked, then modified (old
sig
removed), and resigned multiple times on the way.
Issue 114: DiameterIdentity
Submitter
name: Jacques Caron
Submitter email address: jacques_m_caron@yahoo.com
Date first submitted: August 5, 2001
Reference:
Document: Base-07
Comment type: T
Priority: 1
Section: throughout
Rationale/Explanation of issue:
There apparently is a lot of
confusion surrounding DiameterIdentity, due to
its two very different uses:
1. as a way to designate some way to access a Diameter agent, by (implicity
or explicitly) specifying a FQDN, port, protocol and transport. This shall
be used in configuration files, Alternate-Host and Redirect-Host AVPs, etc.
Note that there might be *a lot* of different DiameterIdentity values that
actually designate the same Diameter agent (as an agent might listen on
multiple ports and addresses, using multiple protocols, and there might be
many FQDNs pointing to any of those addresses).
2. as a way to
uniquely identify a given agent for the purposes of
duplicate connection
detection, loop detection, etc. In this case, the
identifier must be unique,
and should be considered completely opaque by
other servers that should do a
pure binary comparison.
To alleviate this confusion, I propose to
separate the current
DiameterIdentity derived AVP format into two different
formats:
1. the DiameterURI format, using the existing syntax. Used in
config files,
Alternate-Host and Redirect-Host AVPs...
2. the
DiameterIdentity format, using a new syntax, the only purpose of
which is to
make sure it is unique (and as a side effect, a lot shorter,
which should
help a lot in Route-Record and Source-Route AVPs).
Proposed changes:
In 2.6, replace the Host identity section with:
- Host URI,
following the conventions described for the
DiameterURI derived AVP data
format in section 4.4. This MAY be
found by static configuration, or
dynamically updated via any of
the methods described in section 5.2. Note
that there might be
multiple DiameterURIs resolving to the same peer.
-
Host Identity. Following the conventions described for the
DiameterIdentity
derived AVP data format in section 4.4. This
is copied from the Origin-Host
AVP of the CER or CEA message
received from the peer.
In 4.4,
replace the DiameterIdentity section with:
DiameterURI
The
DiameterURI format is derived from the OctetString AVP
Base Format. It uses
the UTF-8 encoding and has the same
requirements as the UTF8String. In
addition, it must follow
the Uniform Resource Identifiers (URI) syntax [29]
rules
specified below:
Diameter-URI = fqdn [ port ] [ transport ]
[ protocol ]
aaa-protocol = ( "diameter" | "radius" | "tacacs+" )
protocol = ";protocol=" aaa-protocol
; If absent, the default AAA
protocol
; is diameter.
fqdn = Fully Qualified Host Name
port = ":" 1*DIGIT
; One of the ports used to listen for
;
incoming connections. ; If absent,
; the default Diameter port (TBD) is
; assumed.
transport-protocol = ( "tcp" | "sctp" | "udp" )
transport = ";transport=" transport-protocol
; One of the
transports used to listen
; for incoming connections. If absent,
; the
default SCTP [26] protocol is
; assumed. UDP MUST NOT be used when
; the
aaa-protocol field is set to
; diameter.
The following are examples
of valid Diameter host
identities:
host.abc.com;transport=tcp
host.abc.com:6666;transport=tcp
aaa://host.abc.com;protocol=diameter
aaa://host.abc.com:6666;protocol=diameter
aaa://host.abc.com:6666;transport=tcp;protocol=diameter
aaa://host.abc.com:1813;transport=udp;protocol=radius
A DiameterURI
describes a way to connect to any Diameter agent.
It shall be used in
configuration files, Alternate-Host and
Redirect-Host AVPs, etc.
DiameterIdentity
The DiameterIdentity format is derived from the
OctetString AVP
Base Format. It uniquely identifies a Diameter agent, for
the
purposes of loop and duplication connection detection. Upon
startup,
the agent must select one specific (address,
transport, port) tuple it is
listening on for new connections,
and encode the associated information in
one of the formats
described below. Since only one single process can be
listening
on a given (address, transport, port) tuple, the identity is
guaranteed to be unique (see below for non-unique addresses).
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Reserved(0) | Protocol | Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4
Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This format is used for agents listening on IPv4 addresses
only.
Protocol is the protocol number of the transport used,
i.e. XXX for TCP or
XXX for SCTP. The 'Port' and 'IPv4 Address'
fields contain the port and IPv4
address selected,
respectively, 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Reserved(0) | Protocol | Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6
Address |
+ +
| |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This format is used for agents listening on at least one unique
(i.e. not link-local, etc.) IPv6 address. If the agent is
listening on
both IPv4 and IPv6 addresses, it should select a
tuple with an IPv6 address.
'IPv6 address' contains that value.
The other fields have the same meaning
as above.
Note that these formats are guaranteed to be unique only for
hosts that have unique IP addresses, i.e. not for hosts that
use RFC1918
"private" IP addresses. Hosts using RFC1918
addresses MUST append a unique
IP addresses (administratively
configurable) that is related to the routing
domain they're
part of, such as the public IP address of the host acting as
a
gateway to the public Internet.
A DiameterIdentity value is thus
either 8, 20, 24, or 36 bytes
long, depending on the presence of one or two
addresses, each
of which can be 4 bytes (IPv4) or 16 bytes (IPv6) long.
Other formats can be used, as long as the binary
reprensentation is
globally unique for any given host. This
requires the use of values other
than 0 for the "reserved"
field, which should then be registered with IANA.
Any use of AVPs using the DiameterIdentity format MUST consider
their contents as opaque. Any comparison MUST be purely binary
(i.e. two
values are equal if they have the same length and all
bytes match; in all
other cases they're not equal). An ordered
comparison is also defined in
section 5.6.4.
In 5.3.8, s/Identity/URI/
In 6.4, remove 3rd
paragraph.
Replace 6.8.1 with:
The Route-Record AVP (AVP Code 282)
is of type DiameterIdentity. The
identity added in this AVP MUST be the same
as the one received in the
Origin-Host of the CER or CEA message received
from the peer.
In 6.12, s/Identity/URI/
In 8.8, either:
-
s/Identity/URI/ + some wording to say it's one of the URIs designated the
host,
- or use decimal-encoded Identity
- or move to purely binary
Some other changes might be needed in the other drafts.
Issue 115: CHAP-Password is complex
Submitter name: Pat Calhoun
Submitter email address:
pcalhoun@bstormnetworks.com
Date first submitted: August 6th, 2001
Reference:
Document: NASREQ 07
Comment type: T
Priority: S
Section: 3.1.1.2
Rationale/Explanation of issue:
The definition of
the CHAP-Password AVP in -07 still shows up as being of
type complex. This
needs to be changed to a Grouped AVP, and some
additional text on how
RADIUS<->Diameter translation is needed.
Requested change:
Make the AVP Grouped
Issue 116: Accounting-Session-Id definition
incorrect
Submitter name: Pat Calhoun
Submitter email address:
pcalhoun@bstormnetworks.com
Date first submitted: August 6th, 2001
Reference:
Document: NASREQ 07
Comment type: T
Priority: S
Section: 9.8.4
Rationale/Explanation of issue:
The definition of the
Accounting-Session-Id states that this AVP is
only used for RADIUS gateway
purposes, but other text in the draft
shows that this AVP is used to
identify Accounting subsessions.
Requested change:
Leave
Accounting-Session-Id as-is, and create a new AVP called
Accounting-Sub-Session-Id, and change the necessary text.
Issue 117: Remove support for Source-Route
Submitter name: Pat Calhoun
Submitter email address:
pcalhoun@bstormnetworks.com
Date first submitted: August 6th, 2001
Reference:
Document: NASREQ 07
Comment type: T
Priority: S
Section:
Rationale/Explanation of issue:
Support for explicit paths
for server-initiated messages was added in
-07. Discussions I have had with
folks this week show that consensus
is that this feature is overly complex,
and we should instead require
that the network is configured properly.
Requested change:
Go back to -06 way of server initiated messages.
Issue 118: Error processing/capabilities
negotiation
Submitter name: Jacques Caron
Submitter email address:
jacques_m_caron@yahoo.com
Date first submitted: August 6, 2001
Reference:
Document: Base-07
Comment type: E
Priority: 1
Section: throughout
Rationale/Explanation of issue:
In the
current draft, there are many situations where any agent can return
an error
when processing a message (e.g. when receiving an AVP tagged with
the 'M'
bit that it doesn' accept). However, there are no provisions for
sending an
error in response to an answer (an error is an answer, and can
only be sent
in response to a request).
This makes it difficult to handle some cases,
especially end-to-end
capabilities negotiation (e.g. server wants access
device to set up some
filter, encryption, IP address, route..., but access
devices cannot/will
not do it: there is no way for the access device to
communicate this back
to the server).
I think the best approach is
to move from the simple Request/Answer model
to a Transaction model possibly
involving multiple round-trips until
everybody is satisfied. Another
possibility is for access devices to
advertise their capabilities in advance
in the initial request, but that
might be quite difficult.
Follows a
(longish) description of one possible implementation using the
Transaction
model. I think most people might find it waaaaaay too complex, but:
(a) it
gives a clear understanding of the process and the several
round-trips, why
they are needed, and when.
(b) there are hints at the end as to ways to
simplify this A LOT :-)
Creativity welcome :-)
The following
messages can be exchanged between two nodes:
Msg Dir Description Expects
------ ---- ---------------------------------------
---------------------------
REQ C->S request WMORE, AUTH, REJECT, ACCEPT
MORE C->S error or additional information WMORE, AUTH, REJECT, ACCEPT
NAUTH C->S auth not accepted, need new one AUTH, REJECT
ACK C->S
auth accepted ACCEPT
ABORT C->S transaction abort REJECT
WMORE
S->C request for more information MORE, ABORT
AUTH S->C authorization
information ACK, NAUTH, ABORT
REJECT S->C reject
connection/non-recoverable error (nothing)
ACCEPT S->C accept with
negociated authorization (nothing)
"server" and "client" are defined
here solely in the context of the given
transaction, the client being the
node initiating the transaction, and the
server being the node that is
supposed to provide an answer.
REQ is the first message of a
transaction, including application, realm,
etc. It is routed according to
the realm routing table towards the server
for regular access-device to
home-server transactions, and using
source-routing for home-server to
access-device transactions. Routing
information is collected on the way and
stored in Route-Record AVPs.
MORE is sent whenever the client needs to
send additional or modified
information in a transaction. It might be due to
capabilities negociation
(e.g. the server didn't understand an 'M'-AVP) or a
multi-round-trip auth
(e.g. EAP), that were signalled by the server using a
WMORE message.
NAUTH is sent whenever the client received authorization
information (AUTH)
for the transaction, but isn't satisfied with it (e.g.
there is an 'M'-AVP
that it doesn't accept). It includes the usual
AVP-related info (missing
AVP, bad AVP value, unrecognized AVP...), possibly
with hints about
accepted values (I like very much the modem AT command set
extensions such
as AT+command=? that give a list of allowed values, would be
cool if we
could have something equivalent here).
ACK is sent once
the client got authorization information for the
transaction (AUTH) from the
server, and is satisfied with it.
ABORT is sent by the client if it got
a WMORE message and cannot provide
any new or modified information (e.g. the
server didn't accept an 'M'-AVP,
but the access device absolutely needs it),
or got an AUTH message and
doesn't accept some of the values and doesn't
want to negotiate them.
MORE, NAUTH, ACK, and ABORT are sent with
Source-Route AVPs from the WMORE
or ANS message.
WMORE is sent by
the server to the client if it needs the client to send
additional or
modified information (using a MORE message). It includes info
about what it
wants (e.g. further EAP messages, or modified AVPs).
AUTH is sent by the
server when it has any authorization information it
wants to send the
client.
ACCEPT is sent by the server to the client to give a final yes,
either
directly after receiving info (REQ or MORE) if it only says "yes", or
after
receiving an ACK accepting previous AUTH information.
REJECT
is sent by the server to the client if the transaction was refused
or if
there was an unrecoverable error, or if the server got a NAUTH to an
AUTH
message and doesn't want to negotiate, or to confirm it got an ABORT.
All messages from server to client (WMORE, AUTH, ACCEPT, REJECT) are
routed
using stored message state in proxies/relays. They also carry
Route-Record
information to help routing of further messages from client to
server.
Note that "authorization" (and of course AUTH and NAUTH) is an
abuse, it's
actually any negotiable AVPs the server sends to the client, but
the only
case I could think of is authorization information.
So, in
the simplest case, the scenario would be:
REQ ->
<- ACCEPT
If there is any authorization information:
REQ ->
<- AUTH
ACK ->
<- ACCEPT
In a simple 2-round trip EAP auth, the
scenario might be:
REQ ->
<- WMORE
MORE ->
<- AUTH
ACK ->
<- ACCEPT
In a simple one-round trip auth, but
where the access devices doesn't agree
with the authorization parameters the
first time, it would be:
REQ ->
<- AUTH
NAUTH ->
<-
AUTH
ACK ->
<- ACCEPT
Server doesn't understand/accept an
AVP the client sent, and the client
doesn't want to do without:
REQ
->
<- WMORE
ABORT ->
<- REJECT
Server thinks the
access device is completely out of its mind, or knows
right away the user is
not allowed:
REQ ->
<- REJECT
More generally, for a
successful transaction:
REQ ->
[
<- WMORE
MORE ->
]*
[
<- AUTH
[
NAUTH ->
<- AUTH
]*
ACK
->
]?
<- ACCEPT
Note that it may require adding a
transaction identifier. Alternatively,
the session identifier may be enough?
On a final note, it might be possible to reduce the number of possible
message types (by using some other AVP, e.g. different ranges of
Result-Code), but it must be possible for relays/proxies to track a
transaction state, i.e. know when it ends (by either a REJECT or an
ACCEPT). All that is needed (as seen from the outside) are "Request"
(anything client to server), "Continue" or "Challenge" (WMORE, AUTH) and
"Answer" (REJECT, ACCEPT). This could be done by classifying correctly all
Result-Codes that require further exchanges in a different range than those
that don't. In particular, that means that any answer with negotiable AVPs
should be in the first category, since they need another request to either
accept them, or ask for changes.
Jacques-in-complex-mode.
Issue 119: E bit, P bit, and proxy-info
Issue 120: Minor editorial changes in CMS Security
Application Issue 121: More editorial changes in CMS
Issue 122: Editorial change in
draft-ietf-aaa-diameter-07.txt Issue 123: Use of Application Identifiers in
routing Issue 124: Inconsistency in OCSP-Request-Flags
AVP Issue 125: Inconsistency in OCSP-Responses AVP
Issue 126: Clarification in certificate naming
schema Issue 127: Editorial changes in CMS
Issue 128: duplicate packet detection in failure
case Issue 129: NASREQ unsolicited challenge
requests Issue 130: Prescribed use of encryption in
NASREQ Issue 131: Use of Auth-Request-Type in NASREQ
Issue 132: Multiple signatures on a set of
AVPs Issue 133: digest value within CMS-Signed-Data
AVP Issue 134: Several CMS-Encrypted-Data AVPs in a
message Issue 135: contentType instead of eContentType in
CMS-Encrypted-Data Issue 136: Proxy's DSAR on behalf of a client
Issue 137: CMS Proxy's DSAAs Issue 138: Signed DSA messages Issue 139: Key Management chapter rephrasing
Issue 140: Can Answer be rejected?
Issue 141: OCSP Response request additional
text Issue 142: CEKMaxDecrypts value vs DSA length
Issue 143: Editorial changes in CMS #4
Issue 144: OCSP Support Issue 145: Order in CMS-proxy messages
Issue 146: CHAP Algorithm missing
Issue 147: CHAP Algorithm missing
Issue 148: Change section 5-6 in MIP app to
relect Issue 149: Revalidation of certificates in
cache Issue 150: S/MIME precisions Issue 151: 8.1 Authorization Session State
Machine Issue 152: Confusion between security services and
techniques to achieve them Issue 153: Key Length in CMS Security
Application Issue 154: End-to-End Id in answer messages
Issue 155: Small editorial comment on section
5.5.4 Issue 156: DSA error codes Issue 157: DSA error codes (cont)
Issue 158: DSA error codes (III) Issue 159: Reference change in CMS-02
Issue 160: Destination-Host in PDSR
Issue 161: Authorisation rejected in CMS
Issue 162: Error replies to requests with no
session id Issue 163: Error codes (recap) Issue 164: problems with Watch Dog
Issue 165: Expiration of DSAs on behalf of a
client Issue 166: Ambiguity on Destination-Host AVP in
Answer messages Issue 167: CMS-Cert in AVP occurrence table
Issue 168: DIAMETER_NO_COMMON_TRUST error
Issue 169: Result-code with 'P' bit erroneous
Issue 170: Erroneous protection expectations
Issue 171: missing realm protocol error
Issue 172: The need for Float128 ?
Issue 173: Transport failure algorithm differs
between drafts Issue 174: CMS Decryption Error Issue 175: Missing text in float definitions
Issue 176: Add clarifying App-Id text in CER/CEA
sections Issue 177: CMS proxy scenarios Issue 178: Partial support of CMS
Issue 179: PDSA-Request without DSA-Target-Realm
Issue 180: AAA-Server-Certs Issue 181: Digital encryption + signature in
CMS-Sec Issue 182: Retain RADIUS attribute types for
attributes 0-255 Issue 183: Diameter hop-by-hop security
Issue 184: CMS-Data AVPs in base protocol
Issue 185: CMS-protected AVPs outside a DSA
Issue 186: Decouple authorization and key
generation Issue 187: Foreign-Home authentication extension
doesn't exist Issue 188: NAS-Key-Binding and Ciphersuite
Negotiation Issue 189: NAS-Session-Key and Initialization
Vectors Issue 190: NAS-Session-Key and Session Master
Keys Issue 191: How to know when to use TLS
Issue 192: Missing Disconnect Cause
Issue 193: Changes to Peer state machine in
base-08-alpha Issue 194: Add Termination-Cause values for
MIPv4 Issue 195: Clarifications on key generation
(mobileip-08) Issue 196: How to use Diameter Accounting
Issue 197: Missing Session Termination Cause in
Section 8.15 Issue 198: MIP-FA-to-[HA|MN]-Key not needed in
HAR Issue 199: wdRecoveryCount used for triggering
failover procedures Resolution: This issue is believed to be fixed in Transport-05. If has not
been resolved, please reopen. Issue 200: Missing UserName AVP in table in
section 10.2
Submitter name: Mark Eklund
Submitter email address: meklund@cisco.com
Date first submitted: 13-Aug-2001
Reference: N/A
Document: base
Comment type: T
Priority: 2
Section: 6.1.7, 6.2, and 7.2
Rationale/Explanation of issue:
1. Can a Diameter packet contain
both a 'P' bit and a 'E'
bit in the packet header?
2. Will a
Diameter packet with the 'P' bit set contain the
proxy-info data from the
request?
Requested change:
A diameter error packet with an 'E'
bit set MUST have the
required AVPS listed in section 6.2, "Diameter Answer
Processing".
Modify section 6.2 to state that these requirements are
valid
even if the 'E' bit is set.
Modify section 7.2 to list the
answer-message as
and state that the 'P' bit will be set the same as the 'P'
bit in
the request.
I'm not certain if we need to modify section 6.1.7. It will
be
technically correct with the requested changes, but probably
could be
made more clear.
Submitter name: Miguel A. Monjas
Submitter email
address: ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-08-14
Reference:
Document: CMS-02
Comment type: E
Priority: 1
Section: 1.1, 1.2, 1.3, 2.0, 3.1, 3.2, 4.3, 5.0, 6.2
Rationale/Explanation of issue:
Minor editorial changes in draft
Requested change:
In 1.1, page 5 (fourth paragraph):
replace
"...requires that the initiator issue a..." with "...requires
that the
initiator issues a..."
In 1.2, figure 3:
replace "PDSR" with "PDSAR"
and "PDSA" with "PDSAA"
In 1.3, page 7:
rephrase the first
paragraph. Maybe the following proposal would be
enough:
When a
redirect agent is used, allowing the access device, or first
hop relay or
proxy agent, to communicate directly with the home
server, the hop-by-hop
security mechanisms specified in the base
protocol MAY be sufficient.
In 1.3, page 7 (second paragraph):
replace "...signing of select
Diameter..." with "...signing of
selected Diameter..."
In 1.3, page
7 (second paragraph):
replace "AVPS" with "AVPs"
In 2.0, page 9
(last paragraph):
replace "section 4.5 of [1]" with "section 4.6 of [1]"
In 3.1, page 11 (first item in second list):
replace "TTL for this
SA" with "TTL for this DSA"
In 3.1, page 11 (first item in last list):
replace "the certificate chain selected is..." with "the certificate
chain provided [in the DSAA] is..."
In 3.1, page 12 (first
paragraph):
replace all references to "Diameter node" with "Diameter
initiator"
In 3.2, page 12 (first item of the list):
replace
"Diamater" with "Diameter"
In 4.3, page 16:
replace "an Security
Association" with "a Diameter Security
Association"
In 5.0, page 18:
replace all references to "proxy server" with "relay agent"
In 6.2,
page 21 (second paragraph):
replace "CMSEnvelopedData" with "EnvelopedData"
In 6.2, page 21 (third paragraph):
replace "CMS-Data" with
"CMS-Encrypted-Data"
Submitter name: Miguel A. Monjas
Submitter email address:
ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-08-14
Reference:
Document: CMS-02
Comment type: E
Priority: 2
Section:
Rationale/Explanation of issue:
Sentences of the type "the
x message must be signed" are confused
since not the whole message is signed
but only the required AVPs
Requested change:
Change all occurrences
of "the x message must/may/should be signed"
with "the x message
must/may/should include (or carry) an appropriate
digital signature"
Submitter name: Martin Andersson
Submitter email address: martin.andersson@ipunplugged.com
Date first
submitted: 2001-08-20
Reference:
Document:
draft-ietf-aaa-diameter-07.txt
Comment type: E
Priority: 2
Section:
4.6 & 7.5
Rationale/Explanation of issue:
The table in section
4.6 states that Failed-Avp should be of type OctetString
while section 7.5
states it should be of type Grouped.
Requested change:
Change
Section 4.6 to state that the Failed-Avp is of type Grouped
Submitter name: Srinivas Sreemanthula
Submitter email
address: Srinivas.Sreemanthula@nokia.com
Date first submitted: August 16,
2001
Reference:
Document: Base
Comment type: T
Priority: 1
Section: 2.5 Last paragraph
Rationale/Explanation of issue:
In the
first sentence, one may interpret the text that the use
of application
identifiers in the routing is a necessary requirement.
We feel that the use
of application identifiers while routing is
optional whereas the routing
must be based on the destination realm
contained in the message. This would
provide a flexible scenario
where proxies and relays always need to be able
to route based on the
realm, and in addition, they may choose to route based
on application
identifiers, as well. This would also allow for
implementation
scenarios capable to hide the network topology or distribute
the
server functions within a realm by use of a "gateway" diameter nodes
.
Requested Change:
Rephrase section 2.5 last paragraph, first
sentence to:
"While the diameter relay and proxy agents MUST know how to
route messages based on the destination realm indicated in the
message,
they MAY be able to route the messages also based on the
application
identifiers of a particular message."
Submitter name: Miguel A. Monjas
Submitter email address:
ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-08-20
Reference:
Document: CMS-02
Comment type: T
Priority: S
Section: 3.1
Rationale/Explanation of issue:
The usage scenario
chapter states that a DSAR message contains, among
other information:
- (optionally) a flag indicating that the originating Diameter
node
wishes to receive certificate status information (using
OCSP messages) ...
So that, the OCSP flag (I suppose we're talking about
OCSP-Request-Flags AVP) is claimed as optional. However, the format of
the DSAR messages indicates that OCSP-Request-Flags are mandatory
(i.e.
it's the nonce value what is optional, since it depends on the
requestes
OCSP response):
...
{ OCSP-Request-Flags }
...
[ OCSP-Nonce ]
...
Requested change:
Replace the previous paragraph from usage scenario
chapter (the whole
paragraph) with this one:
- a flag indicating
wheter 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.
Submitter name: Miguel A. Monjas
Submitter email address:
ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-08-20
Reference:
Document: CMS-02
Comment type: T
Priority: S
Section: 3.1, 4.2
Rationale/Explanation of issue:
The usage scenario
chapter states that a DSAA message contains, among
other information:
- (optionally, if nonce received and OCSP supported) a list of
OCSP
responses for the certificates in question, each of which
contains the nonce
from the DSAR message
However, the format of the DSAA messages indicates
that OCSP-Response
AVP is mandatory:
...
* { OCSP-Responses }
...
Furthermore, the
chapter describing OCSP-Responses AVP says the
following:
The
OCSP-Responses AVP [...] contains an OCSP response message from
an OCSP
responder. If the OCSP-Request-Flags AVP indicating a
response was required
in the corresponding request message, the
OCSP-Responses AVP MUST be
present. Furthermore, the
OCSP-Request-Flags AVP MAY request a fresh OCSP
response message,
which MUST also include the OCSP-Nonce AVP.
Which
looks to suggest that if OCSP-Request-Flags AVP in DSAR was
OCSP_RESPONSE or
OCSP_FRESH_RESPONSE (with an OCSP-Nonce associated)
there must be an
OCSP-Response AVP. But not in the rest of the
possibilities
(NO_OCSP_RESPONSE).
Requested change:
Replace the previous paragraph
from usage scenario chapter (3.1) with
this one:
- (optionally, if
OCSP response was required 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
Replace the mandatory field of DSAA in 4.2:
* { OCSP-Responses }
with an optional field
* [
OCSP-Responses ]
Submitter name: Miguel A. Monjas
Submitter email address:
ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-08-20
Reference:
Document: CMS-02
Comment type: Technical
Priority: S
Section:
Rationale/Explanation of issue:
The naming schema of
AAA servers certificates are spread among
different chapters in the
specification.
In 1.5 it's said that "The realm of the participants is
found in the
subjectAltName field of the Diameter server's X.509
certificate".
In 3.1, between the checks done by the DSA initiator when
the DSAA is
received, it's said that:
- the realm part of the user's
NAI must occur as a subjectAltName
(with the dNSName option) in the AAA
server's certificate. This
dNSName MUST be of the form
"Diameter-
anything (e.g. "Diameter-1.baltimore.com", "Diameter-
west.sun.com") chosen by the Diameter server administrator.
Finally,
a whole chapter (3.2. Certificate Requirements) deals with
the same topic.
Specifically, it's said that:
Certificates [...] MUST also include a
Diameter node's FQDN, which
is typically added in the Host-Name AVP [1], as
one of the values
of
the subjectAltName extension of the Certificate.
And
For Diameter nodes (capable of acting as recipients for
confidentiality), the FQDN MUST be of the form "Diameter-
And last but not least
1. Where a Diameter
node is verifying a signature it needs to be
able to compare the identity of
the signer against the identity
in the Host-Name AVP.
Requested
change:
The main purpose would be to clarify the whole topic. I'd
suggest:
- Unifying the terminology. Using "realm" always or "domain"
always.
- To switch the long explanation of chapter 3.1 to a more
appropriate
place (chapter 3.2), including a reference to it in the item of
3.1
chapter.
- Explaining which AVP is Host-Name AVP
Additionally I'd like to receive a clarification about the realms
involved. I suppose that the "realm part of the user's NAI" is carried
by means of the Destination-Realm in the DSAR, but I'm not sure. BTW
Submitter name: Miguel A. Monjas
Submitter email address:
ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-08-20
Reference:
Document: CMS-02
Comment type: E
Priority: 2
Section:
Rationale/Explanation of issue:
The name "Response" in
OCSP-Responses is plural.
Requested change:
Change all occurrences
of "OCSP-Response" with "OCSP-Responses"
Submitter name: John Loughney
Submitter email address:
john.loughney@nokia.com
Date first submitted: August 20, 2001
Reference:
Document: Base
Comment type: T
Priority: 1
Section: In section
9.4 Fault Resilience,
Rationale/Explanation of issue:
The text in
9.4 may not be sufficient in failure cases. Some text is needed
to describe
how to handle the failure case.
Requested Change:
Additional
text should be added to discuss
The sending party sends the (maximal
amount = the used send window size)
unacknowledged packets (after a link
failure) to the next available
secondary/tertiary/etc. alternative recipient
node (CG), with a mark that
they are potential duplicates, to wait there for
a final decision.
After the original link comes up, the original sender
tests with empty dummy
packets if the original recipient would acknowledge
those packet numbers as
"already successfully handled" or "new".
Then the sender just announces the secondary node which waiting packets
it
may release towards the final destination (like BS), and which waiting
potentially duplicated packets to cancel (since they had already been
successfully handled by the original recipient node just before its link
went down.
Submitter name: Kevin Purser
Submitter email address:
kevin.purser@ericsson.com
Date first submitted: August 21, 2001
Reference: none
Document: NASREQ-07
Comment type: 'E'ditorial
Priority: 'S' Must fix
Section: 3.0
Rationale/Explanation of issue:
The last paragraph of this section describes the possibility for a AAA
server to "issue an unsolicited re-authentication and/or re-authorization by
issueing an AA-Challenge-Ind message to the NAS."
First and
foremost, this kind of message no longer exists. Additionally,
submitted
Issue 32 handles the technical issues regarding the removal of
such
messages.
Requested change:
Remove the last paragraph of section 3.0
Submitter name: Kevin Purser
Submitter email address:
kevin.purser@ericsson.com
Date first submitted: August 21, 2001
Reference: none
Document: NASREQ-07
Comment type: 'E'ditorial
Priority: '1' Should fix
Section: 3.1.1.1
Rationale/Explanation of
issue:=20
This section mentions that the User-Password AVP "MUST be
encrypted =
using of the methods described in [2] or [13]," where [2] is the
Base =
Protocol, and [13] is the CMS Security Application. Of the mechanisms
=
described in the Base Protocol, neither IPsec or TLS deal with =
encrypting portions of a diameter message, but rather the entire message =
itself.
Requested change:=20
Remove the reference to [2],
leaving only the reference to [13].
Submitter name: Kevin Purser
Submitter email address:
kevin.purser@ericsson.com
Date first submitted: August 21, 2001
Reference: none
Document: NASREQ-07
Comment type: 'T'echnical
Priority: '1' Should fix
Section: 3.0
Rationale/Explanation of
issue:
In the second paragraph, "...it is possible to send a request for =
authorization only. The type of service depends upon the =
Auth-Request-Type AVP." However, the use of this AVP is not mandatory =
in any of the messages defined in the NASREQ application, which may =
produce situations where the desired functionality (only =
re-authentication, only re-authorization, or both) is ambiguous.
Requested change:=20
Make the Auth-Request-Type AVP mandatory in the
AAR and DER, and at =
least optional in the AAA and DEA to allow the AAA
server to indicate =
the desired functionality (only re-authentication, only
=
re-authorization, or both) expected.
Submitter name: Miguel A. Monjas
Submitter email address:
ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-08-22
Reference:
Document: CMS-02
Comment type: T
Priority: 1
Section: 6.1
Rationale/Explanation of issue:
In 6.1 it's stated
that:
Multiple Diameter entities MAY add their signatures to an existing
CMS-Signed-Data AVP using the countersignature attribute, defined
in
section 11.4 of [3]. The countersignature attribute requires that
the
signatures occur sequentially, meaning that each signature covers
the
existing signatures in the CMS object.
May I assume that this is the
only way to add multiple signatures? If
so, there will be only one
singerInfo in a SignedData value (including
a message-digest attribute) and
that multiple signatures will be
handled only like countersignature
attributes (which allows not to
resign the whole set of AVPs)
Requested change:
If so, I'd change the previous paragraph to
say:
Multiple Diameter entities MAY add their signatures to an existing
CMS-Signed-Data AVP. It MUST be done using the countersignature
Attribute (defined in section 11.4 of [3]) and not as additional
SignerInfo values. The countersignature attribute requires that the
signatures occur sequentially, meaning that each signature covers
the
existing signatures in the CMS object. This attribute MUST be
always
unsigned.
Submitter name: Miguel A. Monjas
Submitter email address:
ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-08-22
Reference:
Document: CMS-02
Comment type: E
Priority: 1
Section: 6.1
Rationale/Explanation of issue:
In 6.1 (last
sentence of page 20), it's stated that not the whole
content being signed
but just a digest is inserted:
Instead, the digest value within the
SignedData
structure contains the digest produced in the
signature
process.
This paragraph isn't clear so that there isn't any digest value
within
a SignedData structure. The correct name for it is message-digest
attribute type (as defined in [CMS, 11.2]). An attribute of this type
may be inserted into any of the SignerInfo values that comprises
Signed
Data SignerInfos (take into account that this value would be
the same for
all the SingerInfo value, so that only one digest
algorithm must be
supported in [CMSSec]). However, this attribute is
only required (in [CMS,
11.2]) if any other attribute is present (if
present, message-digest is a
SignedAttribute). As the [CMSSec]
specification allows countersignature
operations, an attribute of this
type must be required.
Requested
change:
I'd replace the previous sentence with:
Instead, the
digest value of the AVPs produced in the
signature process MUST be included
in the CMS-Signed-Data
AVP as a message-digest attribute in the SingerInfo
value.
This attribute MUST be always signed.
Submitter name: Miguel A. Monjas
Submitter email address:
ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-08-22
Reference:
Document: CMS-02
Comment type: E
Priority: 1
Section:
Rationale/Explanation of issue:
In 6.2 it's stated
that:
CMS-Encrypted-Data MAY contain more than one CMS object, that is,
implementations MUST be able to add a new CMS-Encrypted-Data AVP
value
and also MUST be able to decrypt all CMS-Encrypted-Data AVP
values which are
encrypted for them.
This text isn't clear for me:
- The first
sentence ("CMS-Encrypted-Data MAY contain more than one
CMS object") might
suggest that it is possible to encrypt several AVPs
into a
CMS-Encrypted-Data AVP (even if those AVPs are also
CMS-Encrypted-Data
AVPs). That is, it might refer to nested
enveloping.
- However, the
next sentence, which is a consequence of the previous
("implementations MUST
be able to add a new CMS-Encrypted-Data AVP
value") isn't straightforward
since it doesn't specify to what it can
be added (to the message or maybe to
an AVP?). I mean, it might
suggest that an implementation MUST be able to
add a new
CMS-Encrypted-Data AVP to a message.
- The last sentence
("also MUST be able to decrypt all
CMS-Encrypted-Data AVP values which are
encrypted for them")
contradict my previous interpretation. If there're
nested encryption,
just the "last" envelope could be opened, so that a
nested envelope
couldn't be opened by the receiver unless he opened the
external
envelopes. On the other hand, with different CMS-Encrypted-Data
AVPs
inside the same message and with different recipients, any AVP would
be opened by the its intended recipient.
Another possibility is that
the paragraph is trying to say that new
RecipientInfo values may be
inserted. But that fact can't be true
since it would be necessary for an
entity trying to do that to be a
recipient to be able to decrypt the CEK and
reencrypt it with a new
key.
Requested change:
Replace the
quoted paragraph (and maybe the next one) with a more
clear text.
Submitter name: Miguel A. Monjas
Submitter email
address: ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-08-22
Reference:
Document: CMS-02
Comment type: E
Priority: S
Section:
Rationale/Explanation of issue:
In 6.2 it's stated
that:
Where AVPs are encapsulated within a CMS-Encrypted-Data AVP, the
eContentType of the EncapsulatedContentInfo MUST be id-data [11].
However, EncapsulatedContentInfo is the type of the value
encapContentInfo inside the CMS SignedData type, not EncapsulatedData.
Requested change:
Replace the previous paragraph with:
Where AVPs are encapsulated within a CMS-Encrypted-Data AVP, the
contentType of the EncryptedContentInfo value MUST be
id-data [11].
Submitter name: Miguel A. Monjas
Submitter email address:
ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-08-22
Reference:
Document: CMS-02
Comment type: T
Priority: S
Section:
Rationale/Explanation of issue:
If the agent agrees on
using the proxy, I assume that the proxy
establishes the DSA with the AAA
server using some of the parameters
provided by the agent in the first DSAR.
I think that, at least, same
TTL, Expected-Encrypted-AVP and
Expected-Signed-AVP have to be used.
However, shouldn't this point deserve
some kind of guideline? For
example, which AVPs values has to be just copied
into the newly
created DSAR? Or, which AVPs can be changed?
Requested change:
Add clarifying text
Submitter
name: Miguel A. Monjas
Submitter email address:
ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-08-22
Reference:
Document: CMS-02
Comment type: T
Priority: 1
Section:
Rationale/Explanation of issue:
When a proxy is
involved in the establishment of a DSA, the proxy will
reject the DSA
indicating to the agent that:
- it is not possible to establish a DSA
(Result-Code is
DIAMETER_NO_CMS_THROUGH_PROXY)
- it can act as a CMS
proxy on behalf of it (Result-Code is
DIAMETER_CAN_ACT_AS_CMS_PROXY).
According to 1.2:
The DSAA MUST be signed by the proxy agent, and
include its
certificate, to allow the access device to validate the
originator of the DSAA.
However, being the Result-Code a permanent
failure code, the message
will have the 'E' bit set, so that the message
will not conform to the
ABNF described for the command (DSAA). Then, on
which AVPs is going to
be applied the digital signature?
Requested
change:
Add clarifying text
Submitter
name: Miguel A. Monjas
Submitter email address:
ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-08-22
Reference:
Document: CMS-02
Comment type: T
Priority: 1
Section:
Rationale/Explanation of issue:
In some points of the
specification, is stated that a DSA message
must/may be signed:
In
1.2:
The DSAA MUST be signed by the proxy agent, and include its
certificate, to allow the access device to validate the originator
of
the DSAA.
In 1.3:
The CMS specification allows for Diameter AVPs
to be
multiply-signed
In 3.1
- the DSAA message MUST be
digitally signed and the signature
MUST be validated and the signer's
certificate chain MUST
terminate as a CA mentioned in the DSAR message
and also
The DSAR MAY be signed. If the originating node has a
private key
and protection expectations for AVPs are specified, then the
DSAR
SHOULD be signed.
The DSAA MUST be signed by a Diameter agent
or server within the
user's realm, to prevent an intermediate node from
modifying the
protection expectations for AVPs.
Pat has agreed on
changing that expression and saying that "...
(MAY|MUST) include the
CMS-Signed-Data AVP".
However, I'm a little bit concerned when the
presence of a
CMS-Signed-Data AVP is required. This AVP contains a digital
signature
on other (or others) AVPs. Those protected AVPs must have the 'P'
bit
set. But let's imagine that neither of the AVPs included in the
message have the 'P' bit set (maybe because the implementation does
not
consider that they must be protected). I assume that the
implementation must
detect those cases and, when a CMS-Signed-Data AVP
is required, set the 'P'
bit of an AVP, maybe chosen randomly or maybe
fixed in the configuration
(for example, the DSA-TTL AVP is always
present, so that the implementation
might be configured to protect it
always when a digital signature is
required). Is this issue up to the
implementation or should be specified in
the specification?
Requested change:
Add clarifying text
Submitter name: Miguel A. Monjas
Submitter email address:
ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-08-23
Reference:
Document: CMS-02
Comment type: E
Priority: 2
Section: 3.0
Rationale/Explanation of issue:
In 3.0 chapter a
number of issues are listed in order to provide
solutions for them in the
rest of 3.x chapters.
However, phrases like:
"a specific
Diameter key distribution mechanism is defined here"
"Another issue that
must be addressed..."
"This section describes..."
aren't lucky since
there isn't a specific mention to which chapters
will actually address the
issues.
Requested change:
Add clarifying phrases in order to
state the chapters in which any
issue will be addressed.
Submitter name: Martin Julien
Submitter email address:
martin.julien@ericsson.com
Date first submitted: 23/08/01
Reference:
Document: Base
Comment type: T
Priority: 1
Section:
Rationale/Explanation of issue:
It is not really clear in the draft
whether or not answer
messages can be rejected. Should it be allowed or not?
That needs to be clarified in the draft.
Submitter name: Miguel A. Monjas
Submitter email address:
ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-08-22
Reference:
Document: CMS-02
Comment type: E
Priority: 2
Section: 3.1
Rationale/Explanation of issue:
An additional
clarifying text might be added to depict the way in
which OCSP responses are
required.
Requested change:
Replace the following paragraph:
If certificate status (revocation) is an issue for the Diameter
initiator, then the DSAR message MAY contain a nonce value. The
idea
is that the sender of the DSAA makes OCSP requests on behalf of the
Diameter initiator and returns the OCSP responses to the Diameter
initiator as part of the DSAR message. The use of the nonce value
ensures that the sender of the DSAA cannot return cached or
otherwise
fake OCSP responses to the Diameter initiator.
with this one:
If
certificate status is an issue for the Diameter initiator (it
has
been
configured to check if the certificates has not been revoked),
then the DSAR
message MUST contain a flag indicating that it wishes
to receive certificate
status information. The DSAR message MAY
contain a nonce value (depending on
whether the initiator wishes a
"fresh" response). The idea is that the
sender of the DSAA makes
OCSP requests on behalf of the Diameter initiator
and returns the
OCSP responses to the Diameter node as part of the DSAR
message.
The
use of the nonce value ensures that the sender of the DSAA
cannot
return cached or otherwise fake OCSP responses to the Diameter
node.
If the initiator indicated that no fresh response was required (so
that no nonce value was provided) it MAY accept a stale response.
Submitter name: Miguel A. Monjas
Submitter email address:
ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-08-23
Reference:
Document: CMS-02
Comment type: T
Priority: S
Section: 3.4
Rationale/Explanation of issue:
As stated in 6.2,
CEK reuse should be supported by Diameter nodes. The
description of the open
issues left by the "Reuse of CMS CEKs" is done
in 3.4. When talking about
the maximum number of decryptions allowed
it's said that may be higher than
1 (the default value).
But, which is the relationship between the
maximum number of
decryptions and the length of the DSA? I mean, is it
possible to reuse
a CEK even if the DSA has already expired?
Requested change:
Add clarifying text
Submitter name: Miguel A. Monjas
Submitter email address:
ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-08-23
Reference:
Document: CMS-02
Comment type: E
Priority: 2
Section: 3.1, 3.2, 4.3, 6.2, 11.0
Rationale/Explanation of issue:
Requested change:
In 3.1 (last line):
replace "certicate"
with "certificate"
In 3.2 (last point in page 12):
replace
"certificiates" with "certificates"
In 3.2 (first item in page 13):
replace "certfificates" with "certificates"
In 4.3 (title)
replace "Assocation" with "Association"
In 6.2 (second last
paragraph)
In order to maintain coherence, replace "content encryption key
re-use" with "content encryption key reuse"
In 11.0:
replace
"S/MIME v2 Message Specification" with "S/MIME v2 Message
Specification"
Submitter name:
Miguel A. Monjas
Submitter email address: ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-08-23
Reference: Issue 125 (Inconsistency in
OCSP-Responses AVP)
Document: CMS-02
Comment type: T
Priority: S
Section:
Rationale/Explanation of issue:
The specification
doesn't mention which level of requirement OCSP has.
When reading the
specification, I've found that OCSP may be used with
two different purposes:
- Certificate validation in order to decide if a certificate in cache
can be used or not.
- Certificate validation on behalf of other DSA
participant.
Although the purposes is different, the implementation
would be the
same. However, how mandatory is the OCSP support? The
specification
itself only seems to talk about the first purpose (6.3) by
saying:
Optionally, the Diameter node MAY check the status of
certificates using another mechanism, such as Online Certificate
Status
Protocol (OCSP) [9].
According to this paragraph, OCSP support is
optional. However, when
discussing about issue 125, we reached an agreement
by which
OCSP-Responses AVP in DSAA is optional.
I've got two
concerns:
- Does a Diameter implementation supporting CMS Sec have to
support
online and CRL validation functionality? Is it mandatory to support
one, both? Is it optional?
- What happens when after a DSAR requesting
an OCSP response arrives
to a Diameter node that doesn't support OCSP? I
suppose than no
OCSP-Responses AVP is included in the DSAA, so that the
iniciator
deduces that OCSP isn't supported.
Requested change:
Including a paragraph stating which certificate validation mechanisms
must support a CMS-compliant and how mandatory they are.
Adding a
sentence to the first paragraph of page 12 (3.1) saying
something like:
If the sender of the DSAA does not support OCSP, it would simply
return a DSAA without any OCSP-Responses AVP.
Submitter name: Miguel A. Monjas
Submitter email address:
ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-08-24
Reference:
Document: Base-07, CMS-02
Comment type: T
Priority: S
Section: (base) 2.7, (CMS) 6.2
Rationale/Explanation of issue:
As stated in (base) 2.7:
Relay agents MUST NOT reorder AVPs, and
proxies SHOULD NOT
reorder AVPs.
However, in (CMS) 6.2:
All
AVPs to be encrypted are concatenated, and the encryptor is
free to order
AVPs in whatever way it chooses.
My deduction is that the encryption of
AVPs in a proxy acting as a CMS
proxy on behalf of a client would break the
requirement in (base) 2.7
since the receiver would never know which order
was the original (of
course that route-related AVPs are not encryptable, so
that its order
would never change).
Requested change:
To
rephrase the requirement in (base) 2.7 in order to take into
account what is
stated in (CMS) 6.2
Submitter name: Pat Calhoun
Submitter email address:
pcalhoun@bstormnetworks.com
Date first submitted: 2001-08-27
Reference:
Document: NASREQ-07
Comment type: T
Priority: S
Section: 3.1.1.x
Rationale/Explanation of issue:
The current NASREQ specification
doesn't allow for CHAP extensibility
which RFC 1994 allows.
Requested change:
Introduce a new CHAP-Algorithm AVP
Submitter name: Pat Calhoun
Submitter email address:
pcalhoun@bstormnetworks.com
Date first submitted: 2001-08-27
Reference:
Document: NASREQ-07
Comment type: T
Priority: S
Section: 2.1.6,
7.2.5.4, 7.2.5.5, 7.2.5.6, 7.2.5.7
Rationale/Explanation of issue:
The NASREQ specification requires the following changes:
-
Replace TBD for IPv6 RADIUS attribute numbers to the values found
in RFC
3162.
- Remove AES as a possible key type in section 2.1.6
- Change WEP2
to WEP-128 as a possible key type in section 2.1.6
- Include a reference to
WEP.
Submitter name: Fredrik Johansson
Submitter email address:
fredrik@ipunplugged.com
Date first submitted: August 13, 2001
Reference:
Document: MIP-07
Comment type: T
Priority: 1
Section: 5-6
Rationale/Explanation of issue:
I'm re-submitting a part of issue
110 that wasn't a editorial issue.
Section 5-6 has to be rewritten to be
in line with
draft-ietf-mobileip-aaa-key-08.txt
Today these sections
talks about how keys should be distributed, as the
aaa-key draft has changed
to distribute key-material, this section has to be
updated to reflect that.
I'v had a try to change the sections to reflect the changes. A new AVP
is
also defined called MIP-Key-Material AVP.
/Fredrik
5.0 Key Distribution Center
The mobile node and mobility
agents use registration keys to compute
authentication extensions applied to
registration messages, as
defined in [4]: Mobile-Foreign, Foreign-Home and
Mobile-Home. If
registration keys are requested the AAA server(s) MUST
create key-
material after the Mobile Node is successfully authenticated and
authorized.
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 [9].
The Authorization-Lifetime AVP contains the number
of seconds before
registration keys destined for the Home Agent and/or
Foreign Agent
expire. A value of zero indicates infinity (no timeout).
The SPI values are used as key identifiers, meaning that each
registration 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 [15], while the Home Agent
allocates the
Mobile-Foreign, Mobile-Home and Foreign-Home SPIs.
Once the registration
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.
Each registration key that is generated by AAA will generally be
distributed to two parties; for instance, a Mobile-Foreign key goes
to
both a mobile node and a foreign agent. To the mobile node it is
sent as key
material and to the foreign agent as en encoded key. The
methods by which
the key is encoded will depend upon the security
associations available to
the AAA server and each recipient of the
key. These methods will often be
different for the two recipients,
so that the registration key under
consideration has to be encoded
twice.
See sections 6.0 for details
about the format of the AVPs used to
transport the registration keys.
5.1 Distributing the Mobile-Home Registration Key
If the
mobile node does not have a Mobile-Home registration 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
registration key, and encode
it for eventual consumption by the
mobile node and home agent.
If
the home agent is in the home domain, then AAAH can directly
encode the
Mobile-Home registration 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 domain, the
AAAH does not transmit the HAR to the home agent,
but instead transmits the
HAR to the AAAF. When the AAAF receives the
HAR, it first allocates a home
agent, and then issues the HAR for
that home agent.
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 [4].
For this purpose, AAAH includes the
Mobile-Home registration key-material
into a MIP-MN-to-HA-Key AVP,
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 [15] 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. Using the
key material it calculates the key as defined in [4] and encodes it
into
a MIP-HA-to-MN-Key AVP. The key material is also included in the
MIP-MN-to-HA-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 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
registration 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.
5.2 Distributing the
Mobile-Foreign Registration Key
The Mobile-Foreign registration key
material is also generated by
AAAH (upon request), so that it can be added
into a
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 [15] 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. Most of the considerations for distributing the
Mobile-Foreign
registration key are similar to the distribution of the
Mobile-Home
Registration Key.
Upon receipt of the HAA, if MN-FA keying was requested
the AAAH
creates the MIP-FA-to-MN-Key AVP, using the SPI in the
MIP-FA-to-MN-
SPI, and includes the AVP in the AMA. The key is calculated
using the
same method as defined in the MIP-MN-to-FA-Key. 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.
5.3 Distributing the
Foreign-Home Registration Key
If the home agent is in the home domain,
then AAAH has to generate
the Foreign-Home registration key. Otherwise, it
is generated by
AAAF.
In either case, the AAA server encodes the
registration key into a
MIP-HA-to-FA-Key AVP and includes that AVP as part
of the HAR message
sent to the home agent, and waits for the HAA message to
be returned.
Upon receipt of the HAR, the home agent recovers the
Foreign-Home
registration key, allocates an SPI to be used with the key, and
uses
this key to create a Foreign-Home authentication extension to the
Registration Reply message. The allocated SPI is included in the
HAA's
MIP-FA-to-HA SPI AVP.
Upon receipt of the HAA, the Diameter server
responsible for key
allocation adds the MIP-FA-to-HA Key AVP, using the SPI
in the MIP-
FA-to-HA-SPI, and includes the AVP in the AMA.
5.4
Key Distribution Example
Figure 9 provides an example of subsequent
Mobile IP message
exchange, assuming that AAAH distributed registration keys
for all
three MN-FA, FA-HA and HA-MN authentication extensions.
Mobile Node Foreign Agent Home Agent
----------- -------------
----------
Reg-Req(MN-HA-Auth, MN-FA-Auth)-------->
Reg-Req(MN-HA-Auth, FA-HA-Auth)-------->
<--------Reg-Rep(MN-HA-Auth, FA-HA-Auth)
<--------Reg-Rep(MN-HA-Auth, MN-FA-Auth)
Figure 9: Mobile IP
Message Exchange
6.0 Key Distribution Center (KDC) AVPs
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. This requires that the
AAAH create
Mobile-IP Registration Keys, and that these keys be
distributed to the three
mobile entities, via the Diameter Protocol.
AAA servers supporting the
Diameter Mobile IP Application MUST
implement the KDC AVPs defined in this
document. In other words, AAA
servers MUST be able to create three
registration keys: the Mobile-
Home, Mobile-Foreign, and Foreign-Home keys.
The names of the KDC AVPs indicate the two entities sharing the
security association defined by the encrypted 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
encrypted in a way that
allows it to be recovered by the mobile node.
If strong authentication
and confidentiality of the registration keys
is required, it is recommended
that the CMS security application [9]
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.
+---------------------+
| AVP Flag rules |
|----+-----+----+-----|----+
AVP Section | | |SHLD| MUST|MAY |
Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr|
-----------------------------------------|----+-----+----+-----|----|
MIP-Algorithm- 345 6.9 Enumerated | M | P | | V | Y |
Type | | | | | |
MIP-FA-to-HA-Key 328 6.2 Grouped | M | P | | V | Y |
MIP-FA-to-HA-SPI
318 6.13 Unsigned32 | M | P | | V | Y |
MIP-FA-to-MN-Key 326 6.1 Grouped | M
| P | | V | Y |
MIP-FA-to-MN-SPI 319 6.12 Unsigned32 | M | P | | V | Y |
MIP-HA-to-FA-Key 329 6.3 Grouped | M | P | | V | Y |
MIP-HA-to-MN-Key
332 6.4 Grouped | M | P | | V | Y |
MIP-MN-to-FA-Key 325 6.5 OctetString| M
| P | | V | Y |
MIP-MN-to-HA-Key 331 6.6 OctetString| M | P | | V | Y |
MIP-Peer-SPI 342 6.7 Unsigned32 | M | P | | V | Y |
MIP-Replay-Mode 346
6.11 Enumerated | M | P | | V | Y |
MIP-Session-Key 343 6.8 OctetString| M |
P | | V | Y |
MIP-Key-Material TBD 6.9 OctetString| M | P | | V | Y |
6.1 MIP-FA-to-MN-Key AVP
The MIP-FA-to-MN-Key AVP (AVP Code
326) is of type Grouped, and
contains the Foreign Agent's session key, which
it shares with the
Mobile Node. Its Data field has the following ABNF
grammar:
MIP-FA-to-MN-Key ::= < AVP Header: 326 >
{
MIP-Peer-SPI }
{ MIP-Algorithm-Type }
{ MIP-Session-Key }
* [ AVP ]
6.2 MIP-FA-to-HA-Key AVP
The MIP-FA-to-HA-Key AVP (AVP Code
328) is of type Grouped, and
contains the Foreign Agent's session key, which
it shares with the
Home Agent. Its Data field has the following ABNF
grammar:
MIP-FA-to-HA-Key ::= < AVP Header: 328 >
{
MIP-Peer-SPI }
{ MIP-Algorithm-Type }
{ MIP-Session-Key }
* [ AVP ]
6.3 MIP-HA-to-FA-Key AVP
The MIP-HA-to-FA-Key AVP (AVP Code
329) is of type Grouped, and
contains the Home Agent's session key, which it
shares with the
Foreign Agent. Its Data field has the following ABNF
grammar:
MIP-HA-to-FA-Key ::= < AVP Header: 329 >
{
MIP-Algorithm-Type }
{ MIP-Replay-Mode }
{ MIP-Session-Key }
* [ AVP
]
6.4 MIP-HA-to-MN-Key AVP
The MIP-HA-to-MN-Key AVP (AVP
Code 332) is of type Grouped, and
contains the Home Agent's session key,
which it shares with the
Mobile Node. Its Data field has the following ABNF
grammar:
MIP-HA-to-MN-Key ::= < AVP Header: 332 >
{
MIP-Algorithm-Type }
{ MIP-Replay-Mode }
{ MIP-Session-Key }
* [ AVP
]
6.5 MIP-MN-to-FA-Key AVP
The MIP-MN-to-FA-Key AVP (AVP
Code 325) is of type Grouped, and
contains the Mobile Node's session key,
which it shares with the
Foreign Agent. The Home Agent uses this AVP in the
construction of
the Mobile IP "Unsolicted MN-FA Key from AAA Subtype"
extension [15].
The SPI in the extension's FA SPI field is allocated by the
Home
Agent, but it SHOULD take into consideration the SPI requested by the
Mobile Node in the "MN-FA Key Request From AAA Subtype" extension.
MIP-MN-to-FA-Key ::= < AVP Header: 325 >
{ MIP-Algorithm-Type
}
{ MIP-Replay-Mode }
{ MIP-Key-Material }
* [ AVP ]
6.6
MIP-MN-to-HA-Key AVP
The MIP-MN-to-HA-Key AVP (AVP Code 331) is of type
Grouped, and
contains the Mobile Node's session key, which it shares with
the Home
Agent. The Home Agent uses this AVP in the construction of the
Mobile
IP "Unsolicted MN-HA Key from AAA Subtype" extension [15]. The SPI in
the extension's HA SPI field is allocated by the Home Agent, but it
SHOULD take into consideration the SPI requested by the Mobile Node
in
the "MN-HA Key Request From AAA Subtype" extension.
MIP-MN-to-FA-Key ::=
< AVP Header: 331 >
{ MIP-Algorithm-Type }
{ MIP-Replay-Mode }
{ MIP-Key-Material }
* [ AVP ]
6.7 MIP-Peer-SPI AVP
The MIP-Peer-SPI AVP (AVP Code 342) is of type Unsigned32, and
contains the Security Parameter Index to use to reference the key in
the
associated MIP-Session-Key AVP. The SPI created MUST NOT be a
value between
zero (0) and 255, which is the reserved namespace
defined in [4].
6.8 MIP-Session-Key AVP
The MIP-Session-Key AVP (AVP Code
343) is of type OctetString and
contains the Session Key to be used between
two Mobile IP entities.
6.9 MIP-Key-Material AVP
The
MIP-Key-Material AVP (AVP Code TBD) is of type
OctetString and contains the
Session Key Material to be used to
calculate the Session Key between two
Mobile IP entities.
6.10 MIP-Algorithm-Type AVP
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 [4]
2 HMAC-MD5 [13]
3 SHA-1 [17]
6.11 MIP-Replay-Mode AVP
The MIP-Replay-Mode AVP (AVP Code
346) is of type Enumerated and
contains the replay mode the Home Agent
should use when
authenticating the Mobile Node.
The following values
are supported (see [4] for more information):
0 None
1 Timestamps
2 Nonces
6.12 MIP-FA-to-MN-SPI AVP
The MIP-FA-to-MN-SPI AVP
(AVP Code 319) is of type Unsigned32, and
contains the Security Parameter
Index the Foreign Agent is to use to
refer to the session key it shares with
the Mobile Node. The SPI
created MUST NOT be a value between zero (0) and
255, which is the
reserved namespace defined in [4]. This AVP MAY be added
in the HAA
message by the Home Agent for the AAAH's use in MIP-Peer-SPI AVP
of
the MIP-FA-to-MN-Key AVP.
6.13 MIP-FA-to-HA-SPI AVP
The MIP-FA-to-HA-SPI AVP (AVP Code 318) is of type Unsigned32, and
contains the Security Parameter Index the Foreign Agent is to use to
refer to the session key it shares with the Home Agent. The SPI
created
MUST NOT be a value between zero (0) and 255, which is the
reserved
namespace defined in [4]. This AVP MAY be added in the HAA
message by the
Home Agent for the AAAH's use in MIP-Peer-SPI AVP of
the MIP-FA-to-HA-Key
AVP.
Submitter name: Miguel A. Monjas
Submitter email address:
ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-08-27
Reference:
http://www.merit.edu/mail.archives/aaa-wg/2001-08/msg00083.html and
http://www.merit.edu/mail.archives/aaa-wg/2001-08/msg00101.html
Document: CMS-02
Comment type: T
Priority: S
Section:
Rationale/Explanation of issue:
According to the CMS draft (3.1,
Usage Scenario), the implementations
of CMS may cache DSA setup information.
Also, they must honor the TTL
setting and re-validate certificates before
using cached data. The
draft looks a little bit confused, so that Stephen
Farrel proposed and
additional text in order to make it clear (see
http://www.merit.edu/mail.archives/aaa-wg/2001-08/msg00101.html).
His basic statement was the following: Depending on the parameters of
the certificates belonging to the certificate chain (or belongint to
the
OCSP response or the CRL), a "safe" period with no revocation
checks will be
computed (I assume that if this safe period is smaller
than the length of
the DSA, a revocation check must be done once the
safe period ends; but in
the other hand, if the safe period is bigger
than the DSA length, the
revalidation must be done once the DSA
expires). Additional checks might be
done depending on the local PKI
policy.
However, from my humble
point of view, the text just partially solved
the problem since its approach
was very PKI-centric.
I'll explain my approach with some figures. This
is the scenario as
far as I understood it:
____________________________________________
DSA |
================================== |
| | | |
beginning of | | |
the DSA t1 (any special time | |
in which a message | |
is issued) |
|
end of |
the DSA |
t2 (other
issued message)
What I
wanted to assure is that in t1, the implementation may choose
not to
revalidate the certificates. But in t2, the implementation must
revalidate
the certificates. This statement wasn't clear (in my
oppinion), and I wanted
to make it more explicit.
Requested change:
The following
paragraph must be changed:
Implementations MAY cache the information
required to establish a
DSA, but MUST honor time-to-live settings and MUST
re-validate
certificates (possibly including revocation checks) before using
cached data.
With this paragraph (which includes Stephen's
contributions):
Implementations MAY cache the information required to
establish a
DSA. However, they MUST honor time-to-live settings so that
certificates MUST re-validated (possibly including revocation
checks)
once the DSA has expired.
Revalidations MIGHT 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, if an
implementation did not support certificate revocation checks, then
the
"safe" period would be from the time of initial validation
until the
earliest notAfter time in the set of certificates in the
path. An
implementation which does support certificate revocation
checks will
typically be able to calculate a "safe" period based
additionally on the
earliest nextUpdate field in a CRL or OCSP
response. Basically, the safe
period is from the time of
certificate validation to the earliest value from
the set of
notAfter and nextUpdate fields encountered during certificate
validation.
However, implemetors should note that CAs MAY issue
additional
CRLs before the nextUpdate period. Generally it is a matter of
local PKI policy as to whether an implementation will make
additional
checks even during the calculated "safe" period. For
the purposes of this
specification implementations are NOT REQUIRED
to make such checks and MAY
assume that no re-validation of
certificates is required during the "safe"
period defined above.
Submitter
name: Miguel A. Monjas
Submitter email address:
ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-08-27
Reference:
Document: CMS-02
Comment type: T
Priority: 1
Section:
Rationale/Explanation of issue:
S/MIME is used as the
"encoding" scheme within Diameter CMS Security
Application. However, I miss
an explainatory chapter introducing
S/MIME (and CMS), saying which
relationship there is bewteen them, why
the name of the specification is CMS
Security and not S/MIME security,
and why it has been chosen (apparently the
reason is darkly buried in
6.1 "This method of encapsulating AVPs allows
existing S/MIME toolkits
to be used without changes in order to provide
authentication within
the Diameter application layer.")
Besides, no
mention about MIME encoding is made in 6.2
(CMS-Encrypted-Data AVP). The way
in which several EnvelopedData
values are encoded in a single
CSM-Enveloped-Data AVP isn't defined (I
assume that no nesting is employed
since an "outside" envelope hides
all the content it's enveloping so that
only the recipient of this
external envelope can extract the contents).
Requested change:
a) add an introductory chapter explaining the
relationship between the
different standards involved (along with the
reasons to use it and so
on)
b) add clarifying text to describe the
MIME operations involved in CMS
Security application
Submitter name: Fredrik Johansson
Submitter email address:
Fredrik@ipunplugged.com
Date first submitted: 2001-08-29
Reference:
Document: base
Comment type: E
Priority: 1
Section:
Rationale/Explanation of issue:
There are some missing states in the
authorization session state machine.
1. It is optional to send a ASR
when cleaning up a session on a home server,
however there is no indication
on what state to go to when doing so. My
guess is that you should go to
Disconnect and wait for a ASA. Since this is
an optional feature I'm not
sure it should be in the state machine. However,
if you send an ASA there
has to be a state indicating how to get from
Disconnect to Closed.
Requested Change:
Add the following state
Discon ASA
Received Cleanup Closed
BTW, it might just be a cut'n past error, the
Open ASA Received Cleanup Closed
state should not exist, if you have
sent an ASR you should not be in Open,
so replace the latter with the first
state above.
2. There is no state where the home server can receive a
service specific
auth. request and extend access and stay in open.
Requested Change:
Add a the following state:
Open Successful
Service-Specific Extend Open
Authorization Request received Access
3. There is no state where the home server can receive a STR send a STA
and
go to Closed
Requested Change:
Add the following state:
Open receive STR send STA Closed
4. According to the following
state:
Open Authorization-Lifetime Send Open
expires on access device
service
specific
auth req
It's not clear that an access device
can not send a Service-Specific Auth.
request on Authorization-Lifetime
expiration unless it has received a MIP
registration request or PPP request.
Requested Change:
Can it be made clearer that if no such message has
been received it should
send a STR and go to Disconnect?
Submitter name: Miguel A. Monjas
Submitter email address: ecemaml@rioja.es.eu.ericsson.se
Date first
submitted: 2001-08-29
Reference:
Document: CMS-02
Comment type: E
Priority: S
Section: abstract, 1.1, 3.1, 3.4, 5.0, 6.1, 6.2
Rationale/Explanation of issue:
The purpose of Diameter CMS Security
Application is to achieve some
security services:
[1] (data origin)
authentication
[2] confidentiality
[3] integrity
[4] non-repudiation
(with proof of origin)
To achieve them, some techniques are used:
- digital signatures + digital certificates provide [1], [3] and [4]
(though to achieve only [3] maybe MAC would be enough)
- encryption
(using asymmetric techniques to encrypt a content
encryption key and this
CEK for bulk encryption) provides just [2]
- encryption + digital signatures
+ digital certificates provide [1],
[2], [3] and [4]
However, not
all the security services are listed neither the specific
techniques are
linked with the services.
Requested change:
Replace the second
paragraph of the abstract with the following text:
This Diameter
application describes how a security association is
established by two peers
through agents, and how authentication
integrity, confidentiality and
non-repudiation (with proof of
origin) are achieved using a mixture of
symmetric and asymmetric
transforms, by encapsulating Cryptographic Message
Syntax (CMS)
data within AVPs. CMS is also used to carry X.509 certificates.
Two main techniques are so that used. Digital signatures (along
with
digital certificates) provide authentication, integrity and
non-repudiation.
Encryption provides confidentiality (using
asymmetric techniques to encrypt
a content encryption key and
this key for bulk encryption). Both techniques
can be used
together to provide all the specified security services.
Replace the paragraph below the figure 2 (1.1) wiht the following:
This document defines the Diameter commands that are used to
establish a DSA through Diameter agents, and specifies how
encapsulating
CMS objects [3] in Diameter AVPs can provide
authentication, integrity,
confidentiality and non-repudiation.
The CMS object MAY also be used to
transport X.509
certificates and revocation lists.
Replace the third
paragraph in 3.1 with the following:
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 things,
as well as which public key(s) to use.
Replace the second last paragraph in 3.1 with the following:
Depending on the security technique required (digital
signature,
encryption or both), then the originating node
prepares the CMS related AVPs
as required.
Replace the second paragraph in 3.4 with the following:
Note that though the use of symmetric encryption might be used
to
provide integrity or confidentiality but does not provide
non-repudiation
with proof of origin.
Replace the second paragraph in 5.0 with the
following:
Although the example doesn't specifically use bi-directional
digital signature and encryption, this feature is supported.
Replace
the first sentence of second last paragraph in 6.1 with the
following:
The eContent field of the EncapsulatedContentInfo structure MUST be
absent since the digital signature covers data outside of the
object.
Replace the fourth paragraph in 6.2 with the following:
When
AVPs are to be both encrypted and signed, the CMS-
Encrypted-Data AVP MUST
be created first.
Submitter name: Miguel A. Monjas
Submitter email
address: ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-08-29
Reference:
Document: CMS-02
Comment type: T
Priority: S
Section:
Rationale/Explanation of issue:
Which key length is
employed when RSA is used? I haven't seen any
negociation schema.
Requested change:
Add clarifying text
Submitter name: Adrian Constantin
Submitter email address:
adrian.constantin@nokia.com
Date first submitted:
Reference:
Document: Base 07
Comment type: E
Priority: 1
Section: 3.0 and
6.2
Rationale/Explanation of issue:
There is a consensus about
copying the end-to-end id from the request in the
answer issued by a home
server, but the specification doesn't clearly state
it.
Requested
Change:
In section 3.0, End-to-End Identifier paragraph, change from
"Senders of request or answer messages MUST
insert a unique
identifier on each message, by incrementing the
identifier by one (1)."
to:
"Senders of request messages MUST
insert a unique
identifier on each message, by incrementing the
identifier by one (1). The
originator of an Answer message
MUST ensure that the End-to-End Identifier
field contains the same
value that was found in the corresponding request."
In section 6.2 add the following text:
"- The same End-to-End
identifier in the request is used in the
answer."
Submitter name: John Loughney
Submitter email address:
john.loughney@nokia.com
Date first submitted: August 20, 2001
Reference:
Document: Base
Comment type: T
Priority: 1
Section: In section
5.5.4
Rationale/Explanation of issue:
A minor editorial nit, in
section 5.5.4, 3rd paragraph, 2nd sentence:
When a transport failure is
detected, all messages in the queue are
sent to an alternate agent, if
possible. An example of a case where
it is not possible for forward the
message to an alternate server is
when the message has a fixed destination,
and the unavailable peer is
the message's final destination (see
Destination-Host AVP).
The sentence isn't so clear - do you mean this
(changed text in CAPS):
An example of a case where it is not possible TO
forward the message to an
alternate server is when the message has a fixed
destination,
- or it could be stated as:
An example of a case
where it is not possible for FORWARDING the message to
an alternate server
is when the message has a fixed destination,
Submitter name:
Miguel A. Monjas
Submitter email address: ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-09-03
Reference:
http://www.merit.edu/mail.archives/aaa-wg/msg02002.html
Document: Base-07,
CMS-02
Comment type: T
Priority: 1
Section:
Rationale/Explanation of issue:
Apart from the error codes related
to OCSP there are only two other
errors: DIAMETER_KEY_UNKNOWN and
DIAMETER_INVALID_CMS_DATA.
The former is related to the locally stored
encryption key (symmetric)
while the later talks about CMS-*-Data AVPs.
The Base Protocol draft (7.1.3) states:
DIAMETER_INVALID_CMS_DATA 3006
The Request did not contain a valid
CMS-Data [11] AVP.
While in the CMS Security draft (7.2) it is said
that:
DIAMETER_INVALID_CMS_DATA 5019
This error code is returned
when a CMS-Data AVP is received
with an invalid ContentInfo object.
As stated in the reference mail, my first concern is about the
definition (which is slightly different) and the type of error (in the
base draft it's a protocol error while in the CMS draft it's a
permanent
failure).
My second concern is about the error situations related to
CMS. I can
foresee the following:
- In a DSA setup dialogue, the
initiator can provide a set of "direct
trust" CA which isn't supported by
the receiver. I understand that a
permanent failure code error must be
issued.
- In a DSA setup dialogue, the initiator, once received the
DSAA,
might fail to verify the conditions listed in section 3.1 of the CMS
draft. Like no ACK is foreseen in the specification, I understant that
when in a subsequent Diameter message, the initiator receives an AVP
related to CMS, this node should issue a permanent error. For example,
DIAMETER_NO_DSA_ESTABLISHED
- If a Diameter node receives a message
with encrypted or signed AVPs
once the DSA has expired (or even with no
previous DSA established),
the node should issue another error. Maybe,
DIAMETER_DSA_EXPIRED (or
maybe making use of the former code suggested).
Requested change:
I suggest unifying the definition of
DIAMETER_INVALID_CMS_DATA in both
drafts (or maybe dropping the mention of
the error in base draft).
For the rest of concerns, I'd add some
clarifying text in order to
state wheter those are really error situations
or not.
Submitter name: Miguel A. Monjas
Submitter email address:
ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-09-03
Reference: http://www.merit.edu/mail.archives/aaa-wg/msg02002.html,
http://www.merit.edu/mail.archives/aaa-wg/msg02022.html
Document:
Base-07, CMS-02
Comment type: T
Priority: 1
Section: Base (7.1.3),
CMS (6.2)
Rationale/Explanation of issue:
Apart from what I wrote in
http://www.merit.edu/mail.archives/aaa-wg/msg02022.html, I'd like to
add
the following:
The Base Protocol draft (7.1.3) states:
DIAMETER_CMS_SECURITY 3008
A proxy has detected that CMS security
has been applied to
portions of the Diameter message, and the proxy does not
allow
this security mode since it needs to alter the message by
applying
some local policies.
I suppose that this error code has been superseded
by the error codes
defined in CMS-02 1.2 (Establishing Security
Relationships through
proxy agents).
Also, the CMS-02 draft (section
6.1) says that:
If the signature cannot be verified correctly, a
response with the
Result-Code AVP set to DIAMETER_INVALID_AUTH [1] MUST be
returned.
I haven't found such a error code in Base-07
Requested
change:
a) Drop error 3008 from base draft.
b) Correct which error
code is issued when the signature isn't
properly verified.
Submitter
name: Miguel A. Monjas
Submitter email address:
ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-09-04
Reference:
Document: CMS-02
Comment type: T
Priority: 1
Section: 6.2
Rationale/Explanation of issue:
In chapter 6.2 it's
written down that:
When a conforming implementation receives a Diameter
message which
contains encrypted AVPs within a CMS EnvelopedData, the
recipient
MUST check to see if it is on the list of recipients specified in
the
RecipientInfos of the EnvelopedData. If not, the recipient MAY
choose
to process the message or indicate an error. If the recipient is
in
the RecipientInfos and an error occurs during decryption, then the
recipient MUST indicate an error.
Two error situations are pointed:
- When the DSA recipient isn't in the list of recipients of
EnvelopedData.
- Being in the recipient list, an error occurs during
decryption.
However, no Result-Code is provided in such situations.
Requested change:
a) create appropriate result codes (maybe
DIAMETER_NO_DSA_RECIPIENT
and DIAMETER_DSA_DECRYPTION_FAILED)
b) clarify
the previous paragraph including references to appropriate
result codes
Submitter name: Miguel A. Monjas
Submitter email address:
ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-08-04
Reference:
Document: CMS-02
Comment type: E
Priority: S
Section: 3.1
Rationale/Explanation of issue:
The following item
doesn't follow the convention to use references:
- the certificate chain
selected is cryptographically correct,
passes the (relevant parts of the)
rfc2459 path validation
algorithm and terminates at a CA mentioned in the
DSAR message
The rest of references uses the form [x], where x is the
number of the
reference in 11.0
Requested change:
Replace
the quoted paragraph with the following:
- the certificate chain
selected is cryptographically correct,
passes the (relevant parts of
the)path validation algorithm
specified in [4] and terminates at a CA
mentioned in the
DSAR message
Submitter name: Miguel A. Monjas
Submitter email address:
ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-09-04
Reference:
http://www.merit.edu/mail.archives/aaa-wg/2001-08/msg00229.html
Document: CMS-02
Comment type: T
Priority: 2
Section: 4.3
Rationale/Explanation of issue:
The establishment of DSAs through
evil proxies is usually a tricky
task. As stated in our discussion about
issue 136, two main scenarios
are considered:
- The access device
does not have the cryptographic ability to
handle
the CMS functions
locally, and therefore requests such services
from the local agent, such an
an aggregating relay or proxy agent.
The NAS may have been configured to
always issue a PDSR to its
local agent for CMS services. In such cases, the
agent MUST select
the values for the DSA-TTL and provide the appropriate
Local-CA-Info and the expected OCSP response from the DSA peer.
-
The access device has the cryptographic ability to perform the CMS
functions, but a proxy agent is in the route towards the home
server,
and it returned a failure to the DSAR messages stating
that
it was not
willing to allow the DSA to traverse through it. Such
agents MAY attempt to
re-use the values from the initial DSAR sent
by the access device.
The ABNF grammar of a PDSR AVP is:
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Auth-Application-Id }
[ DSAR-Target-Domain ]
[ Origin-State-Id ]
* [ AVP ]
* [ Proxy-Info ]
* [ Route-Record
]
I'd like to focus in the second scenario. The agent has issued a DSAR
including the Destination-Realm AVP (let's use abc.com). An evil proxy
is in the route towards the home server, so that the evil proxy issues
a
DSAA including the Origin-Host and the Origin-Realm AVPs (and a
DIAMETER_CAN_BE_A_COOL_CMS_PROXY result code). Following, the agent
issues a PDSR. Well, it will include again abc.com (but as
DSAR-Target-Domain) and the value of the Origin-Realm of the previous
DSAA as Destination-Realm of the PDSR.
However, it may happen that,
once issued a PDSR with only a
Destination-Realm, it will be routed to other
proxy in the same realm.
Maybe this proxy doesn't support CMS (so that it
issues a
DIAMETER_AINT_CMS_PROXY). Or maybe it supports CMS but, not being
the
same proxy it won't be able to reuse any of the previously sent
parameters (parameters sent in the previous DSAR).
I understand
that, in this scenario, a Destination-Host AVP must be
included in the PDSR.
So that an optional Destination-Host AVP must be
included in the ABNF
grammar of PDSR.
Requested change:
a) Change the ABNF grammar of
PDSR AVP including an optional field:
[ Destination-Host ]
b)
Add explanatory text to 4.3
Submitter name: Miguel A. Monjas
Submitter email address:
ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-09-05
Reference:
Document: CMS-02
Comment type: T
Priority: 1
Section: 1.5
Rationale/Explanation of issue:
In CMS-02 (section
1.5), it's stated that:
" one of participants
of a DSA (specifically
the one in the home network) MUST belong to
the same realm as the user being
authorized."
May I suppose that otherwise, a
DIAMETER_AUTHORIZATION_REJECTED result
code is issued (or it should be a
newly defined CMS-Sec specific
error)
Requested change:
Include a specific mention to DIAMETER_AUTHORIZATION_REJECTED or
defining a new result code.
Submitter name: Jari Arkko
Submitter email address:
jari.arkko@ericsson.fi
Date first submitted: September 6, 2001
Reference: -
Document:base
Comment type: T
Priority: 1
Section: 7.2
Rationale/Explanation of issue:
Diameter has a
couple of messages such as Device-Watchdog-
Request that do not include a
session id in the request.
Yet section 7.2 requires that error replies to
request
have the session id. How can we make an error reply
to
Device-Watchdog-Request, for instance? And section
6.2 then talks about
answers, and says that Session-Id
must be copied where it exists. Perhaps
this is the
right approach, but should the BNF in 7.2 be changed
then?
Other messages without Session-Id are Capabilities-
Exchange-Req and
Disconnect-Peer-Request.
Requested change:
Perhaps the BNF in
7.2 should be changed, or at
least words added. I'm not sure how to change
the
BNF, given that we can't indicate a fixed position
AVP that is
optional...
If added words is enough, then put in at the end
of 7.2:
"Note also that the Session-Id should be
present if and only if the
corresponding request
contained it."
Submitter
name: Miguel A. Monjas
Submitter email address:
ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-08-22
Reference:
Document: CMS-02
Comment type: T|E
Priority: S|1|2
Section:
Rationale/Explanation of issue:
Some errors and its
result codes (not exhaustive):
1. A Diameter message with a
CMS-Signed-Data AVP including a digital
signature and no AVP with its 'P'
bit set:
DIAMETER_AVP_NOT_ALLOWED (existing in base draft)
2. A
Diameter message without any CMS-Signed-Data AVP and some AVPs
with its 'P'
bit set:
DIAMETER_MISSING_AVP (existing in base draft)
3. A Diameter
message including CMS Security Application AVPs with no
DSA established:
DIAMETER_NO_DSA_ESTABLISHED (existing in CMS-03)
4. A Diameter node
not being able to set up a DSA upon receiving a
DSA-Request due to problems
different from digital signature
verification
DIAMETER_NO_DSA_ESTABLISHED (existing in CMS-03)
5. A Diameter node
not being able to set up a DSA upon receiving a
DSA-Answer due to any
problem
DIAMETER_NO_DSA_ESTABLISHED (in subsequent Diameter messages if a
CMS-related message is received) (existing in CMS-03)
6. A Diameter
node not supporting certificate revocation checks has
calculated a safe
period based on the expiration dates of the
certificates. Once this safe
period has finishing, a CMS-Signed-Data
arrives without any certificate
??
7. A Diameter message including CMS Security Application AVPs
with the
DSA expired (only if the Diameter node can "remember" past DSAs)
DIAMETER_DSA_EXPIRED (existing in CMS-03)
8. A Diameter message
containing a CMS-Signed-Data AVP but with a
different set of AVPs with its
'P' bit set to the ones chosen in the
DSA establishment.
??
9. A
Diameter message containing a CMS-Signed-Data AVP that doesn't
include any
digital signature made by the node included in the
Origin-Host AVP
DIAMETER_CONTRADICTING_AVPS?? (existing in base draft)
10. A
Diameter message containing a CMS-Signed-Data AVP. No
appropriate digital
certificate (regarding the identity included in
the Origin-Host AVP) is
available, neither included in the Diameter
message as CMS-Cert AVP nor
available in the local cache.
DIAMETER_INVALID_AUTH?? (existing in CMS-03)
11. A Diameter message containing a CMS-Signed-Data AVP. The digital
signature is invalid.
DIAMETER_INVALID_AUTH (existing in CMS-03)
12. The DSA participant in the home network doesn't belong to the same
realm as the user being authorized.
DIAMETER_AUTHORIZATION_REJECTED??
(existing in base draft)
13. An OCSP response is requested. The Diameter
server supports OCSP
querying. However, the OCSP responder isn't available
(the server gets
a timeout)
DIAMETER_OCSP_NOT_SUPPORTED?? (existing in
CMS-03)
14. A Diameter message containing a CMS-Encrypted-Data AVP. The
recipient isn't on the list of recipients specified in the
RecipientInfos of the EnvelopedData and decides to indicate an error.
DIAMETER_NO_DSA_RECIPIENT??
15. A Diameter message containing a
CMS-Encrypted-Data AVP. An error
occurs during decryption
DIAMETER_DSA_DECRYPTION_FAILED??
Requested change:
a) Decide
if all the situations quoted in which no error code is
mentioned needs a new
error code (if so create them)
b) Decide whether the suggested result codes
are correct
c) Once decided the result code for any situation, include a
mention
of such result code (or the section) in the proper place.
d)
Clarify what happens when a DSA can't be established because the
initiator
(once received the DSAA) fails to check the conditions
listed in 3.1. Is is
necessary to issue a NAK containing a
DIAMETER_NO_DSA_ESTABLISHED? Or it
sufficient to issue such result
code only when another CMS-related AVP is
inserted in subsequent
messages? It's important to take into account that
the following
paragraph (from 6.1) states that a Diameter message must be
issued
after any failed verification of a digital signature:
If the
signature cannot be verified correctly, a response with the
Result-Code AVP
set to DIAMETER_INVALID_AUTH MUST be returned.
e) Clarify the meaning of
the following paragraph in 6.1
If a receiver detects that the contents
of the CMS-Signed-Data AVP
are invalid, it SHOULD return the new Result-Code
AVP value defined
in section 7.0.
Which contents are we talking
about (maybe 9 above)? Because, if it
isn't the condition, a
DIAMETER_INVALID... should be the appropriate
result code.
Submitter name: Yanqun Le
Submitter email address: yanqun.e@nokia.com
Date first submitted: 2001-09-06
Reference:
Document: Base-07
Comment type: T
Priority: 2
Section: 5.5.3 and 5.1
Rationale/Explanation of issue:
In section 5.1, it said:
three
watchdog messages are exchanged with accepted round trip times, and
the
connection to the peer is considered stablized.
The Problem is:
In
SUSPECT state, if a DWA is received, which action should it take?
1) send
another DWR, then which timer should it start? Tw or Tr/Tw? which
state
should it change to? Still remain in SUSPECT and waiting for sending
another
DWR or change to WAIT_DWA?
2) just change to OKAY?
I think draft 07
doesn't state clearly on it.
Submitter name: Miguel A. Monjas
Submitter email address:
ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-09-06
Reference:
http://www.merit.edu/mail.archives/aaa-wg/2001-08/msg00246.html
Document: CMS-02
Comment type: T
Priority: S
Section: 1.2, 4.4,
6.14
Rationale/Explanation of issue:
When a CMS proxy establishes a
DSA on behalf of a client, it uses its
own parameters (or maybe some of the
provided by the client in a
previous DSA attempt). Once established, it
issues a PDSAA to inform
the client about the status of the DSA. But, what
happens once the DSA
has expired? It may receive a message of the same
client with AVPs
that it (the proxy) would have protected while the DSA
existed.
Does it have to try to establish a new DSA (transparently for
the
client)? Or has to warn the client issuing a Diameter message with an
appropriate Result-Code (so that the client issues a PDSAR again)?
My idea is that the proxy should include the TTL of its established
DSA in the PDSAA in order to inform the client when it has to reissue
a
PDSAR to make the proxy establish a new DSA.
Requested change:
Add the following text to the proposed text for issue 136:
The
PDSAA MUST contain the TTL setting agreed by the proxy agent
for its DSA.
This information will allow the access device to
re-issue a PDSAR when the
proxy's DSA has expired.
Change the ABNF grammar of the PDSAA AVP (4.4),
being the result:
{
Result-Code }
{ Origin-Host }
{ Origin-Realm }
{ Auth-Application-Id
}
{ DSA-TTL }
[ Origin-State-Id ]
* [ AVP ]
* [ Proxy-Info ]
* [ Route-Record ]
Add the followig text to the description of a
DSA-TTL AVP in 6.14:
A DSA-TTL AVP MUST also be included in the PDSAA in
order to
provide information about the lenght of the DSA established by
the proxy on behalf of the access device.
Submitter name: Dirk Poertner, Yiwen Jiang
Submitter
email address: Dirk.Poertner@icn.siemens.de,
yiwen.jiang@tic.siemens.ca
Date first submitted: 2001-9-6
Reference:
Document: Base-07,
MobileIP-07, NASREQ-07, CMS-02
Comment type: E
Priority: 2
Section:
Throughout
Rationale/Explanation of issue:
There are
inconsistencies/ambiguities regarding Destination-Host AVP
throughout the
document. In older versions (< -05), it actually said that
Destination-Host MUST be present in answers. Is this area missed in the
cleanup process, or??
For example, in Base-07:
In Section
6.1,
" - a request that is not proxiable (such as CER) MUST NOT contain
either Destination-Realm or Destination-Host AVPs."
But the ABNF format
of CER and CEA listed the Destination-Host as optional.
In Section 6.2,
" - The Destination-Host and Destination-Realm AVPs MUST NOT be
present
in the answer message."
But the ABNF formats of DPA and DWA listed the
Destination-Host as
mandatory.
In the three application latest
versions, Destination-Host AVP is included
in various Answer messages.
Requested change:
Cleanup these areas to make it consistent.
Submitter name: Miguel A. Monjas
Submitter email address:
ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-09-06
Reference:
Document: CMS-02
Comment type: E-T
Priority: S
Section: 8.0
Rationale/Explanation of issue:
a) When issuing a
DSA-Request, a digital signature (by means of a
CMS-Signed-Data AVP) may be
included. If so, an appropriate CMS-Cert
must be included (unless the
certificate is included within the
SignedData estructure).
b) In a
DSA-Answer, I understand that the digital signature can be
verified by means
of the certificates in the AAA-Server-Certs, so that
a CMS-Cert isn't
necessary
Requested change:
a) Replace the row in the AVP
occurrence table regarding CMS-Cert
+-----------------------+
|
Command-Code |
|-----+-----+-----+-----+
Attribute Name | DSAR| DSAA|
PDSR| PDSA|
------------------------------|-----+-----+-----+-----+
CMS-Cert | 0-1 | 0 | 0 | 0 |
b) Clarify if a CMS-Cert is necessary
in a DSAA or if it's superseded
by a certificate present in AAA-Server-Cert
BTW, shouldn't be present Key-Hash AVP in the AVP occurrence table?
Submitter name: Miguel A. Monjas
Submitter email address:
ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-09-06
Reference:
http://www.merit.edu/mail.archives/aaa-wg/2001-08/msg00300.html
Document: CMS-02
Comment type: T
Priority: 2
Section: 1.2
Rationale/Explanation of issue:
DIAMETER_NO_COMMON_TRUST error is
introduced in section 7.2 of
CMS-Sec. However, no explicit mention to it is
done in the text. The
definition is as follows:
This error code is
returned when a receiver receives a PDSR for
which it has no common trust
with the sender, which is required
to establish the DSA.
What seems
to suggest that when a proxy receives a PDSAR from a client
when there no
exist "common trust" between them.
In which situations is considered
that there's common trust?
Requested change:
Add clarifying text
Submitter name: Miguel A. Monjas
Submitter email address:
ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-09-07
Reference:
Document: Base-07|CMS-02
Comment type: T
Priority: S
Section: 7.1.5|7.2, CMS-02 2.0
Rationale/Explanation of issue:
There's no defined error code for situations in which a node receives
an AVP with its 'P' bit set not being authorised to have its 'P' bit
set
Requested change:
Add in the appropriate place (7.1.5 in Base-07
or 7.2 in CMS-02) a new
error code:
DIAMETER_INVALID_AVP_P_BIT 50xx
The request contained an AVP with an invalid value in its 'P'
bit. A
Diameter message indicating this error MUST include
the offending AVPs
within a Failed-AVP AVP.
Add at the end of the section 2.0 in CMS-02:
Diameter implementations MUST check whether AVPs with its 'P' bit
set are allowed to use it. If not, an appropriate error message
MUST be
issued containing DIAMETER_INVALID_AVP_P_BIT result code.
Update:
I agree with this issue as such. I would suggest however slightly
more
general error code, and it to be put to the base. This
way we could handle
any illegal bit-AVP combinations:
DIAMETER_INVALID_AVP_BIT_COMBINATION
50xx
The request contained an AVP with which is not allowed
to have the
given value in the AVP Flags field. A Diameter message
indicating this error
MUST include the offending AVPs
within a Failed-AVP AVP.
and then:
Diameter implementations MUST check whether AVPs with its 'P' bit
set are allowed to use it. If not, an appropriate error message
MUST be
issued containing DIAMETER_INVALID_AVP_BIT_COMBINATION
result code.
Submitter name: Miguel A. Monjas
Submitter email address:
ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-09-07
Reference:
Document: CMS-02
Comment type: T
Priority: S
Section: 3.1, 6.9, 6.10, 7.2
Rationale/Explanation of issue:
A
Diameter node can request protection on certain AVPs that are not
allowed
(i.e. requested as signed an AVP which can't set its 'P' bit
or as encrypted
an AVP which can't be encrypted). No check nor error
code has been defined.
Requested change:
Add the following paragraph to 3.1 (after the
list of components of
the DSAR):
The destination node MUST check
that the provided elements of
the DSAR are valid. It MUST check, at least,
that:
- Its local policy allows it to provide a TTL compatible with
the value provided in the request.
- One of the CAs provided is suitable
of being the top of a
CA certificate chain that will assure the certificates
of
the servers in the Home Domain.
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.
The destination node MUST also
verify that the protection
expectations are valid. If it is requested as
signed an AVP
which may not set its 'P' bit or as encrypted an AVP which may
not be encrypted, the destination node MUST return a DSAA with the
Result-Code AVP set to DIAMETER_ERRONEOUS_PROTECTION_EXPECTATIONS.
In the event....
Add the following paragraph to 6.9:
If the AVP code specified in the Expected-Signed-AVP is not
valid
(that it, that AVP is not allowed to set its 'P' bit), the
implementation
MUST issue an error message containing the
DIAMETER_ERRONEOUS_PROTECTION_EXPECTATIONS result code
Add the
following paragraph to 6.10:
If the AVP code specified in the
Expected-Encrypted-AVP is not
valid (that it, that AVP is not allowed to be
encrypted), the
implementation MUST issue an error message containing the
DIAMETER_ERRONEOUS_PROTECTION_EXPECTATIONS result code
Add the
following error code to 7.2:
DIAMETER_ERRONEOUS_PROTECTION_EXPECTATIONS
50xx
The protection expectations stated in the Expected-Signed-AVP
or
Expected-Encrypted-AVP are invalid. A Diameter message
indicating this error
MUST include the offending AVPs within
a Failed-AVP AVP.
Update:
I agree with the parts of this issue. However, I would
suggest that
instead of creating a new error code we
could simply use
DIAMETER_INVALID_AVP_VALUE.
Otherwise we end up creating a special error
code for
all AVPs.
Also, I would suggest we don't list all the
checks explicitly
because, essentially, the destination node must check
ALL sent parameters according to the policies. I've reformulated
the
text slightly to be a bit more general in this respect.
Edited change
request below.
Jari
> Add the following paragraph to 3.1
(after the list of components of
> the DSAR):
>
> 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, AVP protection
> expectations, certification
status, and other parameters.
> - A common "top" of the certificate chain
can be found between
> the home and foreign domains.
>
> 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.
>
> The destination node MUST also verify that the protection
> expectations are valid. If it is requested as signed an AVP
>
which may not set its 'P' bit or as encrypted an AVP which may
> not be
encrypted, the destination node MUST return a DSAA with the
> Result-Code
AVP set to DIAMETER_INVALID_AVP_VALUE.
>
>
> In the
event....
>
> Add the following paragraph to 6.9:
>
> If the AVP code specified in the Expected-Signed-AVP is not
>
valid (that it, that AVP is not allowed to set its 'P' bit), the
>
implementation MUST issue an error message containing the
>
DIAMETER_INVALID_AVP_VALUE result code
>
> Add the following
paragraph to 6.10:
>
> If the AVP code specified in the
Expected-Encrypted-AVP is not
> valid (that it, that AVP is not allowed
to be encrypted), the
> implementation MUST issue an error message
containing the
> DIAMETER_INVALID_AVP_VALUE result code
Submitter name: Mark Eklund
Submitter email address: meklund@cisco.com
Date first submitted: 2001-09-07
Reference:
Document: Base-07
Comment type: T
Priority: 1
Section: 7.1.3
Rationale/Explanation
of issue:
Section 6.1 states that
- a request that needs to be
sent to a specific home server among
those serving a given realm, MUST
contain both the Destination-
Realm and Destination-Host AVPs.
If
there is a Destination-Host, but no Destination-Realm, there
is no way to
respond with a protocol error.
MISSING_AVP is not a protocol error, so
you must use the correct
ABNF for the answer. This is not possible for a
many proxy
situations if the proxy is not aware of a certain Application (a
simple relay agent for example).
DIAMETER_UNABLE_TO_DELIVER is used
when the realm known,
but no hosts are available.
DIAMETER_REALM_NOT_SERVED is used when the realm is available,
but
not served.
Requested change:
Either add a new
DIAMETER_MISSING_DESTINATION_REALM protocol
error, or reword
DIAMETER_UNABLE_TO_DELIVER or
DIAMETER_REALM_NOT_SERVED to include the above
situation.
> Either add a new DIAMETER_MISSING_DESTINATION_REALM
protocol
> error, or reword DIAMETER_UNABLE_TO_DELIVER or
>
DIAMETER_REALM_NOT_SERVED to include the above situation.
Update:
Perhaps we should avoid again the explosion of new error
codes, and
pick the second option. Here's a an attempt at the
rewording:
DIAMETER_UNABLE_TO_DELIVER 3003
This error is given when Diameter
can not deliver
the message to the destination, either because
no host
within the realm was available to process
the request, or because
Destination-Host AVP was
given without the associated Destination-Realm AVP.
Submitter name: Tony Johansson
Submitter email address:
tony.johansson@ericsson.com
Date first submitted: 2001-09-10
Reference:
Document: Base-07
Comment type: T
Priority: 1
Section: 4.3
Rationale/Explanation of issue:
Float128 is specified in the Base
specification, but not int128 and u_int128. Is there a particular need for
Float128?.
Furthermore, is Float128 even supported in most OSs?
Requested change:
Remove Float128 from the Base, unless
somebody can tell that float128 is really needed and can be supported be the
majority of known OSs.
Submitter name: Bernard Aboba
Submitter email
address: aboba@internaut.com
Date first submitted: 9/13/01
Document:
base-07, transport-04
Comment type: Technical
Priority: Must fix
Section: 5.5.3 (base), 3.2 (transport)
Explanation of issue: The
transport failure algorithms described in the
two drafts differ
substantially. For example, the transport draft
describes an algorithm that
depends on a single timer, while the base
drafts algorithm includes multiple
timers.
Requested change:
The drafts need to be aligned so that they
describe the same transport
failure algorithm.
Submitter
name: Miguel A. Monjas
Submitter email address:
ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-09-14
Reference: http://www.merit.edu/mail.archives/aaa-wg/msg02095.html
Document: CMS-02
Comment type: T
Priority: 2
Section: 6.2
Rationale/Explanation of issue:
In the list of errors provided in
the reference message, the error
situation 19 states no error code:
> 19. A Diameter message arrives containing a CMS-Encrypted-Data AVP
and
> an error occurs during decryption.
> Error code issued:
> Definition of the error:
> Included in CMS-02 draft: No
>
Included in CMS-03 draft:
> Status: proposal needed.
After some
reflexion time, I've noticed that there is no way to
distinguish between an
error decryption and an error in the AVPs
extracted. As far as I know, the
extracted AVPs are just a bit stream
that has to be parsed. If the
CMS-Encrypted-Data AVP has been
modified, the only result is that the bit
stream would be parsed since
the extracted AVPs would be invalid.
My
proposal is that only a DIAMENTER_INVALID_AVP_VALUE would be
issued,
including the CMS-Encrypted-Data AVP as Failed-AVP AVP.
Requested
change:
Replace the following sentence in 6.2:
...and an error
occurs during decryption, then the
recipient MUST indicate an error.
with the following:
...and an error occurs during decryption,
then the
recipient MUST indicate an error by means of the
DIAMETER_INVALID_AVP_VALUE result code and including
the
CMS-Encrypted-Data AVP as Failed-AVP AVP.
Submitter name: Mark Eklund
Submitter email address: meklund@cisco.com
Date first submitted: 9/13/01
Document: base-07
Comment type:
Editorial
Priority: Should fix
Section: 4.3
Explanation of issue:
The definitions of Float32, Float64, and Float128 in the base
draft
all are missing the sentence fragment "if the 'V' big is
enabled)".
Requested change:
Add the text to the end of the four lines.
Submitter name: Yolanda Garcia
Submitter email address:
Yolanda.Garcia-Serrano@ece.ericsson.se
Date first submitted: 2001-09-14
Reference:
Document: Base-07
Comment type: T
Priority: S
Section: 2.5, 5.3, 6.9, 6.10
Rationale/Explanation of issue:
Diameter Nodes MUST advertise locally supported applications. This must
be done
including at least an Auth-Application-Id AVP or an
Acct-Application-Id AVPs in
CER and CEA messages, otherwise there is no way
a receiver of a CER message detect
whether it has any application in common
with the sender.
Requested change:
Add clariying text at least
in sections 5.3.1 and 5.3.2
Submitter
name: Miguel A. Monjas
Submitter email address:
ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-09-14
Reference:
http://www.merit.edu/mail.archives/aaa-wg/2001-08/msg00229.html
Document: CMS-02
Comment type: T
Priority: 2
Section: 1.2, 4.3
Rationale/Explanation of issue:
As agreed in the discussion of issue
136, the description of two
scenarios regarding CMS proxies was introduced
in the draft. These
scenarios are just examples, so that additional
scenarios might be
considered. I've noticed that there might exist another
scenario.
Let's consider a local AAA server that has to forward
authentication
request from user that don't belong to its realm. It seems
reasonable
that the AAA server establishes DSAs with other realms
automatically
(that is, without any PDSA request from the clients). The
local AAA
server would decide, accoding to its policies, with which realms
it
must establish a DSA. This scenario seems reasonable since it puts the
intelligence of the system in the Diameter node and not in the client.
As a consecuence, at least three scenarios could be described. The two
escenarios also covered by the draft (as agreed on issue 136's
discussion):
- The access device does not have the cryptographic
ability to
handle the CMS functions locally, and therefore requests such
services from the local agent, such an an aggregating relay or
proxy
agent. The NAS may have been configured to always issue a
PDSR to its local
agent for CMS services. In such cases, the
agent MUST select the values for
the DSA-TTL and provide the
appropriate Local-CA-Info and the expected OCSP
response from
the DSA peer.
- The access device has the
cryptographic ability to perform the
CMS
functions, but a proxy agent is
in the route towards the home
server, and it returned a failure to the DSAR
messages stating
that it was not willing to allow the DSA to traverse
through it.
Such agents MAY attempt to re-use the values from the initial
DSAR sent by the access device.
And an additional scenario (which
IMHO could be even more common):
- The access device does not have the
cryptographic ability to
handle the CMS functions locally but does not
request such
services from the local agent. Instead, the local agent has
been configured to establish DSAs with certain realms in an
automatic
way, so that the existence of DSAs is transparent
for the access device.
Requested change:
Add such scenario to the draft. However, as
this new scenario doesn't
requires a previous PDSA request, it looks like
that this scenario
shouldn't be added to section 4.3 but to section 1.2. And
that's a
problem, since Pat already stated that in order to add the
scenarios
to section 1.2 a major "surgery taks" might be necessary.
If Pat and the rest of the WG agrees on adding this issue, I'll be
able to carry out this task.
Submitter name: Miguel A. Monjas
Submitter email address:
ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-09-14
Reference:
Document: CMS-02. ¿base?
Comment type: T
Priority: S
Section:
Rationale/Explanation of issue:
One of the scenarios
described in section 4.3 introduces the concept
of a client without
cryptographic abilities but able to send a PDSA
request (and process a PDSA
answer).
My concern is the following: does this client actually support
CMS
(that is, can it include a value of '2' in the capabilities exchange?)
I don't think so. However, it must support the messages that are
needed
to request a proxy a DSA on its behalf.
Requested change:
A
clarifying text about it such clients can advertise that they
support CMS
when they can't actually do it? As a consecuence, maybe it
would be more
reasonable to move PDSAR and PDSAA to the base
specification, so that a base
support would include such messages (I
don't really like this proposal, but
IMHO it's the more coherent).
Submitter name: Miguel A. Monjas
Submitter email address:
ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-09-14
Reference:
Document: CMS-02
Comment type: T
Priority: 1
Section: 1.2
Rationale/Explanation of issue:
The possibility of
issueing a PDSA request without a DSA-Target-Realm
has been suggested as an
optimized approach that allows to avoid a
explicit PDSA with any desired
realm.
However, there are some points that remain unclear (IMHO):
- When does the proxy establish a DSA? As an initial establishment
with all the realms isn't possible, I suppose that every time the
client
request an authorisation operation regarding a user, the proxy
must detect
the operation and establish a DSA before forwarding the
authorisation
message.
- Does the proxy has to establish a DSA with any realm? I don't
think
so, since it may not be allowed by the proxy's local policies.
- What happens when one of such DSA fails? Or whether the proxy
doesn't support a DSA with the required realm? Or even whether there
is
a another proxy on the route that issues a NOT_CMS_THROUGH_PROXY
result
code? Do the proxy have to indicate it to the client, issuing
an appropriate
answer with a given result-code (maybe
DIAMETER_NO_DSA_ESTABLISHED)? Or it
must forward the message without
warning the client?
- Are all the
clients equal? I mean, does the proxy have to record on
behalf of which
client it is establishing a DSA (what might involve
several DSAs with the
same realm on behalf of different clients)?
- What happens when the DSA
expires? Does the proxy have to
re-establish it without any indication from
the client. If so, the
third model suggested in one of my previous issues
would be better (no
explicit PDSAR to begin a DSA but just local policies of
the proxy).
Requested change:
a) Replace the following
paragraph:
An optimized approach also allows the PDSR to be sent by the
access
device without the DSAR-Target-Realm AVP. This message is used to
inform the proxy that it MUST establish a Diameter security
association
for all realms it will be communicating with on behalf
of the access device.
with something like the following:
An optimized approach also
allows the PDSAR to be sent by the
access
device without the
DSAR-Target-Realm AVP. This message is used to
inform the proxy that it MUST
establish a Diameter security
association for all realms it will be
communicating with on behalf
of the access device. Such DSA MUST be
established only first time
a message must be routed to a given realm.
It may happen that this DSA can not be established. For example,
the
proxy might be configured not to establish DSAs with the
required
realm,
the DSA setup migh fail or there is a proxy agent in the
route towards the
home server, and it returned a failure to the
DSAR messages stating that it
was not willing to allow the DSA to
traverse through it. In such situations,
the proxy MUST reject the
message, but set the Result-Code AVP to
DIAMETER_NO_DSA_ESTABLISHED.
If several access device send a PDSAR
without the DSAR-Target-Realm
AVP, only one DSA per realm MUST be
established.
b) Add clarifying text regarding what happens when the DSA
expires.
Submitter
name: Miguel A. Monjas
Submitter email address:
ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-09-14
Reference:
Document: CMS-02
Comment type: T
Priority: 2
Section: 6.6
Rationale/Explanation of issue:
It remains unclear
for me the meaning of AAA-Server-Certs. As far as I
understand, a DSA is
established between two Diameter agents (not
between an agent and a realm)
so that no CMS-protected AVP can come
from a node "outside" the DSA. If this
supposition is right, including
certificates of other home nodes is useless,
since the initiator of
the DSA wouldn't accept CMS AVPs from a different
node although
belonging also to the home realm.
Requested change:
Add clarifying text.
Submitter name: Miguel A. Monjas
Submitter email address:
ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-09-06
Reference:
Document: CMS-02
Comment type: T
Priority: 1
Section: 6.1, 6.2
Rationale/Explanation of issue:
When a set of
AVPs is required also as encrypted and digitally signed,
the draft states
(according to S/MIME RFC) that the encryption must be
done first. That's is
coherent but can, in some occasions, be confused
for an implementation.
I'll try to explain it. Let's imagine that the Expected-Encrypted-AVP
states that AVPs A and B must be encrypted. So does the
Expected-Signed-AVP (including maybe another AVP, C). The
implementation
will first create a CMS-Encrypted-AVP containing A and
B, that are
subsequently dropped. When the signing process begin,
there's no A and B
AVPs, so that it might sign only C. In order to
avoid this misbehaviour, I
suggest stating explicitly that when
encryption and digital signature are
required, it has to be treated as
an atomic operation, so that the
implementation must "remember" that A
and B AVPs are also inside an
encrypted AVP.
Requested change:
Add some paragraphs after
(6.1):
When AVPs are to be both encrypted and signed, the
CMS-Encrypted-Data
AVP MUST be created first. The resulting CMS object
MUST then be
MIME
encoded producing an application/pkcs7-mime MIME type
which is then
used as the content of the EnvelopedData. This means that
signing
is
"outside" encryption.
It might be something like the
following:
Implementations MUST treat this process as an atomic process,
so
that
one encrypted the set of AVPs required as so, the implementation
MUST
use the CMS-Encrypted-Data AVP (as well as any additional AVP
required
as only signed) as the input to the signing process (even if
the
CMS-Encrypted-Data AVP was not required as digitally signed).
Where an implementation wants to receive a set of AVPs both
encrypted
and signed it MIGHT use a work around consisting of requiring
the
set
of AVPs as encrypted and CMS-Encrypted-Data AVP as digitally
signed.
Where there are more AVPs required as encrypted than
digitally
signed,
a CMS-Encrypted-Data AVP MUST be created including
only the AVPs
that
has also to be digitally signed. This AVP will be the
input to the
signing process. The rest of AVPs required as encrypted MUST be
done
as many as desired additional CMS-Encrypted-Data AVPs.
Replace the next paragraph in 6.2:
When AVPs are to be both
encrypted and signed, the
CMS-Encrypted-Data
AVP MUST be created first.
with
When AVPs are to be both encrypted and signed, the
CMS-Encrypted-Data
AVP MUST be created first, according to the
guidelines stated in
6.1.
Submitter name: Bob Kopacz
Submitter email address:
BKopacz@InterlinkNetworks.com
Date first submitted: September 18, 2001
Reference: None
Document: draft-ietf-aaa-diameter-mobileip-07
Comment type: T
Priority: 1
Section: 7.1, 7.2, 7.4, 7.5
Rationale/Explanation of issue:
The first 256 AVP numbers are
reserved for compatibility with
RADIUS.
However, the type of four of
them has been changed in the Diameter
draft. Accounting-Input-Octets,
Accounting-Output-Octets,
Accounting-Input-Packets, and
Accounting-Output-Packets are AVPs in
the RADIUS attribute space, but are
32-bit integers in RADIUS and
64-bit integers in Diameter.
This
makes the dictionary implementation more difficult in servers
that support
both RADIUS and Diameter.
For the first 256 attributes, we should retain
full RADIUS
compatibility and retain the original RADIUS type. If Diameter
applications want 64-bit integer counters, then create
Diameter-specific
AVPs for them.
Requested change:
(The AVP names are only a
suggestion)
Rename Accounting-Input-Octets as
Accounting-Input-Extended-Octets,
rename Accounting-Output-Octets as
Accounting-Output-Extended-Octets,
rename Accounting-Input-Packets as
Accounting-Input-Extended-Packets,
rename Accounting-Output-Packets as
Accounting-Output-Extended-Packets,
let their values be 64-bit integers,
and assign them Diameter AVP numbers greater than 255.
Related to
this issue, a similar problem exists in the nasreq-07 spec.
However, while
sections 8.1-8.5 indicate that the AVPs in question should be
Unsigned64,
the table in section 2.2 indicates that they are in fact
Unsigned32.
Submitter name: Bernard Aboba
Submitter email address:
aboba@internaut.com
Date first submitted: 9/19/01
Document: base-07
Comment type: Technical
Priority: Must fix
Section: 2.2 Securing
Diameter Messages
Explanation of issue: There is a mismatch between security
support
required on the client and on the server. Diameter clients MUST
support
IPsec, and MAY support TLS. Yet, Diameter Servers MUST support TLS,
and
MAY support IPsec. Thus, compliant Diameter clients & servers won't
necessarily interoperate.
Requested change:
Change text to: Diameter
Servers MUST support TLS and IPsec.
Submitter name: Miguel A. Monjas
Submitter email address:
ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-09-24
Reference:
Document: Base
Comment type: T
Priority: S
Section: 9.5, 9.7.1
Rationale/Explanation of issue:
In base
specification 9.5 it's quoted the term CMS-Data AVP:
In all accounting
records the Session-Id and User-Name AVPs MUST
be present. If end-to-end
authentication is required, as described
in [11], the CMS-Data AVP may be
used to authenticate the
Accounting Data and Service Specific AVPs. It is
not typically
necessary, nor recommended, that the end-to-end authentication
cover any additional AVPs since the Data and Service Specific AVP,
and
associated CMS-Data, MAY need to be submitted to a third party.
Also in
9.7.1:
When the Accounting-Request is being submitted to a third party
(e.g. settlement service), and includes the CMS-Data AVP [11], the
CMS-Data AVP MUST be signed by both the local and home Diameter
server
using the countersignature procedures described in [11].
However, this
CMS-Data AVP doesn't actually exist.
Requested change:
Changing
that term in both paragraphs. In the first paragraph,
CMS-Data should be
changed by CMS-Signed-Data since it's
authentication the security service
involved. However, in the last
sentence, the phrase "It is [...] not
recommended that the end-to-end
authentication cover any additional AVPs..."
looks wrong. As stated in
the discussion of issue 150, too much digital
signature doesn't harm
and there's no problem if the signature covers other
AVPs.
The result could be something like the following:
In all
accounting records the Session-Id and User-Name AVPs MUST
be present. If
end-to-end authentication is required, as described
in [11], the
CMS-Signed-Data AVP may be used to authenticate the
Accounting Data and
Service Specific AVPs. It is not typically
necessary, although nor harmful,
that the digital signature carried
by the CMS-Signed-Data AVP covers any
additional AVPs, even if the
since the Data and Service Specific AVP, and
associated
CMS-Signed-Data, MAY need to be submitted to a third party.
In the second one, it also looks like CMS-Signed-Data is the right
option.
When the Accounting-Request is being submitted to a third
party
(e.g. settlement service), and includes the CMS-Signed-Data AVP
[11], the CMS-Signed-Data AVP MUST be include digital signatures
by both
the local and home Diameter server using the
countersignature
procedures
described in [11].
Submitter name: Miguel A. Monjas
Submitter email address:
ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-09-24
Reference:
Document: CMS-02
Comment type: T
Priority: 1
Section:
Rationale/Explanation of issue:
The CMS application
comprises two main "features" (as described in
section 2.0): the security
feature, which comprises the messages
necessary for establishing security
associations and the AVPs needed
to protect other AVPs; and the proxy
feature, made up of the messages
that are used to ask a proxy to establish a
security association.
On the other hand, the CMS draft begins by
describing how a security
association can be established (sections 1.1 and
1.2). It might looks
like as if the CMS draft states that a security
association is needed
to exchange protected AVPs. But it doesn't actually
say it.
Another points:
- The definition of CMS-Signed-Data AVP
(section 6.1) introduces the
concept of countersignatures. This attribute
allows any Diameter peer
to add its own digital signature to an existing
CMS-Signed-Data AVPs
(but always on the same set of AVPs, the ones with its
protection bit
set). As far as I understand, this situation could happen
when a
broker signs AVPs in given Diameter messages that traverse through
it.
Section 1.3 also describes a "business model" in which two Diameter
nodes signs "in parallel" accounting AVPs. It is supposed that those
both parties are the participants of a DSA (according to figure 4).
The
base specification also talks about AVPs being signed by two
parties
(sections 9.5 and 9.7.1) usually to be forwarded to a third
party with
settlement purposes (however, it isn't said whether those
AVPs would be
forwarded using new Diameter messsages). Discussion on
Issue 150 emphasizes
that a digital signature has no actual receiver
(that is, a Diameter node
can sign anything withour a explicit request
within the framework of an
established DSA)
- The definition of CMS-Encrypted-Data AVP (section
6.2) reviews the
concept of RecipientInfo, an attribute of the CMS structure
EnvelopedData that allows to encrypt a given set of AVPs for different
receivers using an only CMS-Encrypted-Data AVP. Discussion on issue
#150
also introduces an example in which a Diameter node has to
encrypt some
(different) AVPs to two different receivers. Section 6.2
(proposed) says
that:
If the recipient is not specified in a RecipientInfo, it MAY
choose to process the message or return an answer with the
Result-Code
AVP set to DIAMETER_NO_DSA_RECIPIENT"
that is, a node can receive a
CMS-Encrypted-Data AVP with a receiver
different from itself.
- As a
result of "Questions about AVPs ocurrence" series, it was
stated that "The
DSAR message MUST NOT be used simply as a convenient
certificate
distribution protocol without establishing a DSA" (section
4.1). What might
imply that a DSA is necessary to include a CMS-Cert
AVP. However, section
6.1.7 in base protocol states that:
Redirector agents MAY also include
the certificate of the servers
in
the Redirect-Host AVP(s). These
certificates are encapsulated in a
CMS-Cert AVP [11].
and the same
in section 1.3 of CMS:
the redirect agent to retrieve the necessary
information for it to
communicate directly with the home server, which MAY
include the
home server's certificates.
Requested change:
a) Clarifying whether CMS-* (that is, CMS-Signed-Data,
CMS-Encrypted-Data and CMS-Cert) may be exchanged without an
established
DSA between the peers. If so, introducing a brief
description of scenarios
in which no previous DSA is needed (that is,
that a node can sign of encrypt
AVPs according only to its local
policy and not to an explicit DSA)
b) Whenever CMS is used in the base draft, describing that
functionality in the CMS draft.
Submitter name: Panos Thomas
Submitter email address:
Panos.Thomas@motorola.com
Date first submitted: 9/25/01
Reference: N/A
Document: draft-ietf-aaa-diameter-mobileip-07.txt
Comment type: T
Priority: 2
Section: 5.0
Rationale/Explanation of issue:
3rd
paragraph in Section 5.0:
"The Authorization-Lifetime AVP contains the
number of seconds
before registration keys destined for the Home Agent
and/or
Foreign Agent expire. A value of zero indicates infinity (no
timeout)."
Tying the Authorization-Lifetime and the key lifetimes
couples
authorization and key generation. It may be desirable to allow
AAAH to set key lifetimes to any value (e.g. to a multiple of
the
Authorization-Lifetime), so that it doesn't have to generate
new keys every
time it re-authorizes the user.
Requested change:
Remove the 3rd
paragraph in Section 5.0 and add a MIP-Lifetime
AVP to the MIP-XX-to-XX-Key
AVPs in Sections 6.1 - 6.6.
Submitter name: Mark Eklund
Submitter email address:
meklund@cisco.com
Date first submitted: 26-Sep-01
Reference:
Document: mobileip
Comment type: Editorial
Priority: '1' Should fix
Section: 5.3
Rationale/Explanation of issue:
According to 5.3:
Upon receipt of the HAR, the home agent recovers the Foreign-Home
registration key, allocates an SPI to be used with the key, and uses
this key to create a Foreign-Home authentication extension to the
Registration Reply message.
But according to
draft-ietf-mobileip-aaa-key-01.txt there is no
such thing as a Foreign-Home
authentication extension.
Requested change:
Since there is no
need for the mobile node to know the
Foreign-Home key, this was probably a
cut and paste
error. Please remove:
, and uses
this key to
create a Foreign-Home authentication extension to the
Registration Reply
message.
Submitter name: Henry Haverinen
Submitter email address:
henry.haverinen@nokia.com
Date first submitted: 2001-09-27
Reference:
Document: nasreq
Comment type: T
Priority: S
Section: 2.1.6
Rationale/Explanation of issue:
The NAS-Key-Binding AVP specifies
the purpose of the
session key. The AVP MUST be included if the
NAS-Session-Key
AVP is included. The key binding specifies which ciphersuite
will be used between the NAS and the user. The problem is that
the
ciphersuite may not have been selected yet.
In PPP, ECP is used to
negotiate the ciphersuite and it occurs
between the user and the NAS after
authentication.
In IEEE 802.11, the ciphesuite negotiation may as well
occur after authentication.
In addition, the NAS-Key-Binding AVP
makes AAA servers
dependent on and aware of different ciphersuites, so they
need to be updated if a new ciphersuite is specified.
Even if the
ciphersuite hasn't been selected, the AAA server
can still transport keying
material to the NAS in the
NAS-Session-Key AVP. For example, it can include
large
session keys which the NAS can truncate as necessary for use
with
a given ciphersuite.
Requested change:
The NAS-Key-Binding AVP
should not be mandatory even if the
NAS-Session-Key AVP is included. Do we
need the NAS-Key-Binding
AVP at all?
Submitter name: Henry Haverinen
Submitter email address:
henry.haverinen@nokia.com
Date first submitted: 2001-09-27
Reference:
Document: nasreq
Comment type: S
Priority: 1
Section: 2.1.2 -
2.1.6
Rationale/Explanation of issue:
The NAS-Session-Key AVP as
currently specified does not
include means to transport initialization
vectors for
encryption.
Requested change:
One way to support
IV's would be to have a new NAS-Key-Type
for them. This would make sense
especially if the NAS
uses the received material as a master session key
from
which the actual IV's are derived.
Alternatively, we could
specify that the keying material
of cipher keys includes initialization
vector material.
Submitter name: Henry Haverinen
Submitter email address:
henry.haverinen@nokia.com
Date first submitted: 2001-09-27
Reference:
Document: nasreq
Comment type: S
Priority: 1
Section: 2.1.2 -
2.1.6
Rationale/Explanation of issue:
The NAS-Session-Key AVP, as
currently specified, can only
be used to transport encryption and integrity
keys.
However, a IEEE 802.11 access point may need session
master keys
from which it derives the actual encryption
and authentication keys. (This
is not certain yet.)
Requested change:
Perhaps the NASREQ
document could simply say that the
CIPHER_KEY (or INTEGRITY_KEY) can
alternatively be used as
a session master key from which the NAS derives the
actual
cipher keys (integrity keys).
Submitter name: Fredrik Johansson
Submitter email address:
fredrik@ipunplugged.com
Date first submitted: 2001-09-28
Reference:
Document: base
Comment type: T
Priority: 1
Section:
Rationale/Explanation of issue:
How should a peer know if the other
side is runnig TLS or not?
Requested change:
One possible
solution could be to add two new values to the transport
attribute in the
URI saying TLSoverTCP or TLSoverSCTP
Another solution would be to add it
as an configurable attribute to a peer.
But maybe the URI solution is
preferable.
Submitter name: Fredrik Johansson
Submitter email address:
fredrik@ipunplugged.com
Date first submitted: 2001-10-01
Reference:
Document: base-08-alpha
Comment type: T
Priority: 1
Section:
Rationale/Explanation of issue:
What disconnect cause should be sent
when disconnecting due to a lost
election.
Requested change:
Add new disconnect cause code, e.g.
ELECTION_LOST 3
Sent on
the transport connection that has lost the election.
Submitter name: Fredrik Johansson
Submitter email
address: fredrik@ipunplugged.com
Date first submitted: 2001-10-01
Reference:
Document: base-08-alpha
Comment type: T
Priority: 1
Section:
Rationale/Explanation of issue:
Typos/errors in peer
state machine
Requested change:
change:
Wait-I-CEA
I-Rcv-CEA Process-CEA I-Open
R-Conn-CER R-Accept, Wait-Returns
Process-CER,
Elect
I-Peer-Disc I-Disc Closed
------>
I-Rcv-DPR I-Snd-DPA,I-Disc Closed <-----
I-Rcv-Non-CEA Error ^^^^^^
Closed
Timeout Error Closed
I-Open Send-Message I-Snd-Message
I-Open
I-Rcv-Message Process I-Open
WatchDog-Timer I-Snd-DWR I-Open
I-Rcv-DWR Process-DWR, I-Open
I-Snd-DWA
I-Rcv-DWA Process-DWA I-Open
R-Conn-CER R-Reject I-Open
------> Stop I-Snd-DPR Closing <------
I-Rcv-DPR I-Snd-DPA, Closed
I-Disc
I-Peer-Disc I-Disc Closed
<-------
I-Rcv-CER Error Closed
I-Rcv-CEA Error Closed
and add:
Closing I-Rcv-DPA I-Disc Closed
R-Rcv-DPA
R-Disc Closed
Timeout Error Closed
-----> I-Peer-Disc I-Disc Closed
<-------
-----> R-Peer-Disc R-Disc Closed <-------
Submitter name: Panos Thomas
Submitter email address:
Panos.Thomas@motorola.com
Date first submitted: 2001-10-01
Reference:
N/A
Document: base-08-alpha
Comment type: T
Priority: 1
Section:
8.15
Rationale/Explanation of issue:
In a MIPv4 scenario, when
old-FA detects that the user has moved
to a new-FA, or when its
Auth-Lifetime+Grace-Period timer expires,
it sends an STR to AAAH to
terminate the (old-FA)-(AAAH) session.
What Termination-Cause value should
the old-FA use in these cases?
DIAMETER_LOGOUT or DIAMETER_LINK_BROKEN may
cause the AAAH to also
terminate the (AAAH)-(HA) session.
Requested
change:
Add the following Termination-Cause AVP values in Section 8.15:
DIAMETER_AUTH_EXPIRED
This value is used when the Auth-Lifetime +
Auth-Grace-Period
expires on access device.
DIAMETER_USER_MOVED
This value is used in a MIP scenario when the FA determines
that the
user has moved to a new FA.
Submitter name: Mark Jones
Submitter email address:
mjones@matrixmuse.com
Date first submitted: 2001-10-02
Reference:
http://www.merit.edu/mail.archives/aaa-wg/msg02204.html
Document:
mobileip-08, aaa-key-08
Comment type: 'E'
Priority: '1'
Section:
5.x, 6.0 of mobileip-08, 2 of aaa-key-08
Rationale/Explanation of issue:
1) The text in 5.x and 6.0 refers to the generation of Registration
Keys.
The KDC AVP descriptions (sections 6.1 onwards) refer only to session
keys.
These are one and the same so the naming should be consistent.
2) Section 5.3 entitled 'Distributing the Foreign-Home Registration Key'
does not give any details on how the key is derived.
3) The
aaa-key-08 draft does not explicitly state that key material must be
distinct for each of the requested keys leaving the implementor the option
of using the same key material for deriving Mobile-Home, Mobile-Foreign and
Home-Foreign session key.
Requested change:
1) In section
5.x and 6.0, replace the term Registration Key(s) with
'Session Key(s)' for
consistency.
2) Add the following text to the end of the first paragraph
in section 5.3:
"The procedure for generation of key material and derivation
of this session
key is identical to that for the Mobile-Home and
Mobile-Foreign session keys
as specified in [15]."
3) In aaa-keys,
modify the text in step 5 of section 2 (Scope of Protocol)
to read:
5. At the time the information within the MN-AAA Authentication
extension is verified by the AAA server, the AAA server also
generates
distinct Key Material for each of the keys requested
by the mobile node, and
causes insertion of the Key Material
fields along with the Registration
Reply.
Submitter name: Harri Hakala
Submitter email address:
Harri.Hakala@lmf.ericsson.se
Date first submitted: 10.10.2001
Reference:
Document: Base (draft-ietf-aaa-diameter-08-alpha01)
Comment type: T/E
Priority: 1
Section: 2.3 and 8
Rationale/Explanation of issue:
According to the section 8.0 Diameter can provide two different type of
services to applications.
The first involves authentication and
authorization, and can optionally make use of accounting.
The second only
makes use of accounting.
There are certain applications, which needs
only send the accounting information and
do not need the support of
authentication and authorization.
The Accounting commands from the
Diameter base protocol suits very well for this purpose.
In section 2.3
Diameter Protocol Extensibility it is described the ways how
the Diameter
protocols can be extended.
Section 2.3.2 defines that when no existing AVP
can be used appropriately to communicate some
service-specific information,
a new AVP should be created.
By using the accounting commands and
service-specific AVPs would be the perfect solutions
for the applications
which only want to send the accounting information.
But it is not
possible to use the Accounting commands with service specific AVPs without
creating a new application, because the accounting is not an application by
itself
(no Application identifier defined).
This means that there is
always need to create a new application before it is possible to use
the
Diameter accounting commands.
Anyhow it is said in section 2.3.3 that the
creation of a new application should be view as a
last resort.
In the
same chapter it is also defined that the new Diameter application MUST define at
least one
Command Code.
Does this mean that if a new application is
created it still can use Commands from the base protocol without
creating a
new Commands ?
Does this restrict the possibility to use Diameter
protocol only for accounting purposes ?
Requested change:
Proposal
Even if the Accounting is part of the Base protocol it should be
possible to use only the accounting part of
Diameter without creating each
time a new application.
Application Id for accounting used for
capabilities exchange.
Submitter name: Liu Qing
Submitter email address:
qing.roger.liu@nokia.com
Date first submitted: 2001-10-08
Reference:
Document: base-08-alpha
Comment type: T
Priority: 1
Section:
8.15
Rationale/Explanation of issue:
What termination cause should
be sent when terminating a session due to the
"Session-Timeout expire on
Access Device"?
(refer to the 8.1: "OPEN Session-Timeout Expires on Access
Device send
STR Discon")
Requested change:
Add new
termination cause code, e.g.
DIAMETER_SESSION_TIMEOUT 6
Access
Device terminate the session when session-timeout expires.
Submitter name: Mark Eklund
Submitter email address:
meklund@cisco.com
Date first submitted: 8-Oct-01
Reference:
http://www.merit.edu/mail.archives/aaa-wg/2001-10/msg00029.html
Document:
mobileip
Comment type: Technical
Priority: 1
Section: 8.1
Rationale/Explanation of issue:
Since the home agent has no use for the
MIP-FA-to-HA-Key or the
MIP-FA-to-MN-key, there is no need to send it to the
home agent.
Requested change:
Change the 0-1 in the HAR column for
rows MIP-FA-to-HA-Key and
MIP-FA-to-MN-key to 0.
Submitter name: Fredrik Johansson
Submitter
email address: fredrik@ipunplugged.com
Date first submitted: 10-Oct-01
Reference:
Document: transport
Comment type: technical
Priority:
1
Section: 5.5.3
Rationale/Explanation of issue:
The wdRecoveryCount
is used for both taking us from SUSPECT to OKAY and
for triggering failover
procedures.
Requested change:
add new counter to trigger failover
procedures
OnTimerElapsed(pcb)
{
if pcb->Status = OKAY
SendWatchdog(pcb)
pcb->Status = WAIT_DWA
T = Tw
else if
pcb->Status = WAIT_DWA
pcb->Status = SUSPECT
T = Td
else if
pcb->Status = SUSPECT
---->>> if pcb->noDWRSentInSuspect++ ==
2
StopConnection(pcb)
FailoverProcedures(pcb)
else SendWatchdog(pcb)
}
Submitter name: Fredrik Johansson
Submitter email
address: fredrik@ipunplugged.com
Date first submitted: 9-Oct-01
Reference:
Document: base-08-alpha
Comment type: editorial
Priority: 1
Section: 10.2
Rationale/Explanation of issue:
The
User Name AVP is not available in the table in section 10.2, but it's
present in the ABNF for the accounting messages
Requested change:
Add User Name AVP