Issue 401: No Security Considerations Section
Submitter name: Bernard Aboba
Submitter email
address: aboba@internaut.com
Date first submitted: 02-19-2003
Reference:
Document: EAP-00
Comment type: Technical
Priority: S
Section:
Rationale/Explanation of issue:
The draft
currently has no security considerations section.
Find enclosed a contribution filling this need:
4. Security Considerations
4.1. Security requirements
Diameter/EAP is used in order to provide authentication and authorization
for network access. As a result, both the Diameter and EAP portions of the
conversation are open to attack. Examples include:
[1] An adversary may attempt to acquire confidential data and
identities by snooping Diameter/EAP packets.
[2] An adversary may attempt to modify packets containing Diameter
messages.
[3] An adversary may attempt to inject packets into a Diameter
conversation.
[4] An adversary may attempt to replay a Diameter exchange.
[5] An adversary may attempt to disrupt the EAP negotiation,
in order to weaken the authentication, or gain access to user
passwords.
[6] An authenticated NAS may attempt to forge attributes,
including NAS-IP-Address, NAS-Identifier, Called-Station-Id,
or Calling-Station-Id.
[7] A rogue (unauthenticated) NAS may attempt to impersonate a
legitimate NAS.
[8] An attacker may attempt to act as a man-in-the-middle.
To address these threats, it is necessary to support confidentiality,
data origin authentication, integrity, and replay protection on a per-
packet basis. Bi-directional authentication between the Diameter client
and server also needs to be provided. There is no requirement that the
identities of Diameter clients and servers be kept confidential (e.g.,
from a passive eavesdropper). Diameter Base protocol [BASE] provides
support for both IPsec and TLS transmission layer security, addressing
threats 1-4. The other security issues are discussed below.
4.2. Security issues
This section provides more detail on the vulnerabilities identified in
above, and how they may be mitigated. Vulnerabilities include:
Privacy issues
Connection hijacking
Replay attacks
Negotiation attacks
Impersonation
Man in the middle attacks
Multiple databases
4.3.1. Privacy issues
Since Diameter messages may contain the User-Name attribute as well as
NAS-IP-Address or NAS-Identifier attributes, an attacker snooping on
Diameter traffic may be able to determine the geographic location of users
in real time. In wireless networks, it is often assumed that Diameter
traffic is physically secure, since it typically travels over the wired
network and that this limits the release of location information.
However, it is possible for an authenticated attacker to spoof ARP
packets from another Access Point so as to cause diversion of Diameter
traffic onto the wireless network. In this way an attacker may obtain
Diameter packets from which it can glean location information. To address this
vulnerability, IPsec or TLS can be used to provide per-packet authentication,
integrity protection, confidentiality and replay protection
of Diameter messages, as specified in [BASE].
4.3.2. Connection hijacking
An attacker may attempt to inject packets into the conversation between
the NAS and the Diameter server, or between the Diameter server and the
security server.
To address this
vulnerability, IPsec or TLS can be used to provide per-packet authentication,
integrity protection, confidentiality and replay protection
of Diameter messages, as specified in [BASE].
4.3.3. Replay attacks
The Diameter protocol relies upon IPsec or TLS transmission layer
security to prevent replay. However, where untrusted proxies are
present, this is not sufficient to prevent replay of CMS-protected
objects. These objects, when included in Diameter EAP messages,
MUST contain sufficient liveness to address replay attacks.
<More detail here>
4.3.4. Negotiation attacks
In a negotiation attack, a rogue NAS, tunnel server, Diameter agent or
Diameter server causes the authenticating peer to choose a less secure
authentication method so as to make it easier to obtain the user's
password. For example, a session that would normally be authenticated
with EAP would instead authenticated via CHAP or PAP; alternatively, a
connection that would normally be authenticated via one EAP type occurs
via a less secure EAP type, such as MD5-Challenge. The threat posed by
rogue devices, once thought to be remote, has gained currency given
compromises of telephone company switching systems, such as those
described in [Masters].
Protection against negotiation attacks requires the elimination of
downward negotiations. This can be achieved by protecting the Diameter
exchange using IPsec or TLS as described in [BASE]. Alternatively,
the vulnerability can be mitigated via implementation
of per-connection policy on the part of the authenticating peer, and
per-user policy on the part of the Diameter server. For the
authenticating peer, authentication policy should be set on a per-
connection basis. Per-connection policy allows an authenticating peer to
negotiate a strong EAP method when connecting to one service, while
negotiating a weaker EAP method for another service.
With per-connection policy, an authenticating peer will only attempt to
negotiate EAP for a session in which EAP support is expected. As a
result, there is a presumption that an authenticating peer selecting EAP
requires that level of security. If it cannot be provided, it is likely
that there is some kind of misconfiguration, or even that the
authenticating peer is contacting the wrong server. Should the NAS not
be able to negotiate EAP, or should the EAP-Request sent by the NAS be
of a different EAP type than what is expected, the authenticating peer
MUST disconnect. An authenticating peer expecting EAP to be negotiated
for a session MUST NOT negotiate a weaker method, such as CHAP or PAP.
In wireless networks, the service advertisement itself may be spoof-
able, so that an attacker could fool the peer into negotiating an
authentication method suitable for a less secure network.
For a NAS, it may not be possible to determine whether a peer is
required to authenticate with EAP until the peer's identity is known.
For example, for shared-uses NASes it is possible for one reseller to
implement EAP while another does not. Alternatively, some peer might be
authenticated locally by the NAS while other peers are authenticated via
Diameter. In such cases, if any peers of the NAS MUST do EAP, then the NAS
MUST attempt to negotiate EAP for every session. This avoids forcing an
EAP-capable client to support more than one authentication type, which
could weaken security.
If CHAP is negotiated, the NAS will pass the User-Name and CHAP-
Password attributes to the Diameter server in an Access-Request packet.
If the user is not required to use EAP, then the Diameter server will
respond with an Access-Accept or Access-Reject packet as appropriate.
However, if CHAP has been negotiated but EAP is required, the Diameter
server MUST respond with an Access-Reject, rather than an Access-
Challenge/EAP-Message/EAP-Request packet. The authenticating peer MUST
refuse to renegotiate authentication, even if the renegotiation is from
CHAP to EAP.
If EAP is negotiated but is not supported by the Diameter agent or server,
then the server or agent MUST respond with an Access-Reject. In these
cases, a PPP NAS MUST send an LCP-Terminate and disconnect the user.
This is the correct behavior since the authenticating peer is expecting
EAP to be negotiated, and that expectation cannot be fulfilled. An EAP-
capable authenticating peer MUST refuse to renegotiate the
authentication protocol if EAP had initially been negotiated. Note that
problems with a non-EAP capable Diameter proxy could prove difficult to
diagnose, since a user connecting from one location (with an EAP-capable
proxy) might be able to successfully authenticate via EAP, while the
same user connecting at another location (and encountering an EAP-
incapable proxy) might be consistently disconnected.
4.3.5. Impersonation
When Diameter requests are forwarded by an agent, the NAS-IP-Address or
NAS-IPv6-Address attributes may not correspond to the source address.
Since the NAS-Identifier attribute need not contain an FQDN, it also may
not correspond to the source address, even indirectly.
This implies that it is possible for a rogue NAS to forge NAS-IP-
Address, NAS-IPv6-Address or NAS-Identifier AVPs in order to
impersonate another NAS. This could result in Diameter messages,
including Grouped Key AVPs, being sent to the wrong NAS. ALthough the rogue
NAS is authenticated by the Diameter agent or server within TLS or
IKE, this authentication information may not be accessible to the Diameter
agent or server, making it unable to detect the forgery. In
addition, it is possible for attributes such as the Called-Station-Id
and Calling-Station-Id to be forged as well.
To address these vulnerabilities it is necessary for the Grouped Key AVP
to contain enough information to "bind" the key to the NAS and client
with which it is to be used. For example, AVPs identifying the NAS
(Origin-Host, NAS-IPV6-Address, NAS-IP-Address, NAS-Port, etc.) can
be included as well as attributes identifying the client (Calling-Station-Id,
Framed-IP-Address, Framed-IPv6-Prefix, Framed-Interface-Id, Session-Id, etc.).
Diameter servers SHOULD check whether NAS-Identifier, Origin-Host,
NAS-IP-Address or NAS-IPv6-Address AVPs match an entry in the
Route-Record AVP. If the NAS-Identifier AVP is present,
such a check may not be possible since the NAS-Identifier
may not correspond to an FQDN. Similarly, where a PTR RR does not
exist corresponding to the NAS-IP-Address or NAS-IPv6-Address, determination
of the FQDN may not be possible. Also, where a NAT
exists between the Diameter client and server, checking the NAS-IP-Address
or NAS-IPv6-Address attributes may not be feasible.
To allow verification of session parameters such as the Called-Station-
Id and Calling-Station-Id, they can be sent by the EAP peer to the EAP
server, and covered by an EAP method-specific message integrity check.
The Diameter server can then check the parameters sent by the EAP client
against those claimed by the NAS. If a discrepancy is found, an error
can be logged.
4.3.6. Man in the middle attacks
As a result, attackers gaining control
of a Diameter agent will be able to modify EAP packets in transit. This is
the case even where IPsec or TLS is used to protect Diameter messages, as
described in [BASE].
To protect against this vulnerability, object security mechanisms SHOULD
be used wherever untrusted Diamter agents are present. These include
Diameter CMS [CMS], a work in progress.
4.3.7. Multiple databases
In many cases a security server will be deployed along with a Diameter
server in order to provide EAP services. Unless the security server also
functions as a Diameter server, two separate user databases will exist,
each containing information about the security requirements for the
user. This represents a weakness, since security may be compromised by a
successful attack on either of the servers, or their databases. With
multiple user databases, adding a new user may require multiple
operations, increasing the chances for error. The problems are further
magnified in the case where user information is also being kept in an
LDAP server. In this case, three stores of user information may exist.
In order to address these threats, consolidation of databases is
recommended. This can be achieved by having both the Diameter server and
security server store information in the same database; by having the
security server provide a full Diameter implementation; or by
consolidating both the security server and the Diameter server onto the
same machine.
Issue 402: NASREQ-11 Comments
Submitter name: Jari Arkko
Submitter email
address: jari.arkko@piuha.net
Date first submitted: March 3, 2003
Reference:
http://www.piuha.net/~jarkko/publications/aaa/nasreq_review.txt
Document: NASREQ-11
Comment type: Technical
Priority: S
Section:
Rationale/Explanation of issue:
I have
read through version 11. I have some questions as well as
editorial and technical comments, inserted directly to the draft
text. The URL for the comments is
http://www.piuha.net/~jarkko/publications/aaa/nasreq_review.txt
Here are my overall comments: We are nearing a state where this
draft can be made an RFC. However, some work still remains. Some
of the main comments:
- Some keyword issues in, e.g., advertising, sending acct
messages, ...
- Some clarifications, e.g., should service still be provided
while re-auth is going on, Accounting-Realtime-Required
effects, Auth-Request default values, optionality of some AVPs
in AAA/AAR requests, EVENT_RECORD, ...
- Normative/informative nature of the old RADIUS AVP semantics
needs clarification.
- Some question marks on the semantics of the AVPs, but I'm not
sure we can do much if the old RADIUS specifications apply in
any case.
- I'd prefer sections 9.1 and 9.1.1 to be more in the usual
keyword style than in the current "example of steps that may
be followed format".
- AVP table inconsistencies wrt base.
- Some additions to the security considerations may be needed,
e.g. RADIUS translation.
- Editorial corrections
[David Mitton]:
Issues #402:
JARI: Comments marked with "JARI:" DJM: Responses marked with "DJM:" major
snips to document marked with "..."
1.2. Advertising Application Support . . . . . . . . . . . . . . . 6
JARI: A terms section might be useful. NAS, ARAP, IPX, CHAP, PAP etc.
DJM: Added.
2. NAS Calls, Ports, and Sessions . . . . . . . . . . . . . . . . . 6
JARI: Looking at the contents list, it might make sense to change the
section titles from "NAS <something>" to simply "<something>"?
What do you think?
DJM: I like the "NAS". At least it is a simplification from previously,
everything was NASREQ.
...
2.1. Diameter Session Establishment
When the authentication or authorization exchange completes
successfully, the NAS application SHOULD start a session context, and
MAY send an Accounting START_RECORD message [Base]. The failure to
JARI: The MAY above is a bit weak? Is this a configuration issue
again, or are NASes generally allowed to skip accounting
if they feel like it? ;-)
DJM: Yes, I've reworded this per your later comments.
Accounting should not be skipped if implemented, but the spec
doesn't require the capability either.
JARI: Is there an AVP which holds the type of failure? Or are all
EVENT_RECORD messages for this particular error?
DJM: Yes, typically Termination-Cause, but it depends on the error.
2.2. Diameter Session Re-Authentication or Re-Authorization
...
JARI: Is this always possible? I think it is possible on PPP, but
perhaps there are other access types for which it might not
be possible. Is re-auth possible on all types of WLAN
links?
DJM: Maybe, maybe not. The feature is here, because it is possible on
some services.
JARI: While re-auth is going on, can service still be provided?
DJM: That too would be service specific.
JARI: Shouldn't we somehow take in account also
Accounting-Realtime-Required AVP from base?
DJM: A Note: is added.
More information on Diameter Session Termination is in [Base] section
8.4.
3.1. AA-Request (AAR) Command
The AA-Request message (AAR), indicated by the Command-Code field set
to 265 and the 'R' bit set in the Command Flags field, is used in
order to request authentication and/or authorization for a given NAS
user. The type of request is identified through the Auth-Request-Type
AVP, and the default mode is both authentication and authorization.
JARI: Default... hmm... does this mean Auth-Request-Type AVP
is optional? Base 8.7 does not talk about this. Please
clarify. Suggestion: don't talk about defaults.
DJM: On some AAR messages it is. Because this message is used for
Multi-round exchanges, many AVPs are not used in all cases.
I believe that the use of a default is obvious. It also helps with
translation issues.
...
8. NAS Accounting
JARI: Earlier in the document there was some confusion about when
accounting messages should be sent.
DJM: This description and the earlier Session description have been
redone.
Authentication or Authorization transaction and at the end of a
Session. The Accounting-Record-Type value indicates the type of
event. All other AVPs identify the session and provide additional
information relevant to the event.
If Authentication and Authorization are contained in one message
(typical case), then one START_RECORD should be sent. If
Authentication and Authorization occur in seperate transactions, the
first message should generate a START_RECORD, and the later, an
INTERIM_RECORD. For a given session, there should only be one set of
matching START and STOP records, with any number of INTERIM_RECORDS
in between, or one EVENT_RECORD.
JARI: Compare to Section 2.1. I'm not sure I understand what "failure
to start a session" exactly means, but let's assume we do a
successful authentication, successful authorization, and the
"fail to start a session". It would be incorrect in this case to
send START_RECORD, INTERIM_RECORD, EVENT_RECORD, as seems to be
indicated by 2.1. Suggestion: make 2.1 inline with the text
here.
DJM: Your example is indeed incorrect. Every START_RECORD MUST be
paired with a STOP_RECORD. EVENT_RECORDs are for non-session
events.
This text and others related have been rewritten.
...
The corresponding Diameter response is always guaranteed to be
received by the same Translation Agent that translated the original
request, due to the contents of the Origin-Host AVP in the Diameter
request. The following steps are applied to the response message
during the Diameter to RADIUS translation:
- If the Diameter Command-Code is set to AA-Answer and the Result-
Code AVP is set to DIAMETER_MULTI_ROUND_AUTH, the gateway must
send a RADIUS Access-Challenge with the Diameter Session-Id and
the Origin-Host AVPs encapsulated in the RADIUS State attribute,
with the prefix "Diameter/". This is necessary in order to
ensure that the Translation Agent that will receive the
subsequent RADIUS Access-Request will have access to the Session
Identifier, and be able to set the Destination-Host to the
correct value. If the Multi-Round-Time-Out AVP is present, the
value of the AVP MUST be inserted in the RADIUS Session-Timeout
AVP.
- If the Command-Code is set to AA-Answer, the Diameter Session-Id
AVP is saved in a new RADIUS Class attribute, whose format
consists of the string "Diameter/" followed by the Diameter
Session Identifier. This will ensure that the subsequent
Accounting messages, which could be received by any Translation
Agent, would have access to the original Diameter Session
Identifier.
- If a Proxy-State attribute was present in the RADIUS request,
the same attribute is added in the response. This information
may be found in the Proxy-Info AVP group, or in a local state
table.
- If state information regarding the RADIUS request was saved in a
Proxy-Info AVP or local state table, the RADIUS Identifier and
UDP IP Address and port number are extracted and used in issuing
the RADIUS reply.
JARI: Question: Does the above rules work even in a situation where
there's been a change to another translation agent due to
load balancing or a fault?
DJM: I'm not sure. That would depend on how such a handover was
implemented, and this spec does not describe or specify such
behavior even for non-RADIUS cases.
...
10.1. AA-Request/Answer AVP Table
The table in this section is limited to the Command Codes defined in
this specification.
JARI: I don't understand the above comment. Remove?
DJM: This is needed. I have improved the text.
...
10.2.1. Accounting Framed Access AVP Table
JARI: I don't fully understand the construction of this table
vs. the one in the base spec. The above attribute,
for instance, is included but not discussed in this
specification. But some other base attributes such
as Auth-Application-Id are not included. Is this
an old version of the base table, with the NASREQ
additions? May I suggest taking a new version from
base-17...?
DJM: Please name any other AVPs not included? Are they required for all
Accounting applications? Do they have application for NASreq? I
will include them.
The BASE does not, and cannot describe this application, I must.
This application uses Base AVPs, how it uses them (not what they
are) must be described here, even if it's just an inclusion that
says it's allowable. I have added more verbage to make
these tables self explanatory.
...
12. Security Considerations
The security considerations of the Diameter protocol itself have
been discussed in [Base].
This document does not contain a security protocol, but does discuss
how PPP authentication protocols can be carried within the Diameter
protocol. The PPP authentication protocols that are described are PAP
and CHAP.
The use of PAP SHOULD be discouraged, since it exposes user's
passwords to possibly non-trusted entities. However, PAP is also
frequently used for use with One-Time Passwords (OTP), which do not
expose a security risk.
This document also describes how CHAP can be carried within the
Diameter protocol, which is required for RADIUS backward
compatibility. The CHAP protocol, as used in a RADIUS environment,
facilitates authentication replay attacks.
JARI: Any references to the attacks discussed above?
JARI: Maybe there should be some discussion of what it implies
if authorization-only AAA requests are made, and in which
cases such usage is safe.
DJM: Submissions are welcome.
JARI: What are the security impacts of RADIUS-DIAMETER translation?
Are all or only some of the known radius vulnerabilities carried
onto DIAMETER in such a setup? See reference "Joshua Hill. An
Analysis of the RADIUS Authentication Protocol.
http://www.untruth.org/~josh/security/radius/, 2001."
DJM: I have read that document in the past, however, we have tried
to document the Diameter NAS Application protocol in this document, and
avoided including a full treatis on Diameter/RADIUS how-to build a
gateway. This really requires another document. If I could make it
relate to my job (what's that?) I'd write it myself.
[David Mitton]: I'm closing Issue 402. Here is the resolution:
Issues #402:
JARI: Comments marked with "JARI:" DJM: Responses marked with "DJM:" major
snips to document marked with "..."
1.2. Advertising Application Support . . . . . . . . . . . . . . .
6
JARI: A terms section might be useful. NAS, ARAP, IPX, CHAP, PAP etc.
DJM: Added.
2. NAS Calls, Ports, and Sessions . . . . . . . . . . . . . . . . .
6
JARI: Looking at the contents list, it might make sense to change the
section titles from "NAS <something>" to simply
"<something>"?
What do you think?
DJM: I like the "NAS". At least it is a simplification from previously,
everything was NASREQ.
...
2.1. Diameter Session Establishment
When the authentication or authorization exchange completes
successfully, the NAS application SHOULD start a session context,
and
MAY send an Accounting START_RECORD message [Base]. The
failure to
JARI: The MAY above is a bit weak? Is this a configuration issue
again, or are NASes generally allowed to skip
accounting
if they feel like it? ;-)
DJM: Yes, I've reworded this per your later comments.
Accounting should not be skipped if implemented, but the spec
doesn't require the capability either.
JARI: Is there an AVP which holds the type of failure? Or are all
EVENT_RECORD messages for this particular error?
DJM: Yes, typically Termination-Cause, but it depends on the error.
2.2. Diameter Session Re-Authentication or Re-Authorization
...
JARI: Is this always possible? I think it is possible on PPP, but
perhaps there are other access types for which it
might not
be possible. Is re-auth possible on all types of
WLAN
links?
DJM: Maybe, maybe not. The feature is here, because it is possible on
some services.
JARI: While re-auth is going on, can service still be provided?
DJM: That too would be service specific.
JARI: Shouldn't we somehow take in account also
Accounting-Realtime-Required AVP from base?
DJM: A Note: is added.
More information on Diameter Session Termination is in [Base]
section
8.4.
3.1. AA-Request (AAR) Command
The AA-Request message (AAR), indicated by the Command-Code field
set
to 265 and the 'R' bit set in the Command Flags field, is used in
order to request authentication and/or authorization for a given
NAS
user. The type of request is identified through the
Auth-Request-Type
AVP, and the default mode is both authentication and authorization.
JARI: Default... hmm... does this mean Auth-Request-Type AVP
is optional? Base 8.7 does not talk about this.
Please
clarify. Suggestion: don't talk about defaults.
DJM: On some AAR messages it is. Because this message is used for
Multi-round exchanges, many AVPs are not used in all cases.
I believe that the use of a default is obvious. It also helps with
translation issues.
...
8. NAS Accounting
JARI: Earlier in the document there was some confusion about when
accounting messages should be sent.
DJM: This description and the earlier Session description have been
redone.
Authentication or Authorization transaction and at the end of a
Session. The Accounting-Record-Type value indicates the type
of
event. All other AVPs identify the session and provide
additional
information relevant to the event.
If Authentication and Authorization are contained in one message
(typical case), then one START_RECORD should be sent. If
Authentication and Authorization occur in seperate transactions,
the
first message should generate a START_RECORD, and the later, an
INTERIM_RECORD. For a given session, there should only be one
set of
matching START and STOP records, with any number of INTERIM_RECORDS
in between, or one EVENT_RECORD.
JARI: Compare to Section 2.1. I'm not sure I understand what "failure
to start a session" exactly means, but let's
assume we do a
successful authentication, successful
authorization, and the
"fail to start a session". It would be incorrect
in this case to
send START_RECORD, INTERIM_RECORD, EVENT_RECORD,
as seems to be
indicated by 2.1. Suggestion: make 2.1 inline
with the text
here.
DJM: Your example is indeed incorrect. Every START_RECORD MUST be
paired with a STOP_RECORD. EVENT_RECORDs are for non-session
events.
This text and others related have been rewritten.
...
The corresponding Diameter response is always guaranteed to be
received by the same Translation Agent that translated the original
request, due to the contents of the Origin-Host AVP in the Diameter
request. The following steps are applied to the response message
during the Diameter to RADIUS translation:
- If the Diameter Command-Code is set to
AA-Answer and the Result-
Code AVP is set to
DIAMETER_MULTI_ROUND_AUTH, the gateway must
send a RADIUS Access-Challenge with
the Diameter Session-Id and
the Origin-Host AVPs encapsulated in
the RADIUS State attribute,
with the prefix "Diameter/". This is
necessary in order to
ensure that the Translation Agent
that will receive the
subsequent RADIUS Access-Request will
have access to the Session
Identifier, and be able to set the
Destination-Host to the
correct value. If the
Multi-Round-Time-Out AVP is present, the
value of the AVP MUST be inserted in
the RADIUS Session-Timeout
AVP.
- If the Command-Code is set to AA-Answer, the
Diameter Session-Id
AVP is saved in a new RADIUS Class
attribute, whose format
consists of the string "Diameter/"
followed by the Diameter
Session Identifier. This will ensure
that the subsequent
Accounting messages, which could be
received by any Translation
Agent, would have access to the
original Diameter Session
Identifier.
- If a Proxy-State attribute was present in the
RADIUS request,
the same attribute is added in the
response. This information
may be found in the Proxy-Info AVP
group, or in a local state
table.
- If state information regarding the RADIUS
request was saved in a
Proxy-Info AVP or local state table,
the RADIUS Identifier and
UDP IP Address and port number are
extracted and used in issuing
the RADIUS reply.
JARI: Question: Does the above rules work even in a situation where
there's been a change to another translation
agent due to
load balancing or a fault?
DJM: I'm not sure. That would depend on how such a handover was
implemented, and this spec does not describe or specify such
behavior even for non-RADIUS cases.
...
10.1. AA-Request/Answer AVP Table
The table in this section is limited to the Command Codes defined
in
this specification.
JARI: I don't understand the above comment. Remove?
DJM: This is needed. I have improved the text.
...
10.2.1. Accounting Framed Access AVP Table
JARI: I don't fully understand the construction of this table
vs. the one in the base spec. The above
attribute,
for instance, is included but not discussed in
this
specification. But some other base attributes
such
as Auth-Application-Id are not included. Is this
an old version of the base table, with the NASREQ
additions? May I suggest taking a new version
from
base-17...?
DJM: Please name any other AVPs not included? Are they required for all
Accounting applications? Do they have application for NASreq? I
will include them.
The BASE does not, and cannot describe this application, I
must.
This application uses Base AVPs, how it uses them (not what
they
are) must be described here, even if it's just an inclusion
that
says it's allowable. I have added more verbage to
make
these tables self explanatory.
...
12. Security Considerations
The security considerations of the Diameter protocol itself
have
been discussed in [Base].
This document does not contain a security protocol, but does
discuss
how PPP authentication protocols can be carried within the Diameter
protocol. The PPP authentication protocols that are described are
PAP
and CHAP.
The use of PAP SHOULD be discouraged, since it exposes user's
passwords to possibly non-trusted entities. However, PAP is also
frequently used for use with One-Time Passwords (OTP), which do not
expose a security risk.
This document also describes how CHAP can be carried within the
Diameter protocol, which is required for RADIUS backward
compatibility. The CHAP protocol, as used in a RADIUS environment,
facilitates authentication replay attacks.
JARI: Any references to the attacks discussed above?
JARI: Maybe there should be some discussion of what it implies
if authorization-only AAA requests are made, and
in which
cases such usage is safe.
DJM: Submissions are welcome.
JARI: What are the security impacts of RADIUS-DIAMETER translation?
Are all or only some of the known radius
vulnerabilities carried
onto DIAMETER in such a setup? See reference
"Joshua Hill. An
Analysis of the RADIUS Authentication Protocol.
http://www.untruth.org/~josh/security/radius/, 2001."
DJM: I have read that document in the past, however, we have tried
to document the Diameter NAS Application protocol in this document, and
avoided including a full treatis on Diameter/RADIUS how-to build a
gateway. This really requires another document. If I could make it
relate to my job (what's that?) I'd write it myself.
[Jari Arkko]
David Mitton wrote:
Issues #402: JARI: Comments marked with "JARI:" DJM: Responses marked with "DJM:" major snips to document marked with "..." 1.2. Advertising Application Support . . . . . . . . . . . . . . . 6 JARI: A terms section might be useful. NAS, ARAP, IPX, CHAP, PAP etc. DJM: Added.
Great!
2. NAS Calls, Ports, and Sessions . . . . . . . . . . . . . . . . . 6
JARI: Looking at the contents list, it might make sense to change the
section titles from "NAS <something>" to simply "<something>"?
What do you think?
DJM: I like the "NAS". At least it is a simplification from previously,
everything was NASREQ.
...
No problem.
2.1. Diameter Session Establishment
When the authentication or authorization exchange completes
successfully, the NAS application SHOULD start a session context, and
MAY send an Accounting START_RECORD message [Base]. The failure to
JARI: The MAY above is a bit weak? Is this a configuration issue
again, or are NASes generally allowed to skip accounting
if they feel like it? ;-)
DJM: Yes, I've reworded this per your later comments.
Accounting should not be skipped if implemented, but the spec
doesn't require the capability either.
Is this is in the latest document or on some private version? I agree with what you say above. But I wonder if there should be some words about configuration as well. If you implement it, you may not in all cases need accounting.
JARI: Is there an AVP which holds the type of failure? Or are all
EVENT_RECORD messages for this particular error?
DJM: Yes, typically Termination-Cause, but it depends on the error.
Ok. Is this described now somewhere?
2.2. Diameter Session Re-Authentication or Re-Authorization
...
JARI: Is this always possible? I think it is possible on PPP, but
perhaps there are other access types for which it might not
be possible. Is re-auth possible on all types of WLAN
links?
DJM: Maybe, maybe not. The feature is here, because it is possible on
some services.
JARI: While re-auth is going on, can service still be provided?
DJM: That too would be service specific.
Ok. Are there words warning about the above in the latest version?
JARI: Shouldn't we somehow take in account also
Accounting-Realtime-Required AVP from base?
DJM: A Note: is added.
Great!
More information on Diameter Session Termination is in [Base] section
8.4.
3.1. AA-Request (AAR) Command
The AA-Request message (AAR), indicated by the Command-Code field set
to 265 and the 'R' bit set in the Command Flags field, is used in
order to request authentication and/or authorization for a given NAS
user. The type of request is identified through the Auth-Request-Type
AVP, and the default mode is both authentication and authorization.
JARI: Default... hmm... does this mean Auth-Request-Type AVP
is optional? Base 8.7 does not talk about this. Please
clarify. Suggestion: don't talk about defaults.
DJM: On some AAR messages it is. Because this message is used for
Multi-round exchanges, many AVPs are not used in all cases.
I believe that the use of a default is obvious. It also helps with
translation issues.
...
Ok.
8. NAS Accounting
JARI: Earlier in the document there was some confusion about when
accounting messages should be sent.
DJM: This description and the earlier Session description have been
redone.
Authentication or Authorization transaction and at the end of a
Session. The Accounting-Record-Type value indicates the type of
event. All other AVPs identify the session and provide additional
information relevant to the event.
If Authentication and Authorization are contained in one message
(typical case), then one START_RECORD should be sent. If
Authentication and Authorization occur in seperate transactions, the
first message should generate a START_RECORD, and the later, an
INTERIM_RECORD. For a given session, there should only be one set of
matching START and STOP records, with any number of INTERIM_RECORDS
in between, or one EVENT_RECORD.
Ok.
JARI: Compare to Section 2.1. I'm not sure I understand what "failure
to start a session" exactly means, but let's assume we do a
successful authentication, successful authorization, and the
"fail to start a session". It would be incorrect in this case to
send START_RECORD, INTERIM_RECORD, EVENT_RECORD, as seems to be
indicated by 2.1. Suggestion: make 2.1 inline with the text
here.
DJM: Your example is indeed incorrect. Every START_RECORD MUST be
paired with a STOP_RECORD. EVENT_RECORDs are for non-session
events.
This text and others related have been rewritten.
Great, thanks!
...
The corresponding Diameter response is always guaranteed to be
received by the same Translation Agent that translated the original
request, due to the contents of the Origin-Host AVP in the Diameter
request. The following steps are applied to the response message
during the Diameter to RADIUS translation:
- If the Diameter Command-Code is set to AA-Answer and the Result-
Code AVP is set to DIAMETER_MULTI_ROUND_AUTH, the gateway must
send a RADIUS Access-Challenge with the Diameter Session-Id and
the Origin-Host AVPs encapsulated in the RADIUS State attribute,
with the prefix "Diameter/". This is necessary in order to
ensure that the Translation Agent that will receive the
subsequent RADIUS Access-Request will have access to the Session
Identifier, and be able to set the Destination-Host to the
correct value. If the Multi-Round-Time-Out AVP is present, the
value of the AVP MUST be inserted in the RADIUS Session-Timeout
AVP.
- If the Command-Code is set to AA-Answer, the Diameter Session-Id
AVP is saved in a new RADIUS Class attribute, whose format
consists of the string "Diameter/" followed by the Diameter
Session Identifier. This will ensure that the subsequent
Accounting messages, which could be received by any Translation
Agent, would have access to the original Diameter Session
Identifier.
- If a Proxy-State attribute was present in the RADIUS request,
the same attribute is added in the response. This information
may be found in the Proxy-Info AVP group, or in a local state
table.
- If state information regarding the RADIUS request was saved in a
Proxy-Info AVP or local state table, the RADIUS Identifier and
UDP IP Address and port number are extracted and used in issuing
the RADIUS reply.
Ok.
JARI: Question: Does the above rules work even in a situation where
there's been a change to another translation agent due to
load balancing or a fault?
DJM: I'm not sure. That would depend on how such a handover was
implemented, and this spec does not describe or specify such
behavior even for non-RADIUS cases.
Ok. But maybe the limitation should be documented.
... 10.1. AA-Request/Answer AVP Table The table in this section is limited to the Command Codes defined in this specification. JARI: I don't understand the above comment. Remove? DJM: This is needed. I have improved the text.
Ok.
...
10.2.1. Accounting Framed Access AVP Table
JARI: I don't fully understand the construction of this table
vs. the one in the base spec. The above attribute,
for instance, is included but not discussed in this
specification. But some other base attributes such
as Auth-Application-Id are not included. Is this
an old version of the base table, with the NASREQ
additions? May I suggest taking a new version from
base-17...?
DJM: Please name any other AVPs not included? Are they required for all
Accounting applications? Do they have application for NASreq? I
will include them.
The BASE does not, and cannot describe this application, I must.
This application uses Base AVPs, how it uses them (not what they
are) must be described here, even if it's just an inclusion that
says it's allowable. I have added more verbage to make
these tables self explanatory.
I'll have to take a more detailed look at this later. What you say makes sense. I'll try to do a check of the tables.
...
12. Security Considerations
The security considerations of the Diameter protocol itself have
been discussed in [Base].
This document does not contain a security protocol, but does discuss
how PPP authentication protocols can be carried within the Diameter
protocol. The PPP authentication protocols that are described are PAP
and CHAP.
The use of PAP SHOULD be discouraged, since it exposes user's
passwords to possibly non-trusted entities. However, PAP is also
frequently used for use with One-Time Passwords (OTP), which do not
expose a security risk.
This document also describes how CHAP can be carried within the
Diameter protocol, which is required for RADIUS backward
compatibility. The CHAP protocol, as used in a RADIUS environment,
facilitates authentication replay attacks.
JARI: Any references to the attacks discussed above?
JARI: Maybe there should be some discussion of what it implies
if authorization-only AAA requests are made, and in which
cases such usage is safe.
DJM: Submissions are welcome.
The one below may be sufficient for the second attack. 2869bis talks about some of the PAP attacks, though not the one discussed above. A ten minute search to the net on PAP attacks did not reveal anything interesting. Maybe its too obvious.
JARI: What are the security impacts of RADIUS-DIAMETER translation?
Are all or only some of the known radius vulnerabilities carried
onto DIAMETER in such a setup? See reference "Joshua Hill. An
Analysis of the RADIUS Authentication Protocol.
http://www.untruth.org/~josh/security/radius/, 2001."
DJM: I have read that document in the past, however, we have tried
to document the Diameter NAS Application protocol in this document, and
avoided including a full treatis on Diameter/RADIUS how-to build a
gateway. This really requires another document. If I could make it
relate to my job (what's that?) I'd write it myself.
Ok. --Jari
[David Mitton]
On 7/11/2003 10:14 PM +0300, Jari Arkko wrote:
2.1. Diameter Session Establishment When the authentication or authorization exchange completes successfully, the NAS application SHOULD start a session context, and MAY send an Accounting START_RECORD message [Base]. The failure to JARI: The MAY above is a bit weak? Is this a configuration issue again, or are NASes generally allowed to skip accounting if they feel like it? ;-) DJM: Yes, I've reworded this per your later comments. Accounting should not be skipped if implemented, but the spec doesn't require the capability either.Is this is in the latest document or on some private version? I agree with what you say above. But I wonder if there should be some words about configuration as well. If you implement it, you may not in all cases need accounting.
Draft 12 is availible from the IETF server.
I don't have a rev ... yet.
Let me try again - Accounting is not a required capability of a NASreq
application, but if Accounting is implemented, it MUST follow the specifications
given. In particular the type and sequence of records must be conformant to
allow interoperable server implementations.
Dave.
Proposed Resolution: Accept
Issue 403: NASREQ-11 Review
Submitter name: John Loughney
Submitter email
address: john.loughney@nokia.com
Date first submitted: March 8, 2003
Reference:
Document: NASREQ-11
Comment type: Technical
Priority: S
Section:
Rationale/Explanation of issue:
NASREQ-11 looks good. I saw Jari did a detailed review, so mine is somewhat
less detailed. Some comments that things that caught my eye:
1) Abstract: spell out EAP and CMS.
2) Terminology section could be useful to add, but maybe reference
the Base spec terminology & just add new terms.
3) Indentation problem in 4.1
4) 4.1, first sentence:
This section contains the NAS unique AVPs that are needed to identify
sounds a bit awkward, maybe dropping the NAS would make more gramatical sense.
I think that Jari seemed to get everything else I had noted down.
Issue 404: NASREQ-11 Issues
Submitter name: Bernard Aboba
Submitter email
address: aboba@internaut.com
Date first submitted: March 11, 2003
Reference:
Document: NASREQ-11
Comment type: Technical
Priority: S
Section: Various
Rationale/Explanation of issue:
Section 1
" This document describes Diameter applications that are used for AAA
in the Network Access Server (NAS) environment."
Doesn't the document just describe a single
application? Suggested change:
"This document describes the Diameter NAS application,
which, when combined...."
Section 1.2
"1.2. Advertising Application Support
Diameter nodes conforming to this specification MAY advertise support
by including the value of one (1) in the Auth-Application-Id or the
Acct-Application-Id AVP of the Capabilities-Exchange-Request and
Capabilities-Exchange-Answer commands [Base]."
Isn't advertisement mandatory? Shouldn't the MAY be a MUST?
Section 2
" Unlike the RADIUS protocol [RADIUS], the Diameter protocol does not
require authentication information to be contained in a request from
the client. Therefore, it is possible to send a request for
authorization only. The type of service depends upon the Auth-
Request-Type AVP. This difference MAY cause operational issues in
environments that need RADIUS interoperability, and it MAY be
necessary that protocol conversion gateways add authentication
information when transmitting to a RADIUS server."
The RADIUS protocol doesn't require authentication information to be
included in a Call-Check, so this isn't accurate. The use of a
capital MAY is inappropriate. Adding authentication information in
a gateway seems questionable security-wise.
Rewrite to:
"The Diameter protocol allows authorization-only requests
depending on the Auth-Request-Type AVP, where no authentication
information is contained in a request from the client. This
capability goes beyond the Call Check capabilities described
in Section 5.6 of [RADIUS] in that no access decision is
requested. As a result, service cannot be started as a result
of a response to an authorization-only request without
introducing a significant security vulnerability.
Since no equivalent capability exists in RADIUS, authorization-only
requests from a NAS implementing Diameter may not be easily
translated to an equivalent RADIUS message by a Diameter/RADIUS
gateway. For example, where a Diameter authorization-only request
cannot be translated to a RADIUS Call Check, it would be necessary
for the Diameter/RADIUS gateway to add authentication information
to the RADIUS Access Request. On receiving the Access-Reply, the
Diameter/RADIUS gateway would need to discard the access decision
(Accept/Reject). It is not clear that these translations can be
accomplished without adding significant security vulnerabilities."
Section 2.2
"A Diameter server
informs the NAS of the maximum time allowed before re-authentication
or re-authorization via the Authorization-Lifetime AVP [Base]. Note,
however, that the Authorization-Lifetime AVP SHOULD NOT be used if
the AAR message contained a NAS-IP-Address, NAS-IPv6-Address, or NAS-
Identifier AVP since this would mean that the NAS is using RADIUS
which does not support server-initiated re-authentication or re-
authorization."
The 2nd sentence is correct, but it doesn't follow from the first.
The issue is not that the Diameter server informs the NAS of the
maximum time allowed; after all, this is what RADIUS does. The issue
is the ability to handle a server-initiated re-authentication or
re-authorization. This paragraph confuses the two issues. Rewrite to:
"A Diameter server
informs the NAS of the maximum time allowed before re-authentication
or re-authorization via the Authorization-Lifetime AVP [Base].
A NAS MUST re-authenticate and/or re-authorize after the period provided
by the Authorization-Lifetime AVP. Furthermore, it is possible for
Diameter servers to issue an unsolicited re-authentication and/or
re-authorization requests (e.g. Re-Auth-Request (RAR) message) to
the NAS. Upon receipt of such a message, the NAS issues a request
to re-authenticate and/or re-authorize the client."
See Issue 405 for additional discussion on this.
Section 3.1
" It is possible for a single session to be authorized first, then
followed by an authentication request."
It would help to provide an example of when this would be desirable.
Unfortunately, I can't think of any.
The ABNF for AAR includes support for RADIUS attributes not allowable in
an Access-Request, including Session-Timeout, Idle-Timeout, and Class.
To avoid problems in translation, I'd avoid including these AVPs in the
ABNF.
The AAR ABNF also does not include the Proxy-State AVP, which is allowed
in a RADIUS Access Request. This is because the Proxy-Info AVP takes its
place, no?
Section 3.2
The Proxy-State attribute is not listed in the ABNF for AA-Answer. I assume
it is not supported because Proxy-Info AVP takes its place.
Section 4
" AVPs new to Diameter have code values 256 and greater. A Diameter
message that includes one of these AVPs MAY cause interoperability
issues should the request traverse a AAA node that only supports the
RADIUS protocol. However, the Diameter protocol should not be
hampered from future developments due to the existing installed base."
The MAY doesn't need to be capitalized here. Also, backward compatibility
is achievable as described in Issue 405. Rewrite to:
" AVPs new to Diameter have code values 256 and greater. Diameter
messages including one or more of these AVPs may cause interoperability
problems should the request traverse a AAA node that only supports
RADIUS. "
RADIUS compatibility is further addressed in Issue 405.
Section 4.5
" The Called-Station-Id AVP (AVP Code 30) is of type UTF8String, and
allows the NAS to send in the request, the ASCII string of the phone
number that the user called, using Dialed Number Identification
(DNIS) or a similar technology. Note that this may be different from
the phone number the call comes in on. It SHOULD only be present in"
The Called-Station-Id can also contain a MAC address, as in
draft-congdon-radius-8021x-23.txt. To cover this and other cases I
would change this to:
"The Called-Station-Id AVP (AVP Code 30) is of type UTF8String, and
allows the NAS to send in the request, the ASCII string describing the layer 2
address that the user contacted to. For dialup access, this can
be a phone number, obtained using Dialed Number Identification
(DNIS) or a similar technology. Note that this may be different
from the phone number the call comes in on. For use with IEEE 802
access, the Called-Station-Id MAY contain a MAC address,
formatted as described in [Congdon]."
4.6
" The Calling-Station-Id AVP (AVP Code 31) is of type UTF8String, and
allows the NAS to send in the request the the ASCII string of the
phone number that the call came from, using Automatic Number
Identification (ANI) or a similar technology. It SHOULD only be
present in authentication and/or authorization requests.
If the Auth-Request-Type AVP is set to authorization-only and the
User-Name AVP is absent, the Diameter Server MAY perform
authorization based on this field. This can be used by a NAS to
request whether a call should be answered based on the ANI.
"
Change to:
"The Calling-Station-Id AVP (AVP Code 31) is of type UTF8String, and
allows the NAS to send in the request the the ASCII string describing
the layer 2 address that the user connected from. For dialup access, this
is the phone number that the call came from, using Automatic Number
Identification (ANI) or a similar technology. For use with IEEE 802
access, the Calling-Station-Id AVP MAY contain a MAC address,
formated as described in [Congdon]. It SHOULD only be
present in authentication and/or authorization requests.
If the Auth-Request-Type AVP is set to authorization-only and the
User-Name AVP is absent, the Diameter Server MAY perform
authorization based on this field. This can be used by a NAS to
request whether a call should be answered based on the layer 2
address (ANI, MAC Address, etc.)"
4.7
As described, the Connect-Info attribute is only useful for dialup.
Change:
" The Connect-Info AVP (AVP Code 77) is of type UTF8String and is sent
in the AA-Request message, and indicates the nature of the user's
connection. The connection speed SHOULD be included at the beginning
of the first Connect-Info AVP in the message. If the transmit and
receive connection speeds differ, they may both be included in the
first AVP with the transmit speed first (the speed the NAS modem
transmits at), a slash (/), the receive speed, then optionally other
information.
For example, "28800 V42BIS/LAPM" or "52000/31200 V90"
"
To:
" The Connect-Info AVP (AVP Code 77) is of type UTF8String and is sent
in the AA-Request or ACR STOP message. When sent in the
Access-Request it indicates the nature of the user's
connection. The connection speed SHOULD be included at the beginning
of the first Connect-Info AVP in the message. If the transmit and
receive connection speeds differ, they may both be included in the
first AVP with the transmit speed first (the speed the NAS
transmits at), a slash (/), the receive speed, then optionally other
information. Examples:
"28800 V42BIS/LAPM", "52000/31200 V90" or "11 Mbps 802.11b"
If sent in the ACR STOP, this attribute may be used to
summarize statistics relating to session quality. For example,
in IEEE 802.11, the Connect-Info attribute may contain information
on the number of link layer retransmissions. The exact format of
this attribute is implementation specific."
Section 4.l0
" When used by 802.1X supplicants, the service typically terminates due
to the expiry of the Session-Timeout AVP. The access device may then
reauthenticate the user with a new AA-Request. The RECOMMENDED way
to do this in Diameter is to use the Authorization-Lifetime AVP
rather than the Termination-Action AVP. However, the Termination-
Action AVP MAY be used when copied from a RADIUS Access-Accept to a
Diameter AA-Answer by a Translation Agent."
This contradicts Section 2.2, which says that the Authorization-Lifetime
AVP SHOULD NOT be used with RADIUS clients. The only alternative is to
use Session-Timeout and Termination-Action, but that doesn't do the job,
since the meaning has been changed. This leaves a Diameter server
incapable of communicating that it would like a RADIUS client to
re-authenticate at a given interval. The suggested fix is to change
the meaning of Termination-Action so that it is compatible with RADIUS.
Section 6.1
" The Service-Type AVP (AVP Code 6) is of type Enumerated and contains
the type of service the user has requested, or the type of service to
be provided. One such AVP MAY be present in an authentication and/or
authorization request or response. A NAS is not required to implement
all of these service types, and MUST treat unknown or unsupported
Service-Types as though a response with a Result-Code other than
Diameter-SUCCESS had been received instead."
Is this the same as saying that the authentication failed?
Note also that Service-Types 15 and 16 have recently been defined by IEEE
802.11f.
Should these be included in the list?
Section 8
"If Authentication and Authorization occur in seperate transactions, the
first message should generate a START_RECORD, and the later, an
INTERIM_RECORD."
This assumes that service is begun once the authorization response is received,
correct? Also "seperate" is misspelled.
I think you need to add Connect-Info to the list of Accounting AVPs.
Section 9
Why does this section include a table with NAS-Identifier,
NAS-IP-Address, NAS-IPv6-Address, etc.? This looks like it
belonged somewhere else and ended up here by mistake.
" Note that this section uses the two terms; AVP and attribute in a
consise manner. The former is used to signify a Diameter AVP, while
the latter is used to signify a RADIUS attribute."
Do you mean "consistent manner"?
Section 9.1
"Therefore, a
RADIUS/Diameter Translation Agent SHOULD NOT assume to track session
state information."
I think you mean "SHOULD NOT be assumed", no?
" - If a Message-Authenticator attribute is present, it MUST be
checked and discarded. The gateway system SHOULD generate and
include a Message-Authenticator in return responses to this
system."
I think you mean that it is checked, and if valid, then it is not included
within the Diameter message; if invalid, then the packet is silently discarded.
" - The Diameter Origin-Host and Origin-Realm AVPs MUST be created
and added using the information from the NAS-Identifier
attribute, and/or the FQDN corresponding to the NAS-IP-Address
attribute. The AAA protocol specified in the identity would be
set to "RADIUS"."
I think that the FQDN corresponding to the NAS-IP-Address is preferred,
if available.
" - If the RADIUS message contains an address attribute, (e.g.
Framed-IP-Address, Login-IP-Host, Login-IPv6-Host, NAS-IP-
Address, NAS-IPv6-Address) it MUST be converted to the
appropriate Diameter AVP and Address type."
Didn't we dump the idea of address type?
9.1.1
" - The Origin-Host AVP's value is inserted in the NAS-Identifier
attribute."
How about also supporting translation of Origin-Host AVP to
NAS-IP-Address or NAS-IPv6-Adddress?
9.4
"If this is not possible, an attribute error should be
returned."
Not sure which protocol this is referring to. RADIUS doesn't support
error messages, and Diameter doesn't have attribute (only AVPs).
9.5.2
" The Diameter AVP will consist of the following fields;
Diameter Flags: V=1, M=0, P=0
Diameter Vendor code = RADIUS VSA Vendor code
Diameter AVP code = RADIUS VSA Vendor type code
Diameter AVP length = length of AVP (header + data + padding)
Diameter Data = RADIUS VSA vendor data
If the RADIUS receiving code knows of vendor specific fields
interpretations for the specific vendor, it may employ them to parse
an extended AVP code or data length, Otherwise the recommended
standard fields will be used.
Nested Multiple vendor data fields MUST be expanded into multiple
Diameter AVPs."
Forwarding a RADIUS Vendor-Specific AVP as non-mandatory
could be dangerous in some circumstances, such as when a
proprietary filter or key attribute is included. I'd suggest
setting M=1 by default.
13.1
"[AAATrans] B. Aboba, J. Wood. "Authentication, Authorization and
Accounting (AAA) Transport Profile", draft-ietf-aaa-
transport-08, IETF work in progress, April 2002"
Latest version is -12.
Additional comments
I believe that it would be useful to talk about translation of unsolicited
disconnect
or change of filters messages to their RADIUS equivalents, defined in
[DynAuth].
[David Mitton]
Section 4.l0
" When used by 802.1X supplicants, the service typically terminates due
to the expiry of the Session-Timeout AVP. The access device may then
reauthenticate the user with a new AA-Request. The RECOMMENDED way
to do this in Diameter is to use the Authorization-Lifetime AVP
rather than the Termination-Action AVP. However, the Termination-
Action AVP MAY be used when copied from a RADIUS Access-Accept to a
Diameter AA-Answer by a Translation Agent."
This contradicts Section 2.2, which says that the Authorization-Lifetime
AVP SHOULD NOT be used with RADIUS clients. The only alternative is to
use Session-Timeout and Termination-Action, but that doesn't do the job,
since the meaning has been changed. This leaves a Diameter server
incapable of communicating that it would like a RADIUS client to
re-authenticate at a given interval. The suggested fix is to change
the meaning of Termination-Action so that it is compatible with RADIUS.
DJM: - change Termination-Action, so that it does not require the
resetting Session-ID and sending STR. more consistent with RADIUS
- Rework Auth-Lifetime description so it offers gwy solutions
- Add to RADIUS interactions section, what to do with A-L AVP
---
9.1.something...
" - The Diameter Origin-Host and Origin-Realm AVPs MUST be created
and added using the information from the NAS-Identifier
attribute, and/or the FQDN corresponding to the NAS-IP-Address
attribute. The AAA protocol specified in the identity would be
set to "RADIUS"."
I think that the FQDN corresponding to the NAS-IP-Address is preferred,
if available.
DJM: Okay, done.
9.1.1
" - The Origin-Host AVP's value is inserted in the NAS-Identifier
attribute."
How about also supporting translation of Origin-Host AVP to
NAS-IP-Address or NAS-IPv6-Adddress?
DJM: This is a server response. The NAS id information is not
present in the RADIUS message. I have reworked this section to make it
clearer. The information must either be saved at request time or
derived from context.
9.5.2
" The Diameter AVP will consist of the following fields;
Diameter Flags: V=1, M=0, P=0
Diameter Vendor code = RADIUS VSA Vendor code
Diameter AVP code = RADIUS VSA Vendor type code
Diameter AVP length = length of AVP (header + data + padding)
Diameter Data = RADIUS VSA vendor data
If the RADIUS receiving code knows of vendor specific fields
interpretations for the specific vendor, it may employ them to parse
an extended AVP code or data length, Otherwise the recommended
standard fields will be used.
Nested Multiple vendor data fields MUST be expanded into multiple
Diameter AVPs."
Forwarding a RADIUS Vendor-Specific AVP as non-mandatory
could be dangerous in some circumstances, such as when a
proprietary filter or key attribute is included. I'd suggest
setting M=1 by default.
DJM: Hmmm... this is a toughie. I agree with your intent, but I think
in practice some RADIUS services are used to sending a scattershot VSA
list that covers all of their configured vendors. They know the
equipment will ignore the unrecognized attributes. Funk's SBR takes a
slightly more sophisticated approach in that it will filter VSAs in
the response profile from in the Access Response message if it knows the
NAS vendor type (by configuration).
This would be a good filter option for a gateway.
Well maybe if we default mandatory, but allow local modification?
13.1
DJM: I'm sure there are a number of drafts to update in this section. A
couple documents have gone to RFC now too. I will do this as a last pass
before the next submission.
Additional comments
I believe that it would be useful to talk about translation of unsolicited
disconnect
or change of filters messages to their RADIUS equivalents, defined in
[DynAuth].
DJM: DynAuth support is optional. Should be treated like
server-initiated AAR, with RE-Auth=X
- RADIUS message (per Chiba) translated or processed as above
- Response translated
[David Mitton]: I'm closing Issue 404. Here are the proposed changes:
Section 4.l0
" When used by 802.1X supplicants, the service typically terminates due
to the expiry of the Session-Timeout AVP. The access device may then
reauthenticate the user with a new AA-Request. The RECOMMENDED way
to do this in Diameter is to use the Authorization-Lifetime AVP
rather than the Termination-Action AVP. However, the Termination-
Action AVP MAY be used when copied from a RADIUS Access-Accept to a
Diameter AA-Answer by a Translation Agent."
This contradicts Section 2.2, which says that the Authorization-Lifetime
AVP SHOULD NOT be used with RADIUS clients. The only alternative is to
use Session-Timeout and Termination-Action, but that doesn't do the job,
since the meaning has been changed. This leaves a Diameter server
incapable of communicating that it would like a RADIUS client to
re-authenticate at a given interval. The suggested fix is to change
the meaning of Termination-Action so that it is compatible with RADIUS.
DJM: - change Termination-Action, so that it does not require the
resetting Session-ID and sending STR. more consistent with RADIUS
- Rework Auth-Lifetime description so it offers gwy solutions
- Add to RADIUS interactions section, what to do with A-L AVP
---
9.1.something...
" - The Diameter Origin-Host and Origin-Realm AVPs MUST be created
and added using the information from the NAS-Identifier
attribute, and/or the FQDN corresponding to the NAS-IP-Address
attribute. The AAA protocol specified in the identity would be
set to "RADIUS"."
I think that the FQDN corresponding to the NAS-IP-Address is preferred,
if available.
DJM: Okay, done.
9.1.1
" - The Origin-Host AVP's value is inserted in the NAS-Identifier
attribute."
How about also supporting translation of Origin-Host AVP to
NAS-IP-Address or NAS-IPv6-Adddress?
DJM: This is a server response. The NAS id information is not
present in the RADIUS message. I have reworked this section to make it
clearer. The information must either be saved at request time or
derived from context.
9.5.2
" The Diameter AVP will consist of the following fields;
Diameter Flags: V=1, M=0, P=0
Diameter Vendor code = RADIUS VSA Vendor code
Diameter AVP code = RADIUS VSA Vendor type code
Diameter AVP length = length of AVP (header + data + padding)
Diameter Data = RADIUS VSA vendor data
If the RADIUS receiving code knows of vendor specific fields
interpretations for the specific vendor, it may employ them to parse
an extended AVP code or data length, Otherwise the recommended
standard fields will be used.
Nested Multiple vendor data fields MUST be expanded into multiple
Diameter AVPs."
Forwarding a RADIUS Vendor-Specific AVP as non-mandatory
could be dangerous in some circumstances, such as when a
proprietary filter or key attribute is included. I'd suggest
setting M=1 by default.
DJM: Hmmm... this is a toughie. I agree with your intent, but I think
in practice some RADIUS services are used to sending a scattershot VSA
list that covers all of their configured vendors. They know the
equipment will ignore the unrecognized attributes. Funk's SBR takes a
slightly more sophisticated approach in that it will filter VSAs in
the response profile from in the Access Response message if it knows the
NAS vendor type (by configuration).
This would be a good filter option for a gateway.
Well maybe if we default mandatory, but allow local modification?
13.1
DJM: I'm sure there are a number of drafts to update in this section. A
couple documents have gone to RFC now too. I will do this as a last pass before
the next submission.
Additional comments
I believe that it would be useful to talk about translation of unsolicited
disconnect
or change of filters messages to their RADIUS equivalents, defined in
[DynAuth].
DJM: DynAuth support is optional. Should be treated like
server-initiated AAR, with RE-Auth=X
- RADIUS message (per Chiba) translated or processed as above
- Response translated
Proposed Resolution: Accept
Issue 405: RADIUS compatibility
Submitter name: Bernard Aboba
Submitter email
address: aboba@internaut.com
Date first submitted: March 11, 2003
Reference:
Document: NASREQ-11
Comment type: Technical
Priority: S
Section: 9
Rationale/Explanation of issue:
As noted in Section 2.2, it is possible for a Diameter server to
know that it is talking to a RADIUS client. This is indicated
by an AAR message containing a NAS-IP-Address, NAS-IPv6-Address
or NAS-Identifier AVP.
Given this, the Diameter can restrict itself to use of RADIUS
compatible attributes and commands.
It also occurred to me that it would be worthwhile to deal with the case
where a Diameter NAS is talking to a RADIUS server. Here the dynamic is a
bit different, because the Diameter NAS may not know it is talking to a
RADIUS server, and the RADIUS server may not know it is talking to a
Diameter NAS.
However, the first time that the Diameter NAS includes an attribute >255,
or uses a Diameter-only capability, it will presumably get back an error
message from the Diameter/RADIUS gateway. At that point, the Diameter NAS
should limit its dialect to RADIUS compatibility mode.
Given that the RADIUS/Diameter gateway is a NASREQ function, I expected to
find some discussion of gateway error messages in the document, but in
searching through it, there is really no discussion of the Error-Message
AVP usage within this application.
It is not entirely clear to me that the DIAMETER_AVP_UNSUPPORTED or
DIAMETER_AVP_NOT_ALLOWED messages are appropriate for a case where an AVP
is >255 and therefore cannot be translated. Perhaps we need a
DIAMETER_AVP_UNTRANSLATABLE error message?
Similarly, DIAMETER_COMMAND_UNSUPPORTED doesn't seem like the right error
message for the case where a command can't be translated (e.g. unsolicited
Diameter disconnect reaching a gateway that doesn't support [DynAuth]).
Perhaps a DIAMETER_COMMAND_UNTRANSLATABLE is needed?
I would suggest that a discussion of this
issue be included in a separate sub-section of Section 9:
"9.X.X RADIUS compatibility mode
Since the NAS-IP-Address, NAS-IPv6-Address or NAS-Identifier AVPs
are not used by Diameter clients within AAR messages, the presence
of these attributes indicates that the Request was originated
by a RADIUS client and subsequently translated.
A Diameter server receiving such a message SHOULD restrict itself
to use of AVPs within the range 0-255, so as to ensure RADIUS
backward compatibility.
In addition, the Authorization-Lifetime AVP SHOULD
NOT be included in an AA-Answer message relating to such a session;
instead the equivalent RADIUS attributes (e.g. Session-Timeout and
Termination-Action) SHOULD be used instead. Within Diameter these
attributes have the same meaning as within RADIUS.
When a Diameter/RADIUS gateway
encounters an untranslatable AVP, it will
return a DIAMETER_AVP_UNTRANSLATABLE value in the
Error-Message AVP. A Diameter NAS encountering
this error SHOULD restrict itself to use of AVPs
with the range 0-255 so as to ensure RADIUS backward
compatibility.
Similarly, when a Diameter/RADIUS
gateway encounters an untranslatable command, it will
return a DIAMETER_COMMAND_UNTRANSLATABLE value in
the Error-Message AVP. A Diameter NAS encountering
this error SHOULD restrict use of the offending
command, so as to ensure RADIUS backward compatibility.
Since RADIUS does not support server-initiated re-authentication
and implementations may not support server-initiated re-authorization
[DynAuth], a Diameter server SHOULD NOT attempt server-initiated
re-authentication for a session known to be initiated by a RADIUS
client. A Diameter server MAY attempt server-initiated re-authorization
or session termination for a session known to be initiated by a
RADIUS client. However, it will typically receive a
DIAMETER_COMMAND_UNTRANSLATABLE error message in response.
A Diameter server encountering this error SHOULD NOT continue
to attempt server-initiated re-authorization or session-termination
for that NAS. "
Issue 406: Context removal
Submitter name: Bernard Aboba
Submitter email
address: aboba@internaut.com
Date first submitted: March 11, 2003
Reference:
Document: NASREQ-11
Comment type: Technical
Priority: S
Section: 2.3
Rationale/Explanation of issue:
" Further, a NAS that receives a Abort-Session-Request (ASR)
[Base]
MUST issue an STR if the session requested is active, and
disconnect
the PPP (or tunneling) session.
Termination of the session context, MUST cause the sending of an
Accounting STOP_RECORD message [Base], if accounting is active.
"
What this doesn't say is that *all* context relating to the session
MUST be removed, including key state. This is important in the case
of access points which may cache the PMK. Note that termination
of the session can occur without removing all session context.
Rewrite to:
" Further, a NAS that receives a Abort-Session-Request (ASR) [Base]
MUST issue an STR if the session requested is active, disconnect
the session and completely remove all context associated with the session.
Termination of the session MUST cause the sending of an
Accounting STOP_RECORD message [Base], if accounting is active.
"
Issue 407: Diameter Credit Control Review
Submitter name: Bernard Aboba
Submitter email
address: aboba@internaut.com
Date first submitted: May 9, 2003
Reference:
http://www.drizzle.com/~aboba/AAA/draft-ietf-aaa-diameter-cc-00.txt
Document: CC-00
Comment type: Technical
Priority: S
Section: Various
Rationale/Explanation of issue:
Detailed comments are provided at the referenced URL above.
Overall, I come away from a first reading of this draft concerned
about whether the architecture presented here is compatible with the
Diameter authentication/authorization/accounting model. It seems like
authentication/authorization decisions such as access or
resource usage (e.g. Session-Time) are being handled in accounting
messages. This is incompatible with the RADIUS model in case it is
ever useful to gateway RADIUS pre-paid to Diameter pre-paid.
It is also different from the semantics of both Diameter
Base authentication/authorization and accounting messages.
It seems cleaner to me to use a conventional authentication
request/response sequence to inform the Diameter server of
the requested service, and have the Diameter server do the
service rating, and check the user's credit allocation.
The Diameter server can then return the allocated resource
usage prior to re-authorization. When the Diameter client
has expended the allocated resources it will send a
re-authorization request (actually you probably want
it to send one sooner in case there are delays). The
Diameter server can then check the user's credit
limit and the service rating again and allocate more
resources, or deny the request and force the user
off.
This model is simpler because it doesn't require
communication of rating information to the NAS,
and just needs the NAS to monitor basic resource
usage. It also relies on basic facilities and
semantics defined in Diameter Base.
The one facility that wouldn't work in this model is
refunds, which probably can't be handled via
authentication/authorization messages. So I'd
recommend using a conventional accounting
message for those, indicating the desire for
real-time service so that the refund is
reflected in a timely way. Since a refund
only *extends* the time available, supporting
this via accounting messages wouldn't invalidate
the re-authorization based credit control approach.
Detailed review comments are available below:
http://www.drizzle.com/~aboba/AAA/draft-ietf-aaa-diameter-cc-00.txt
[Harri Hakala]
Hi,
In the issue 407, Credit Control Review, we were advised
to provide some message diagrams explaining the protocol
usage. In the current CCA draft (draft-ietf-aaa-diameter-cc-00)
we have described some message flows in Appendix A, Credit
Control sequences.
However, the example flows for the refund and price enquiry cases
were not included in the above version. To close this part of the
issue, we have prepared some additional message flows to clarify
these cases.
Flows are available here,
Price Enquiry:
http://standards.ericsson.net/harri/Price_enquiry.txt
Refund:
http://standards.ericsson.net/harri/Refund.txt
All comments and suggestions are most welcome.
Regards........Harri
Proposed Resolution: Accept
Issue 408: Another Diameter Credit Control Review
Submitter name: Avi Lior
Submitter email
address: avi@bridgewatersystems.com
Date first submitted: May 9, 2003
Reference:
http://www.drizzle.com/~aboba/AAA/lior-comments.txt
Document: CC-00
Comment type: Technical
Priority: S
Section: Various
Rationale/Explanation of issue:
General Comments
Use of Authentication\Authorization messages.
As mentioned before (in various emails) I belive that the correct way
(from a philosophical point and technical point) is to use
authentication and authorization messages. I belive you have received
comments to this effect from other people so I won't bother to repeat
myself or others.
Protocol Efficiency
In many domains where this application will be applicable, the user is
authenticated and authorized to use the service. Part of the
authorization service is to perform Credit or Prepaid authorization. The
problem with the current document is that it *forces* the Credit
Authorization or Prepaid Authorization to be performed after the Service
Authroization. This creates a problem: First, the credit authorization
has to traverse the network again. Since both authorization are done in
the Home network, it seems silly to have to traverse the network again.
Second and more importantly, the delay in having to perform this
operation as a seperate step is not acceptable in many application. This
*must* be addressed to have this document acceptable as a generic
solution. This is not a specific 3GPP solution right?
Types of Credit Control
It would be nice if several applicable scenario be presented. For
example, its not clear whether the intent of this application is to
cover Prepaid Data Services.
How are time and volume based applications handled?
What about roaming considerations?
Applicability in other than 3GPP operating environments
This document is intended as a Standard Track therefore, it should work
in general operating environments. That is, environments other than
3GPP. There are certain concepts here that work well in the 3GPP but not
so well in other environments. For example, the notion that a Credit
Control Client can request the user's account balance, or the cost of a
service is not appropriate in all conditions. This particular problem
was brought up in the past and sadly not addressed in this version. I
have no problem if the authors dont want to address these issues.
However, they should submit the document as an Informational Document,
documenting how 3GPP does things.
Redirect
In many instances in the text the action to take when a user resources
are no longer available is to terminate the session. That is one
possible action, the other possible action is to restrict access (or
direct the user) to a portal where they can recharge their account
etc...
Detailed review comments are available below:
http://www.drizzle.com/~aboba/AAA/lior-comments.txt
[Marco Stura]
I would like to give some background about the proposal:
http://www.drizzle.com/~aboba/AAA/diamcca-gst.rtf
In the issue 408 against the Diameter Credit Control Application, that was the
Avi Lior's review of the document, there is at least one comment that we didn't
address in the current IETF draft (draft-ietf-aaa-diameter-cc-00):
"Redirect
In many instances in the text the action to take when a user resources
are no longer available is to terminate the session. That is one
possible action, the other possible action is to restrict access (or
direct the user) to a portal where they can recharge their account
etc..."
We have been working on a solution to enable three different actions upon user's
resources are no longer available. The solution consists of an enhancement to
the current feature of gracefully disconnect the end user (i.e. the
Final-Unit-Indication AVP is used for that purpose)in order to enable:
TERMINATE, REDIRECT and RESTRICT_ACCESS.
I think this was also presented by John Loughney in the last IETF meeting in
Vienna.
The solution is called Graceful Service Termination, we have collected the
changes in the proposal that Bernard kindly made available to everybody to
facilitate the review. If there is no objections we would introduce this
solution in the version 01 of the draft.
Since in the solution the CC server may also use the server-initiated
re-authorization and in the Diameter base it is stated that authorization
applications MUST state whether server-initiated authorization is supported, we
also added a section "Server-Initiated Credit Re-Authorization".
Of course comments and suggestions are more than welcome.
Regards
Marco
Proposed Resolution: Accept
Issue 409: Accounting-EAP-Auth-Method and expanded
types
Submitter name: Pasi Eronen
Submitter email address: pasi.eronen@nokia.com
Date first submitted: 18 Jun 2003
Reference:
http://www.merit.edu/mail.archives/aaa-wg/msg04949.html
Document: EAP-01
Comment type: T
Priority: 1
Section: 4.1.2
Rationale/Explanation of issue:
Accounting-EAP-Auth-Method AVP is defined as Enumerated type.
This is OK for normal EAP types (0-253,255), but it's not
enough for Expanded types (see 2284bis, section 5.7).
Proposed change: Change AVP type to Integer64, with
Vendor-Type stored in least significant 32 bits, and
Vendor-Id in the next 24 bits.
Another possibility would be to simply ignore the
existence of Expanded types, and just use "254" for them.
Issue 410: How NAS sets Accounting-EAP-Auth-Method?
Submitter name: Pasi Eronen
Submitter email address: pasi.eronen@nokia.com
Date first submitted: 18 Jun 2003
Reference:
http://www.merit.edu/mail.archives/aaa-wg/msg04950.html
Document: EAP-01
Comment type: T
Priority: 1
Section: -
Rationale/Explanation of issue:
Currently a pass-through NAS inspects only the Code, Identifier,
and Length fields of EAP messages. If the NAS has to include
the EAP authentication method in accounting messages, it has to
also inspect the Type field. Also, since a typical EAP
conversation will include at least two different types (Identity
and something else), we need to specify how the value is chosen.
Proposed change: One possible solution would be that the
Accounting-EAP-Auth-Method AVP will be equal to the Type
(or Expanded Type) field in the last Diameter-EAP-Request's
EAP-Payload AVP. Or the Diameter server could give the value
to use in the last (success) Diameter-EAP-Answer. Any other ideas?
Issue 411: Maximum size of EAP messages
Submitter name: Pasi Eronen
Submitter email address: pasi.eronen@nokia.com
Date first submitted: 18 Jun 2003
Reference:
http://www.merit.edu/mail.archives/aaa-wg/msg04951.html
Document: EAP-01
Comment type: T
Priority: S
Section: -
Rationale/Explanation of issue:
The EAP server may need to know the maximum size of EAP payload
it can send, in order to produce fragments of correct size.
Proposed change: Add new EAP-MTU AVP, sent in
Diameter-EAP-Requests (I think we shouldn't re-use Framed-MTU
AVP for this; the "framed MTU" of the link isn't necessarily
the same as the maximum size of EAP message).
Issue 412: How to signal invalid packets?
Submitter name: Pasi Eronen
Submitter email address: pasi.eronen@nokia.com
Date first submitted: 18 Jun 2003
Reference:
http://www.merit.edu/mail.archives/aaa-wg/msg04952.html
Document: EAP-01
Comment type: T
Priority: S
Section: -
Rationale/Explanation of issue:
We need some way for the Diameter server to signal that "the EAP
packet was invalid, please send the next one", similar to
Error-Cause 202 "Invalid EAP Packet (Ignored)" in 2869bis.
Diameter-EAP-Answer with an empty EAP-Payload AVP could be one
choice. It would be sort of logical; Result-Code
DIAMETER_MULTI_ROUND_AUTH means "authentication continues", and
empty EAP-Payload would mean "I don't have anything new to
send". However, then RADIUS->Diameter translation agents must
keep a copy of the previous EAP Request...
Another possibility would be to add a new AVP, say,
EAP-Packet-Ignored (with empty data field).
Any comments or ideas on this one?
Issue 413: EAP-Payload AVP vs. EAP-Message
attribute?
Submitter name: Pasi Eronen
Submitter email address: pasi.eronen@nokia.com
Date first submitted: 18 Jun 2003
Reference:
http://www.merit.edu/mail.archives/aaa-wg/msg04953.html
Document: EAP-01
Comment type: T
Priority: 2
Section: 4.1.1
Rationale/Explanation of issue:
Is there some particular reason the Diameter AVP "EAP-Payload"
has a different name and code than the RADIUS "EAP-Message"
attribute? Or could we simply use the same name and code?
(And specify that when translating RADIUS->Diameter, multiple
attributes are concatenated to one AVP, and when doing
Diameter->RADIUS, long AVP values are split to multiple
attributes).
Recommended Resolution: Discuss
Issue 414: Key AVPs
Submitter name: Pasi Eronen
Submitter email address: pasi.eronen@nokia.com
Date first submitted: 19 Jun 2003
Reference:
http://www.merit.edu/mail.archives/aaa-wg/msg04961.html
Document: EAP-01
Comment type: T
Priority: 1
Section: various
Rationale/Explanation of issue:
What should the AVPs for transporting keys look like?
Here are some alternatives for starting a discussion:
Alternative 1:
EAP-Master-Session-Key (OctetString)
Pros/cons:
+ Simple
+ Does not try to solve all keying problems forever, but just
enough for EAP.
+ Consistent with 2284bis
+ The Diameter server doesn't have to know what the key is used for
- The Diamater server doesn't know what the key is used for
- New AVPs may be needed for more complex needs in the future
(but if we don't know them yet, we can define them
later).
Alternative 2:
From old NASREQ-09:
NAS-Session-Key ::= < AVP Header: 408 >
{ NAS-Key-Direction }
{ NAS-Key-Type }
{ NAS-Key-Data }
{ NAS-Key-Binding }
|
[ NAS-Key-Lifetime ]
[ NAS-IV ]
* [ AVP ]
NAS-Key-Direction: (BIDIRECTIONAL, UPLINK, DOWNLINK)
NAS-Key-Type: (CIPHER_KEY,
INTEGRITY_KEY, MASTER_CIPHER_KEY,
MASTER_INTEGRITY_KEY, MASTER_KEY)
NAS-Key-Binding: (DES, 3DES, RC4-40, RC4-128)
Pros/cons.
- The Key-Type/Binding is complex, but it still can't specify even
something simple like "use this key for 802.11i PMK" --
a
BIDIRECTIONAL,MASTER_KEY could be used for some other
purpose!
- Including a list of ciphers here is probably not a good idea.
Alternative 3:
EAP-Session-Key ::= < AVP Header: TBD >
{ EAP-Key-Type }
1* { EAP-Key-Data }
* [ AVP ]
EAP-Key-Type is of type Enumerated, with the following
values assigned:
IEEE_802_11I_PAIRWISE_MASTER_KEY (1)
A single EAP-Key-Data AVP contains the Pairwise
Master Key
to be used in 802.11i four-way handshake.
IEEE_802_11_WEP_KEY (2)
A single EAP-Key-Data AVP contains the 802.11 WEP
key
(TBD: is this correct?).
MS_MPPE_KEYS (3)
Two EAP-Key-Data AVPs included, first containing
the
downlink (send) key, and the second the uplink (recv)
key.
IKE_V2_AUTH_KEY (4)
A single EAP-Key-Data AVP contains the MSK for
IKEv2
authentication.
PANA_something (5)
To be defined when PANA progresses.
Pros/cons:
+ Simple binding, extensible
- ?
Alternative 4:
Like 3, but instead of creating a new Enumeration
namespace, just use the AVP namespace. That is,
create four new AVPs:
IEEE-802-11i-Pairwise-Master-Key
IEEE-802-11-WEP-Key
MS-MPPE-Keys
IKEv2-Auth-Key
Pros/cons:
+ Grouped AVPs can include other stuff, like encryption policies
for MPPE, or allowed cipher algorithms, etc.
+ Any new use for EAP will probably require a spec saying
how it is used with RADIUS/Diameter anyway (e.g. we
will soon
need a "IKEv2 RADIUS/Diameter Usage Guidelines"
document, similar
to the existing "IEEE 802.1X RADIUS Usage Guidelines")
+ New keying AVPs can be defined using the normal ABNF syntax.
+ New AVP required for new key uses -- it's a good thing if they
keys can't be used for other purposes too easily.
- New AVP required for new key uses.
[Pasi Eronen] The one major still open in Diameter EAP application is the
AVP(s) to be used for keys. There are several complications:
while some link layers (such as 802.11i) are happy with a single
key, some (e.g. MPPE) need two. Also, we would like to be
compatible with the de facto RADIUS practise (MS-MPPE-*
attributes), so translation should work "well enough" in
both directions.
The current sketch in -03 draft does not really support having
more than one separate key. I listed some possible alternatives
while working on -02 version:
http://www.drizzle.com/~aboba/AAA/issues5.html#Issue%20414
ÍMHO, alternative #3 seems the best of those, but it requires
that translation agents translating from RADIUS Access-Accept
to Diameter-EAP-Answer can figure out the correct key type...
I had a chat with Jari a while ago, and we came up with a simple
(if not very elegant) alternative... so, I'd like to ask your
comments about the following:
4.1.3 NAS-Session-Key AVP
The NAS-Session-Key AVP (AVP Code TBD) is of type OctetString.
It is used by the Diameter server to deliver keying material
to be used between the client and the NAS.
More than one NAS-Session-Key AVP MAY be sent, and their order is
significant. The interpretation depends on what security
mechanisms are going to be used between the client and the NAS:
o For IEEE 802.11i, only a single NAS-Session-Key AVP is
used:
it contains the Pairwise Master Key (PMK).
o For MPPE, two NAS-Session-Key AVPs are used: the first
contains
the uplink (Recv) key, and the second contains
the downlink
(Send) key.
6.1 RADIUS Request forwarded as Diameter Request
...
o Diameter NAS-Session-Key AVPs can be translated to the
vendor-specific RADIUS MS-MPPE-Recv-Key and MS-MPPE-Send-Key
attributes [RFC2548]. If more than one
NAS-Session-Key AVP is
present, the first is translated to MS-MPPE-Recv-Key
and the
second to MS-MPPE-Send-Key. The encryption of
this attribute is
described in [RFC2548].
6.2 Diameter Request forwarded as RADIUS Request
...
o If the vendor-specific RADIUS MS-MPPE-Recv-Key and/or
MS-MPPE-Send-Key attributes [RFC2548], they can
be translated to
Diameter NAS-Session-Key AVPs. If both attributes
are present,
MS-MPPE-Recv-Key corresponds to the first
NAS-Session-Key AVP
and MS-MPPE-Send-Key to the second. The attribute
has to be
decrypted before conversion, and only the Key
sub-field is
stored to the NAS-Session-Key AVP (i.e., Salt,
Key-Length and
Padding are discarded after translation).
Another possibility would be to use alternative #3, but add
an "UNDEFINED" EAP-Key-Type value; this could be used by
translation agents when they can't figure out the key type
(this would be somewhat similar to what is proposed above,
except that the individual AVPs would be inside one grouped
AVP instead of being at the "top level").
Comments welcome...
[Bernard Aboba] I think this proposal requires that the NAS send the
NAS-Port-Type AVP.
Otherwise, how will the AAA server know what which type of key to send?
Also, how does the AAA server know what ciphersuite is going to be
negotiated? Some ciphersuites might need both keys, some only one.
But
ciphersuite negotiation can occur *after* the keys are sent.
So I'm not clear how the AAA server can figure out which key(s) to send.
And if it guesses wrong, the session cannot go forward.
[Pasi Eronen]
Hmm, yes... if derivation of AAA-Key from MSK depends on the ciphersuite (or at least on link-layer type if not exact ciphersuite), then the AAA server has to know it. This is the case if e.g. AAA-Key has some internal structure with variable-length parts, like MPPE Send/Recv keys. So actually we have this problem already in RADIUS: the AAA server could send different key attributes depending on whether e.g. EAP-TLS is used for MPPE or 802.11i. It seems that current AAA servers don't care about this, and always send 64 bytes of keying material (?). 802.11i will use only half of that (first 32 bytes or Recv key), and if I understood RFC3079 right (?), MPPE will also use half, but it's bytes 0..15 and 32..47 (first 16 bytes of Recv/Send keys each). If we can assume that all AAA servers do this, then we could live with the single 64-byte AVP that draft -03 has. (When translating from RADIUS to Diameter, just concatenate the 32-byte Recv/Send keys, and split the key when translating back.) However, it seems that when using MPPE the AAA server could actually send only the first 16 bytes of MS-MPPE-Recv/Send keys; and then translation gets difficult... is this a concern, or could we assume that AAA-Key is always exactly 64 octets? (or does not have variable-length internal structure)
Recommended Resolution: Discuss
Issue 415: Review of Diameter Multimedia Application
Submitter name: Jayshree Bharatia
Submitter email address: jayshree@nortelnetworks.com
Date first submitted: 8 July 2003
Reference:
http://www.merit.edu/mail.archives/aaa-wg/msg04985.html
Document:
draft-belinchon-aaa-diameter-mm-app-01.txt
Comment type: T
Priority: S
Section: various
Rationale/Explanation of issue:
I have the following comments on draft-belinchon-aaa-diameter-mm-app-01.txt.
Global:
- Since the description in this draft is specific to
SIP, I like to suggest new title
for this draft as "Diameter for SIP Based
Multimedia Application".
- Another suggestion is to include new "User
De-registration" scenario as section
3.6 so that usages of commands RTR and RTA become
more clear.
Section:2 (Second paragraph)
- Reword the paragraph "However, this
document...between SIP and Diameter".
Something is missing from this paragraph.
Section 3 (Second paragraph)
- The draft says that Figure 1 provides general
overview of the integration of
the SIP architecture with the AAA architecture but
the next paragraph says
that it is related to specific SIP server
configuration. If UAR/UAA and
LIR/LIA are applicable to just edge routers, it
should be reflected in this
model clearly.
Section 3.1 and 3.2 (general)
- I don't see much difference between the scenarios
discussed in section
3.1-"Diameter server authenticate the user" and
section 3.2 -"SIP server
authenticate the user". There are just couple of
steps (13 and 14) which are
different from the description of these sections.
Since these scenarios
are discussed in different context, it's better to
show which commands are
used for what purpose and consolidate the
description.
Section 5.1
- In Open Issue Note, you have mentioned User-Name
AVP being the mandatory
parameter. I would think that UAR may be used for
other SIP Requests as well
(other than REGISTER). In those cases, do we have
private id available also?
Additionally, I would think that it will be
better to mention what value will
be assign to SIP-Public-User-Identity parameter in
case of non-3GPP usage.
- This section says that the Diameter server must
include either the address of
the SIP server or the capability needed by the
SIP server. Does it mean that
requesting SIP server always have capability to
derive next hope based on the
capabilities received from the AAA? Why do we have
this additional
requirement.
Recommended Resolution: Discuss
Issue 416: AVP type mismatches in NASREQ-12
Submitter name: Pasi Eronen
Submitter email address: pasi.eronen@nokia.com
Date first submitted: August 12, 2003
Reference:
http://www.merit.edu/mail.archives/aaa-wg/msg05028.html
Document: NASREQ-12
Comment type: T
Priority: 1
Section: various
Rationale/Explanation of issue:
When reviewing NASREQ-12, I found a couple of cases where the AVP
type specified doesn't match the description of the corresponding
RADIUS attribute in RFC 2865/2868/etc.:
These two are obviously editorial mistakes:
- Framed-IPX-Network should be Unsigned32 instead of UTF8String
(it's not UTF-8 or human-readable, and it's always 4 octets)
- Tunnel-Client-Auth-Id should be UTF8String instead of Unsigned32
(it's a string, and RFC2868 says it should be UTF-8)
These are not that important:
- Tunnel-Server-Auth-Id should be UTF8String instead of OctetString
(RFC2868 says that it should be UTF-8)
- Tunnel-Private-Group-Id should be OctetString instead of UTF8String
(RFC2868 says that it can be anything)
Best regards,
Pasi
Recommended Resolution: Discuss
Issue 417: Authentication Method AVP
Submitter name: Pasi Eronen
Submitter email address: pasi.eronen@nokia.com
Date first submitted: August 12, 2003
Reference:
http://www.merit.edu/mail.archives/aaa-wg/msg05029.html
Document: NASREQ-12, Diameter EAP
Comment type: T
Priority: 2
Section: -
Rationale/Explanation of issue:
Diameter EAP application has Accounting-EAP-Auth-Method AVP
that corresponds to the MS-Acct-EAP-Type RADIUS attribute
from RFC 2548. In RADIUS, this attribute is used together
with MS-Acct-Auth-Type attribute (which has values for PAP,
CHAP, EAP, MS-CHAP-1, etc.).
Should NASREQ have a corresponding AVP, named perhaps
Accounting-Auth-Method? (Note that this is different from
Acct-Authentic AVP, which has values for local, RADIUS and
Diameter)
I guess we could define this AVP in Diameter EAP document
if adding this to NASREQ this late would be a problem.
Best regards,
Pasi
[David Mitton]
Okay, can we elaborate more on the intended semantics?
Is this an informational readout for Accounting as to what auth method was
actually used?
Which end originates it? (if accounting only, then client to Acct server)
Which way does it flow?
Can we enumerate all the desired values?
How does this relate to the RADIUS attributes and MS VSAs at a protocol gateway?
We have a day to get this in.
Recommended Resolution: Discuss
Issue 418: Minor NASREQ-12 Editorial NITs
Submitter name: Pasi Eronen
Submitter email address: pasi.eronen@nokia.com
Date first submitted: August 12, 2003
Reference:
http://www.merit.edu/mail.archives/aaa-wg/msg05030.html
Document: NASREQ-12
Comment type: E
Priority: 1
Section: various
Rationale/Explanation of issue:
- The draft mentions the CMS Application in several places.
Since CMS is dead, should these be removed?
- Section 3.1: "The type of request is identified through the
Auth-Request-Type AVP, and the default mode is both
authentication and authorization."
The default mode would make more sense if Auth-Request-Type AVP
was optional to include. But since it's mandatory, maybe
this sentence would be clearer with the second part deleted?
- References:
- IPv6Addr has been obsoleted by RFC3513
- AAATrans, RADDynAuth, and RADIUSIANA have been published
as RFCs (3539, 3576, 3575)
- DiamEAP is now at version -02
- The following references are never cited in the document,
so they're probably unnecessary: NAI, ExtRADPract, CDM2000,
TCPCompress, L2F, ATMP, MSMPPE, UTF-8
- Typos:
- Section 4.6: s/the the/the/
- Section 4.6: ".sp"?
- Section 4.8: s/(AVP Code 94 is/(AVP Code 94) is/
- Section 6.11: s/proprietarySingleLink/proprietary SingleLink/
- Section 6.12: s/proprietary, SingleLink/proprietary SingleLink/
- Section 7.8: s/QOS/QoS/ (twice)
- Section 9.1: s/availible/available/
- Section 9.2: s/reponse/response/
- Section 10.1: extra " in last line of table
- The document has lots of extra spaces between words in
several places, but the RFC editor will probably
take care of them.
Best regards,
Pasi
Recommended Resolution: Discuss
Issue 419: Diameter Multimedia Review (part 1)
Submitter name: Avi Lior
Submitter email address: avi@bridgewatersystems.com
Date first submitted: July 31, 2003
Reference:
http://www.merit.edu/mail.archives/aaa-wg/msg05017.html
Document:
draft-belinchon-aaa-diameter-mm-app-01.txt
Comment type: T
Priority: S
Section: various
Rationale/Explanation of issue:
I did not read other peoples reviews. This way if there is duplication
you will get an amplication effect which could be useful. After my
review i will read the other ones.
However, I did read the first couple of reviews that talked about the name
change
and perhaps it would be a good idea to change the name to reflect the
"SIPness" of this draft.
Also I am not a SIP expert so you are getting the view of a non-sip
expert reviewer which is a good thing. But make sure you get a SIP type
person to review.
[AL] End of general comments
2. Introduction
This document specifies the Diameter Multimedia Application. This
is
a Diameter application that allows a Diameter client to request
authentication and authorization information to a Diameter server
for
Session Initiation Protocol (SIP) [6] based IP multimedia services.
We assume that the SIP server and the Diameter client are located
in
the same node, so that the SIP server is able to receive and
process
SIP requests and responses which in turn relies on the AAA
infrastructure for authenticating the SIP request and authorizing
the
usage of particular SIP services.
[AL] What is a node? The SIP server is acting as a Diameter Client.
Perhaps a better way to say this is: In this document we assume that
the SIP server is acting as a Diameter Client.....
This document provides Diameter procedures to implement certain
required functionality when SIP is the protocol chosen to initiate
and tear-down multimedia sessions. However, this document does not
mandate any particular mapping of SIP procedures to Diameter
Multimedia procedures, nor this document
[AL] mandate
any particular sequence of
events between SIP and Diameter. In some cases, though, this
document
provides with useful examples to show the interaction between SIP
and
Diameter Multimedia in order to achieve the desired functionality.
[AL] Delete " In some cases, though," and "with"
The Overview chapter (Section 3) provides the reader with
non-normative description of the Diameter multimedia commands and
responses and some guidance of its linkage with SIP procedures.
[AL] Can't you use Informative for non-normative?
.....
3. Overview of operation
This section provides an informative description of how the
Diameter
Multimedia application can be used together with SIP. By no means
this section mandates any specific usage of the Diameter Multimedia
application nor it mandates a specific mapping between SIP
and
Diameter messages. This section is just a collection of examples
that
shows how the required AAA functionality can be achieved in
conjunction with SIP.
[AL] Change: "application nor it mandates a " to: "application nor does
it mandates a " above.
According to Figure 2 a SIP User Agent Client (UAC) sends a SIP
REGISTER request (step 1) to its home domain. SIP server 1 will
receive the SIP request. We assume that this SIP server may be
located, e.g., at the edge of the administrative home domain. The
Diameter client in SIP server 1 will contact its Diameter server by
sending a Diameter User-Authorization-Request (UAR) message (step
2)
to determine if this user is allowed to receive service, and if so,
request the address of a local SIP server capable of handling this
user.
[AL] What do you mean by SIP server 1 will contact *its* Diameter
server. Couldn't it contact a Diameter server? There could be more then
one Diameter server no?
The Diameter server will answer with a Diameter
User-Authorization-Answer (UAA) message (step 3), which will
indicate
either a list of capabilities that the SIP server 1 may use to
select
an appropriate SIP server (SIP server 2) or a SIP or SIPS URI
pointing to SIP server 2.
SIP server 1 will forward the SIP REGISTER request (step 4) to an
appropriate SIP server (SIP server 2). The Diameter client in SIP
server 2 will then request user authentication from the Diameter
server by sending a Diameter Multimedia-Auth-Request (MAR) message
(step 5).
[AL] Must it be the same Diameter server? Couldnt it be a different one?
This request will also serve to make the Diameter server
aware of the SIP or SIPS URI of the SIP server 2, so as to return
subsequent requests of the same user to the same SIP server 2.
[AL] So what you are saying here is that you inform the Diameter server
of the SIP Server selected by SIP1.
[AL] What subsequent requests? Why wouldnt subsequent commands go
directly to SIP2?
[AL] Also if you have multiple Diameter servers one used by SIP1 the
other used by SIP2 will this work? It would only work if the state
(which SIP server) can be shared by both Diameter servers. Alternatively
it would work if Diameter serving SIP1 returns SIP2 again.
The Diameter server will respond with a Diameter
Multimedia-Auth-Answer
(MAA) message (step 6) with Result-Code AVP set to the value
DIAMETER_MULTI_ROUND_AUTH. The Diameter server will also include a
challenge, which the SIP server 2 will use to map into the
WWW-authentication header in the SIP 401 (Unauthorized) response
(step 7), which is sent back to the SIP server 1 and then to the
SIP
UAC (step 8).
[AL] Seems to me that if SIP1 kept state there would be fewer messages.
When the SIP server 1 receives a next SIP REGISTER request
containing
the user credentials (step 9), as there SIP server 1 does not need
to
keep a state (even there is not guarantee the SIP request to arrive
to the same SIP server 1), the Diameter client in SIP server 1 will
contact again the Diameter server by sending a Diameter UAR message
(step 10) to determine the SIP server allocated to the user. The
Diameter server will send the SIP or SIPS URI of SIP server 2 in a
Diameter UAA message (step 11).
[AL] The above par. in paritucal the first sentence needs to be cleaned
up. The first sentence is almost the entire paragraph ;-)
SIP server 1 will then forward the SIP REGISTER request to SIP
server
2 (step 12). SIP server 2 will extract the credentials from the SIP
REGISTER request. The Diameter client in SIP server 2 will send
those
credentials in a Diameter MAR message (step 13)to the Diameter
server. This message will also enable the Diameter server to
identify
Garcia-Martin, et al. Expires December 15, 2003
[Page 7]
Internet-Draft Diameter Multimedia application
June 2003
the URI of SIP server 2, so as to return subsequent requests to the
same SIP server 2. At this point, the Diameter server will be able
to
authenticate the user, and upon success, will return a Diameter MAA
message (step 14) with the AVP Result-Code set to the value
DIAMETER_SUCCESS. The Diameter MAA message will also include the
user
profile information, which the SIP server 2 will use to give
service
to the user.
[AL] I thought Diameter already remembered the URI of SIP server 2 in
the exchange that took place in Step 5?
SIP server 2 will then generate a SIP 200 (OK) response (step 15)
which is forwarded to SIP server 1 and eventually to the SIP UAC
(step 16).
[AL] How does Diameter Server know that the second UAR in (step 10) is
associated with the same session as the one in MAR/MAA in (step 6)?
What happens if the UAC is involved in multiple simultaneous operations
some of which would be routed to different SIP servers?
3.2 SIP server authenticates the user
[AL] Very little difference between this scenario and the one above. I
found it uncessary to re-read steps 1 to 12 again. Suggest that you
truncate this section and talk about the salient differences so we dont
have to re-read.
An operator with a large base of installed SIP servers may wish to
minimize the impact of modifying SIP servers to interact with
Diameter servers. This can be achieved by allowing SIP servers to
retain the functionality of authentication, rather than
centralizing
this capability in a Diameter server. However, it should be noted
that this mode will not leverage the extensive array of
authentication and authorization services which will already be
present regardless in Diameter servers.
[AL] I think you want to say an *existing* installed based. Because new
deployements would probably not have the SIP server do the
authentication for the reasons you mention.
.............
When the SIP server 1 receives a next SIP REGISTER request
containing
the user credentials (step 9), as the SIP server 1 does not need to
keep a state (even there is no guarantee that the SIP request
arrives
to the same SIP server 1), the Diameter client in SIP server 1 will
contact again the Diameter server by sending a Diameter UAR message
(step 10) to determine the SIP server allocated to the user. The
Diameter server will send the SIP or SIPS URI of SIP server 2 in a
Diameter UAA message (step 11).
[AL] Change "When the SIP server 1" to: "When SIP server 1" above.
SIP server 1 will then forward the SIP REGISTER request to SIP
server
2 (step 12). SIP server 2 will validate the credentials, and will
send a Diameter Server-Assignment-Request (SAR) message (step 13)
requesting the Diameter server to store the SIP or SIPS URI of the
SIP server that is currently serving the user. The Diameter SAR
message also serves the purpose to request the Diameter server to
send the user profile to the SIP server. The Diameter server will
respond with a Diameter Server-Assignment-Answer (SAA) message
(step
14). If the Result-Code AVP value does not inform about an error,
the
User-Data AVP will contain the information that SIP server 2 needs
in
order to provide a service to the user.
The SIP server 2 will generate then a SIP 200 (OK) response (step
15)
that will be forwarded to SIP server 1 and eventually to the SIP
UAC
(step 16).
[AL] Change "The SIP server 2 will generate then a" to "SIP server 2
generates a" above.
3.3 Session attempt
Figure 4 shows the scenario where the SIP server 1 receives a SIP
INVITE request (step 1). The SIP server 1 needs to find the address
of the SIP server 2, which is serving the addressed UA. Therefore,
the Diameter client in SIP server 1 sends Diameter
Location-Info-Request (LIR) message (step 2) to the Diameter
server.
The Diameter server responds with a Diameter Location-Info-Answer
(LIA) message (step 3) that contains the SIP or SIPS URI of the SIP
server 2. SIP server 1 then forwards the SIP INVITE to SIP server 2
(step 4). SIP server 2 will eventually forward the SIP INVITE to
the
appropriate UAS (step 5).
[AL] Change "where the SIP server 1 receives" to "where SIP server 1
receives" above.
[AL] Change "The SIP server 1 needs to" to "SIP Server
1 needs to"
+--------+
+--------+ +--------+
|
SIP |
|Diameter| | SIP
|
|server
1| | server |
|server 2|
+--------+
+--------+ +--------+
|
|
|
1. SIP INVITE |
|
|
Garcia-Martin, et al. Expires December 15, 2003
[Page 10]
Internet-Draft Diameter Multimedia application
June 2003
-------------->| 2. LIR
|
|
|------------------>|
|
| 3. LIA |
|
|<------------------|
|
| 4. SIP INVITE
|
|-------------------------------------->|
|
|
| 5. SIP INVITE
|
|
|-------------->
|
|
|
|
|
|
Figure 4
Although the example shows the connection between a SIP INVITE
request and the Diameter LIR message, any other SIP request (such
as
SUBSCRIBE, OPTIONS, etc.) would trigger the same Diameter message.
[AL] So from the above par. I get that a SIP REGISTER will generate a
Diameter LIR message. Is that true?
3.4 Update of the user profile
The Diameter Multimedia application provides a mechanism for a
Diameter server to asynchronously download a user profile to a SIP
server whenever there is an update of such user profile. It must be
noted that the Diameter server also attaches the user profile in
the
Diameter Server-Assignment-Request (SAR) message. Although this is
valid for most of the daily situations, it may happen that the
administrator decides to update or modify the user profile for a
particular user, due to, e.g., new services made available to the
user. This may involve a human intervention in the Diameter server
or
some mechanism outside the scope of this specification. In this
situation, the Diameter server is able to push the new user profile
into the SIP server allocated to the user.
[AL] Change "This may involve a human intervention in the Diameter
server or some mechanism outside the scope of this specification" to
"This may involve mechanisms outside the scope of this specification
such as human intervention in the Diameter server"
[AL] Change "The scenario is described in Figure 5" to "The scenario is
illustrated in Figure 5" below.
The scenario is described in Figure 5. In case the user profile
changes, the Diameter server will send a Diameter
Push-Profile-Request (PPR) message (step 1) to the Diameter client
in
the SIP server allocated to that user (SIP server 2 in the
examples).
The Diameter PPR message will contain a SIP-User-Data AVP, a
User-Name AVP and zero or more SIP-Public-User-Identity AVPs. The
presence of the User-Name AVP without any SIP-Public-User-Identity
AVPs serves to indicate that the entire user profile (included in
the
SIP-User-Data AVP) associated with the User-Name AVP is updated. A
Diameter PPR message with a User-Name AVP and one or more
SIP-Public-User-Identity AVPs serves to indicate that the user
profile data associated with each of the SIP-Public-User-Identity
AVPs is updated. The Diameter client in SIP server 2 will
acknowledge
the Diameter PPR message by sending a Diameter Push-Profile-Answer
(PPA) message (step 2) to the Diameter server.
.........
3.5 Registration termination
Termination of a user registration can be achieved by either of the
following three mechanisms:
[AL] I am having trouble with this because i dont know where or when
Auth-Session-State AVP is delivered.
In the event that NO_STATE_MAINTAINED (i.e., No Diameter user
session-id is maintained) has been indicated in a prior
Auth-Session-State AVP, termination is handled with a Diameter
Session-Termination-Request (STR) message (if it is initiated by
the
Diameter Client/SIP Proxy) or with a Diameter
Registration-Termination-Request (RTR) message (if it is initiated
by
the Diameter server).
On the other hand, if STATE_MAINTAINED has been indicated in a
prior
Auth-Session-State AVP, the use of Diameter
Session-Termination-Request (STR) and Abort-Session-Request (ASR)
messages as defined in the base Diameter specification [2] are used
to terminate a user registration.
Last, if the Diameter server receives a Diameter
Server-Assignment-Request (SAR) message that contains a
SIP-Server-Assignment-Type set to the value DE-REGISTRATION, the
Diameter server will proceed with the deregistration of the user.
[AL] Move the stuff below to the start of the section.
Reasons for terminating a user registration include:
o Expiration of the SIP registration timer in the SIP server.
o Administrative action taken at the Diameter server.
o The SIP UAC generates a SIP REGISTER request setting the
Expires
header field value to zero or the expires
parameter in the Contact
header field to zero (e.g., user initiated
deregistration).
4. Advertising Application Support
Diameter nodes conforming to this specification MAY advertise its
support by including the Auth-Application-Id AVP in the
Capabilities-Exchange-Request and Capabilities-Exchange-Answer
commands, according to the Diameter base protocol [2].
[Miguel Garcia]
|
[Avi Lior]
It seems to me that the major issue in my first review piece was the issue relating to deployment of Diameter servers. A single Diameter Server in your document is really a cluster of Diameter Servers sharing a common State Store. This is great. You should perhaps say that somewhere in your document and be done with this aspect of it. The issue still remains however. My gut feel says that having all your subscribers end up at a single cluster sharing the a common State Store is restrictive and will not scale. Think about a carrier with 30 million subscribers plus a bunch of visiting subscribers. Is it worthwhile to address how this will be done? I think yes not sure what others think. Others, what do you think? There are several ways to solve this problem. You can actually store the state in the messages (much the same way that RADIUS uses the State attribute etc). Not sure what is the best solution for this. Related to this I think is the notion of portability and mobility. I suspect that if one designs this for a 3GPP network one would get different constraints then if one were to consider a 3GPP2 network. I think you have to look at least to these two networks inorder to come up with a solution. There maybe other scenarios. More comments inline. > > However if have a short discussion in the past on whether > there is a requirement for a network to implement several > Diameter servers. Coming from a 3GPP view, the draft has been > assuming that, for a paricular user, all its data is stored > in a single Diameter server. One can have servers configured > in redundant fashion, clusters, or similar things (in order > to provide redundancy mainly). But all those servers will > contain the same data (will be mirrors), so from the > functional perspective, there will be only one Diameter > server in the network. > > Now, I would like to understand if this assumption is > correct, otherwise we will need to provide the appropriate > mechanisms in the draft to make it work in other environments. My opinion is yes. > In this case I believe it should be the same (or a cluster of > Diameter servers sharing the same data; I will refer to this > as one Diameter server). The issue is than in step 5 the > second SIP server will inform the Diameter server that such > second SIP server is serving the user. Consequently, further > Diameter requrests (such as UAR in step 10) or the LIR > command (step 2 in Figure 2) will return in the response > routing information, that is, the address of SIP server 2. > > This point is of vital importance for the whole system. If > there are several Diameter servers (with a discongruent view > of the data, such us serving SIP server or user profile), we > will not achieve the desired functionality. > > > > > > This request will also serve to make the Diameter server > > aware of the SIP or SIPS URI of the SIP server 2, so as to return > > subsequent requests of the same user to the same SIP server 2. > > > > [AL] So what you are saying here is that you inform the Diameter > > server of the SIP Server selected by SIP1. > > Correct. In doing so, the second SIP server "registers" > itself in the Diameter server. > > > > > [AL] What subsequent requests? Why wouldnt subsequent commands go > > directly to SIP2? > > I will explain this with the help of figure 4. Figure 4 is an > example of a user calling sip:miguel.a.garcia@ericsson.com. > The SIP INVITE will arrive to any of the multiple SIP server > 1. This is done by using the procedures in RFC 3263 (Locating > SIP servers). This RFC makes usage of DNS to find "entry > points" or "edge" SIP servers. > > So the INVITE in step 1 of Figure 4 will arrive to an edge > SIP server in ericsson.com. This SIP server does not know the > address of the SIP server that is triggering or providing > services to me, so SIP server 1 sends the LIR command to a > Diameter server in the ericsson.com real (step 2 in figure > 4). LIA will return the address of the SIP server allocated > to me, that may be something like sip:server33.ericsson.com > (in the example this will correspond to SIP server 2). > What I wanted to say is that my SIP URI will be in the format > of user@domain rather than user@host.domain, so in general > other SIP requests will ***not*** be addressed to > sip:miguel.a.garcia@server33.ericsson.com but to > sip:miguel.a.garcia@ericsson.com instead. So those subsequent > requests need the routing information from the Diameter server, in > order for the SIP request to reach the appropriate SIP server. Okay. I understand. But doesn't the scale of this worry you? 30 million subscriber's state being maintained in real-time. Is there a way to make this more manageable. Is it an issue?
[Miguel Garcia]
Thanks for the comments. Answers inline... /Miguel Avi Lior wrote:
It seems to me that the major issue in my first review piece was the issue relating to deployment of Diameter servers. A single Diameter Server in your document is really a cluster of Diameter Servers sharing a common State Store. This is great. You should perhaps say that somewhere in your document and be done with this aspect of it.
I think this is a fair proposal. I will add some discussion aligned to this
conclusion. At this stage, I don't think we need an Applicability Statement
section, but I would like to receive guidelines from the charis or the ADs.
The issue still remains however. My gut feel says that having all your subscribers end up at a single cluster sharing the a common State Store is restrictive and will not scale. Think about a carrier with 30 million subscribers plus a bunch of visiting subscribers. Is it worthwhile to address how this will be done? I think yes not sure what others think. Others, what do you think?
Not being "others", but... I agree that the solution will not scale as it is
now. What I can do is to document the solution that 3GPP developped to solve
this problem. 3GPP has added a new entity to its architecture, a Diameter
Redirect Agent (in 3GPP parliance, this is known as the Subscription Locator
Function, SLF).
To make a long story short: SIP servers query the SLF. The SLF, operating in
redirect mode returns the address of the Diameter server where the relevant
information for a particular user is stored. Needless to say, the SLF contains
(or is able to access) a simple database that binds users with the Diameter
Server that stores the data for that user.
Probably there might be other solutions to this problem, and we could document
them if it is required.
There are several ways to solve this problem. You can actually store the state in the messages (much the same way that RADIUS uses the State attribute etc). Not sure what is the best solution for this.
Due to the multiplicity of SIP servers in the network, I don't know how
storing a state in the message will help to solve the problem. The problem to
solve is: given the identity of a particular user, any Diameter Client (SIP
server) has to be able to find the Diameter Server that is storing the data for
that particular user.
Related to this I think is the notion of portability and mobility. I suspect that if one designs this for a 3GPP network one would get different constraints then if one were to consider a 3GPP2 network. I think you have to look at least to these two networks inorder to come up with a solution. There maybe other scenarios.
At least I am aware of the 3GPP solution, and it seems to work. And as I said
before, I would happy to document other solutions as well.
Regards,
Miguel
Recommended Resolution: Discuss
Issue 420: Issues with Diameter Multimedia
Application
Submitter name: Dan Warren
Submitter email address: dlwarren@nortelnetworks.com
Date first submitted: 8 July 2003
Reference:
http://www.merit.edu/mail.archives/aaa-wg/msg04990.html
Document:
draft-belinchon-aaa-diameter-mm-app-01.txt
Comment type: T
Priority: S
Section: various
Rationale/Explanation of issue:
Another comment (or maybe it's a question). In section 3.3, there is text that says...
'Although the example shows the connection between a SIP INVITE request and the Diameter LIR message, any other SIP request (such as SUBSCRIBE, OPTIONS, etc.) would trigger the same Diameter message.'
Could a REGISTER request trigger an LIR, and if so, in what situation? How does SIP server 1 determine if a REGISTER triggers an LIR or a UAR? My suspicion is that the text should read '... any other SIP request with the exception of a REGISTER request (such as SUBSCRIBE, OPTIONS, etc.) would trigger the same Diameter message', and that a REGISTER would always trigger a UAR to be sent. But I am prepared to be told I am wrong.
I also have a whole host of minor editorial comments that I will forward on to Miguel-Angel and Maria-Carmen Belinchon away from the e-mail list.
[Miguel Garcia]
Hi Dan:
You are opening the floor for an interesting discussion. I had the same sort of
concerns about the similarities between UAR and LIR.
The fact that UAR is triggered from a SIP REGISTER and LIR is triggered from any
other SIP request is not enough to justify two different commands.
I would then ask you what is the reason to have two different commands. Why is
not possible to have a single command? Do you know the answer?
/Miguel
If User-Name AVP is made optional, what is the impact of the text in 5.2 that reads...
'At reception of the Diameter UAR message, the Diameter server
MUST
verify the existence of the user in the realm, i.e., the
User-Name
AVP value is a valid user within that realm. If the Diameter
server
does not recognize the user name received in the User-Name AVP,
the
Diameter server MUST build a Diameter
User-Authorization-Answer (UAA)
message and MUST set the Result-Code AVP to
DIAMETER_ERROR_USER_UNKNOWN.
Then Diameter server MUST authorize that User-Name AVP
value is able
to register the SIP or SIPS URI included in the
SIP-Public-User-Identity AVP. If this authorization fails, the
Diameter server must set the Result-Code AVP to
DIAMETER_ERROR_IDENTITIES_DONT_MATCH and send it in a Diameter
User-Authorization-Answer (UAA) message.'
If the User-Name AVP is made optional, is this behaviour still valid? Making User-Name AVP optional would seem to me to imply that any time it is missing, UAA has to report an error. Either it has to be mandatory or this behaviour needs to change too.
[Miguel Garcia]
Of course that text will have be revisited if User-Name AVP is optional. But
the fact is that, no matter what we write in the document, User-Name is optional
except in 3GPP networks. 3GPP has optimized the flow to avoid two roundtrips,
and therefore, User-Name comes in the first roundtrip. But this is not always
the behaviour in an internet client.
So the reason whey I noted down an Open Issue was to synchronize the behaviour
when User-Name is available and when not. This will require to rewrite
substantial parts of the document that assume User-Name is always available.
/Miguel
Recommended Resolution: Discuss
Issue 421: Diameter Multimedia Review (Part 2)
Submitter name: Avi Lior
Submitter email address: avi@bridgewatersystems.com
Date first submitted: July 31, 2003
Reference:
http://www.merit.edu/mail.archives/aaa-wg/msg05019.html
Document:
draft-belinchon-aaa-diameter-mm-app-01.txt
Comment type: T
Priority: S
Section: various
Rationale/Explanation of issue:
This is my second installment of comments:
A general comment is the issue of user-name. As indicated in the following
comments the text is based on the fact that username is know but as you
point out it is sometimes not known. You need to address this issue for this
to be a general SIP solution.
5.1 User-Authorization-Request (UAR) Command
...................
The user name used for authentication of the user is conveyed in a
User-Name AVP (imported from the Diameter baseprotocol [2]). The
location of the authentication user name in the SIP REGISTER
request
varies depending on the authentication mechanism. When the
authentication mechanism is HTTP Digest as defined in RFC 2617 [4],
the authentication user name is found in the "username" directive
of
the SIP Authorization header field value.
[AL] Sounds like there are other cases -- that is not a HTTP Digest.
What are they or are you just giving an example?
The SIP or SIPS URI to be registered is conveyed in the
SIP-Public-User-Identity AVP (Section 7.8). Typically this SIP or
SIPS URI is found in the To header field value of the SIP REGISTER
request that triggered the Diameter UAR message.
The SIP-Visited-Network-Identifier AVP indicates the network that
is
providing SIP services (e.g., SIP proxy functionality or any other
kind of services) to the SIP User Agent.
Message Format
<UAR> ::= < Diameter Header: aaa, REQ, PXY
>
< Session-ID >
< Auth-Application-Id >
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
[ Destination-Host ]
{ Destination-Realm }
{ User-Name }
{ SIP-Public-User-Identity }
[ SIP-Visited-Network-Identifier ]
[ SIP-User-Authorization-Type ]
* [ AVP ]
* [ Proxy-Info ]
* [ Route-Record ]
[AL] I think you have an error with the Destination-Host the bracket
should either be '{' or it should be moved down the list.
OPEN ISSUE: according to the above description,
the User-Name AVP
is mandatory in the UAR message. This AVP is
always available in a
3GPP environment, because 3GPP has mandated the
private user
identity to be present in every REGISTER request.
However, in a
general SIP environment, a SIP client will not
insert any identity
without being challenged. Therefore, the
User-Name AVP may not be
present. Action: investigate if this AVP can be
set to optional.
[AL] I think this is a serious issue for this document since it seems to
me that you depend very heavily on the existance of the User-Name
attribute. To be a general solution which you would have to be in the
AAA-WG, I would think you would have to allow for this to be optional. I
dont see any other way.
5.2 User-Authorization-Answer (UAA) Command
...................
When the authorization procedure succeeds, the Diameter server
constructs a User-Authorization-Answer (UAA) message that MUST
include either the address of the SIP server already assigned to
the
user or the capabilities needed by the SIP server (Diameter client)
to select another SIP server for the user. This section will be
based
on the required capabilities of the SIP server to trigger and
execute
services for the user. The former option is used when the Diameter
server is aware of an allocated SIP server to the user, whereas the
latter is used when the Diameter server is not aware of an
allocated
SIP server, letting the SIP server to choose, if needed, an
appropriate SIP server according to the required capabilities.
[AL] The wording of the above par. is awakward. What do you mean by
"This section will be based on the required capabilities...."?
At reception of the Diameter UAR message, the Diameter server MUST
verify the existence of the user in the realm, i.e., the User-Name
AVP value is a valid user within that realm. If the Diameter server
does not recognize the user name received in the User-Name AVP, the
Diameter server MUST build a Diameter User-Authorization-Answer (UAA)
message and MUST set the Result-Code AVP to
DIAMETER_ERROR_USER_UNKNOWN.
[AL] Change "MUST build a" to "MUST reply with a"
[AL] Is the above paragraph true? Is the user-name the only thing that
can be used to allow the process to continue? This is not really where
the authentication happens right? So other attributes could be used to
verify whether the process should go on? Especially since the username
could be optional.
Then Diameter server MUST authorize that User-Name AVP value is
able
to register the SIP or SIPS URI included in the
SIP-Public-User-Identity AVP. If this authorization fails, the
Diameter server must set the Result-Code AVP to
DIAMETER_ERROR_IDENTITIES_DONT_MATCH and send it in a Diameter
User-Authorization-Answer (UAA) message.
[AL] Change "Then Diameter server" to "Next, the Diameter server"
[AL] Again here you are talking about a specific 3GPP behavior no?
user-name can be optional right?
If there is a SIP-Visited-Network-Identifier AVP in the Diameter
UAR
message, and the SIP-User-Authorization-Type AVP value received in
the Diameter UAR message is set to REGISTRATION or
REGISTRATION&CAPABILITIES then the Diameter server SHOULD verify
whether the user is allowed to roam into the network specified in
the
SIP-Visited-Network-Identifier AVP in the Diameter UAR message. If
the user is not allowed to roam into such network, the Diameter AAA
server MUST set the Result-Code AVP value in the Diameter UAA
message
to DIAMETER_ERROR_ROAMING_NOT_ALLOWED.
[AL] Can't i make the decision whether the user is allowed to roam based
only on the SIP-Visited-Network-Identifier? If i dont have a roaming
agreement with the network why should i bother looking up a user? Its
probably faster to do that. SImilar to RADIUS Call Check functionality.
.......................
In case that the SIP-User-Authorization-Type AVP value received in
the Diameter UAR message is set to REGISTRATION then:
o If the Diameter server is not aware of any previous
registration
of the user name (including registrations of
other public user
identities allocated to the same user name), then
the Diameter
server does not know of any SIP server allocated
to the user. In
this case the Diameter server MUST set the
Result-Code AVP value
to DIAMETER_FIRST_REGISTRATION in the Diameter
UAA message, and
the Diameter server SHOULD include the required
SIP server
capabilities in the SIP-Server-Capabilities AVP
value in the
Diameter UAA message. The SIP-Server-Capabilities
AVP will assist
the Diameter client (SIP server) to select an
appropriate SIP
server for the user, according to the required
capabilities.
[AL] what if the diameter server just wants to assign a specific SIP
server could it not set the SIP-Server-Name AVP?
[AL] There seems to be some wording problem between the above and below
par. Above you seem to say that the Diameter Server does not know of any
SIP server allocated to the user If the Diameter server is not aware of
any previous registration of the user name. Yet in the paragraph below
you say that in some cases, the Diameter server is aware of a previously
assigned SIP server
o In some cases, the Diameter server is aware of a previously
assigned SIP server for the same or different
public user identity
allocated to the same user name. In these cases,
re-assignment of
a new SIP server may or may not be needed,
depending on the
capabilities of the SIP server. The Diameter
server MUST always
include the allocated SIP server URI in the
SIP-Server-Name AVP of
the UAA message. If the Diameter server does not
return the SIP
capabilities, the Diameter server MUST set the
Result-Code AVP in
the Diameter UAA message to
DIAMETER_SUBSEQUENT_REGISTRATION.
Otherwise, if the Diameter server includes a
SIP-Server-Capabilities AVP then the Diameter
server MUST set the
Result-Code AVP in the Diameter UAA message to
DIAMETER_SERVER_SELECTION. The Diameter client
will then
determine, based on the received information,
whether it needs to
select a new SIP server or not.
In case that the SIP-User-Authorization-Type AVP value received in
the Diameter UAR message is set to REGISTRATION&CAPABILITIES then
Diameter Server MUST return the list of capabilities in the
SIP-Server-Capabilities AVP value of the Diameter UAA message, it
MUST set the Result-Code to DIAMETER_SUCCESS and it MUST NOT return
a
SIP-Server-Name AVP. The SIP-Server-Capabilities AVP enables the
SIP
server (Diameter Client) to select another appropriate SIP server
for
invoking and executing services for the user, depending on the
required capabilities. The Diameter server MAY leave the list of
capabilities empty to indicate that any SIP proxy can be selected.
[AL] What if the Diameter server does not want to allow the Client to
change? What would the response be?
............
End of section 5.2
|
Recommended Resolution: Discuss
Issue 422: Review Comments on Diameter Multimedia
Application
Submitter name: Kuntal Chowdhury
Submitter email address: :kuntal@iqmail.net
Date first submitted: July 14, 2003
Reference:
http://www.merit.edu/mail.archives/aaa-wg/msg05009.html
Document:
draft-belinchon-aaa-diameter-mm-app-01.txt
Comment type: T
Priority: S
Section: various
Rationale/Explanation of issue:
Section 2.
We assume that the SIP server and the Diameter client are located in
the same node, so that the SIP server is able to receive and process
SIP requests and responses which in turn relies on the AAA
infrastructure for authenticating the SIP request and authorizing the
usage of particular SIP services.
Comment: I think the better way to say will be -
It is assumed that the SIP server supports a Diameter interface...
Section 3.1:
SIP server 1 will forward the SIP REGISTER request (step 4) to an
appropriate SIP server (SIP server 2). The Diameter client in SIP
server 2 will then request user authentication from the Diameter
server by sending a Diameter Multimedia-Auth-Request (MAR) message
(step 5).
Comment: The apparent assumption in this document that the SIP server 2 will
talk to the same AAA server. What if it is not talking to the same AAA server?
What identifies the AAA server to SIP server 2 that has related information
from SIP server 1?
Section 3.1:
This request will also serve to make the Diameter server
aware of the SIP or SIPS URI of the SIP server 2, so as to return
subsequent requests of the same user to the same SIP server 2.
Comment: the text above is not clear. the SIP server 2 can be identified
by which entity (AAA or the SIP server 1?)?
Suggestion:
This request will also serve to make the Diameter server aware of the SIP or
SIPS URI of the SIP server 2. The AAA server shall store this information so
that it can return the same to the SIP server 1 during subsequent
re-registration by the same user.
Section 3.1:
When the SIP server 1 receives a next SIP REGISTER request containing
the user credentials (step 9), as there SIP server 1 does not need to
keep a state (even there is not guarantee the SIP request to arrive
to the same SIP server 1), the Diameter client in SIP server 1 will
contact again the Diameter server by sending a Diameter UAR message
(step 10) to determine the SIP server allocated to the user. The
Diameter server will send the SIP or SIPS URI of SIP server 2 in a
Diameter UAA message (step 11).
Comment: the paragraph needs some editorial scrub as suggested below. Also I
think we need to mention how the same AAA server is selected (when multiple AAA
servers are in the network).
Suggestion:
When the SIP server 1 receives a next SIP REGISTER request containing the
user's credentials (step 9), as the SIP server 1 is stateless (even there is
no guarantee that the SIP request arrives at the same SIP server 1), the
Diameter client in SIP server 1 will contact the Diameter server again by
sending a Diameter UAR message (step 10) to determine the SIP server 2
allocated to the user. The Diameter server will send the SIP or SIPS URI of
SIP server 2 in a Diameter UAA message (step 11).
Section 3.2 SIP server authenticates the user:
This should not be included in the draft. Local authentication/authorization
is certainly out of scope in AAA WG, IMHO. The draft also uses AAA server to
perform SIP server assignment, store non-AAA specific info such as location of
the SIP servers etc. These facts needs to discussed in the AAA WG.
Section 3.2:
Figure 3 shows an example where a SIP server is dynamically allocated
to serve a SIP User Agent with the support of the Diameter server.
This may be the case of certain architectures, such as the 3rd
Generation Partnership Project (3GPP) IP Core Network Multimedia
Subsystem (IMS).
Comment: the SIP server 2 is dynamically allocated in section 3.1 as well.
Nevertheless user authentication/authorization solely by the SIP server is
possible w/o AAA server's involvement (in this scheme) and dynamic SIP server
assignment is not the main topic of the discussion. Therefore I suggest deleting
this text.
Section 3.4:
It must be
noted that the Diameter server also attaches the user profile in the
Diameter Server-Assignment-Request (SAR) message
Comment: I think Diameter server needs to attach the user profile in the MAA
message as well.
Section 3.5:
Last, if the Diameter server receives a Diameter
Server-Assignment-Request (SAR) message that contains a
SIP-Server-Assignment-Type set to the value DE-REGISTRATION, the
Diameter server will proceed with the deregistration of the user.
Comment: What is the criteria for the Diameter client (SIP server 2 in this
case) to use SAR instead of STR?
Section 5.2:
Then Diameter server MUST authorize that User-Name AVP value is able
to register the SIP or SIPS URI included in the
SIP-Public-User-Identity AVP.
Comment: need a little editorial scrub:
Then Diameter server MUST authorize the user as identified in the User-Name
AVP value so that the user is able to register the SIP or SIPS URI included in
the SIP-Public-User-Identity AVP.
Section 5.2:
o In some cases, the Diameter server is aware of a previously
assigned SIP server for the same or different public user identity
allocated to the same user name.
Comment: it is not clear why user name AVP will map into more than one
different public user identities? More specifically why do we need to include
the user name AVP at all when public user identity is present?
Section 5.3:
Typically the reception of a SIP REGISTER request in a SIP server
will trigger the Diameter client in the SIP server to send the
Diameter SAR message. However, if a SIP server is receiving other SIP
request, such as INVITE, and the SIP server does not have the user
profile, the Diameter client in the SIP server may send the Diameter
SAR message to the Diameter server in order to download the user
profile and make the Diameter server aware of the SIP server assigned
to the user.
Comment: When the user is not registered and the SIP server receives an INVITE
for/from the user, then by directly sending a SAR the SIP server is bypassing
auth/authz. This scenario (auth/authz bypass) may not be allowed in all
networks. Moreover, receiving a REGISTER for a user that has no context in
the SIP server should generate MAR message not SAR.
Section 5.6:
[ Auth-Grace-Period ]
[ Authorization-Lifetime ]
Comment: Since SIP server 1 is stateless, therefore what is the purpose of these
two AVPs in the LIA message?
Section 5.12:
OPEN ISSUE: How to avoid that the same SIP server is chosen again,
and we enter a loop.
Comment: Ideally, the Diameter server flags the SIP server to be "busy" or a
similar tag, so that while returning a UAA next time it does not include this
server for a new user.
Section 6.1.1:
o DIAMETER_SERVER_SELECTION 2xx5
The Diameter server has authorized the registration. The user has
already a SIP server assigned, but it may be necessary to select a
new SIP server for the user.
Comment: Not sure how often this will happen, but the appropriate value name
should be DIAMETER_SERVER_RESELECTION
Section 7.1:
SIP-Charging-Information :: = < AVP Header: TBD >
[ Primary-Event-Charging-Function-Name ]
[ Secondary-Event-Charging-Function-Name ]
[ Primary-Charging-Collection-Function-Name ]
[ Secondary-Charging-Collection-Function-Name ]
* [ AVP]
Comment: There should be a sentence that says that these functions can all have
the same value. These things may very well be part of the Diameter server (AAA
server) and charging and accounting is part of AAA.
Section 7.4:
o UNREGISTERED_USER (3)
The SIP server has received a SIP request (e.g., SIP INVITE)
addressed for a public user identity that is not registered.
Comment: Why doesn't the SIP server send a MAR in this case?
Section 7.4:
o AUTHENTICATION_FAILURE (9)
The authentication of a user has failed.
Comment: Why would the SIP sever send a SAR with Auth failure code? Ideally
the Authentication needs to be done in the Diameter server.
Recommended Resolution: Discuss
Issue 423: Authorization-Lifetime/Session-Timeout
Confusion
Submitter name: Pasi Eronen
Submitter email address: :pasi.eronen@nokial.com
Date first submitted: August 15, 2003
Reference:
http://www.merit.edu/mail.archives/aaa-wg/msg05043.html
Document: NASREQ-12
Comment type: T
Priority: 1
Section: various
Rationale/Explanation of issue:
There seems to be some confusion about Authorization-Lifetime
and Session-Timeout AVPs between Base and NASREQ.
More specifically, the state machine in Base (Section 8.1)
specifies that when Session-Timeout expires, the access
device MUST send a STR and move to state Discon.
This is inconsistent with with NASREQ description for
Termination-Action AVP, which allows other behavior as well.
Proposed change:
Remove the Termination-Action AVP completely.
When translating a RADIUS Access-Accept to Diameter AA-Answer,
do the following:
- If the RADIUS message contains a Session-Timeout attribute
and a Termination-Action attribute set to DEFAULT (or no
Termination-Action attribute at all), translate it
to AA-Answer with a Session-Timeout AVP (and remove
the Termination-Action attribute).
- If the RADIUS message contains a Session-Timeout attribute
and a Termination-Action attribute set to AA-REQUEST,
translate it to AA-Answer with Authorization-Lifetime AVP
and Re-Auth-Request-Type set to AUTHORIZE_AUTHENTICATE
(and remove the Session-Timeout attribute).
When translating a Diameter AA-Answer (with successful result
code) to RADIUS Access-Accept,
- If the Diameter message contains a Session-Timeout AVP but no
Authorization-Lifetime AVP, translate it to Session-Timeout
attribute (and no Termination-Action).
- If the Diameter message contains a Authorization-Lifetime AVP but
no Session-Timeout AVP, translate it to Session-Timeout attribute
and Termination-Action set to AA-REQUEST. (And remove
Authorization-Lifetime and Re-Auth-Request-Type)
- If the Diameter message has both, the Session-Timeout is always
greater or equal than Authorization-Lifetime (required by Base).
I guess the safest bet is to translate it to Session-Timeout
value (with value from Authorization-Lifetime AVP, the smaller one)
and Termination-Action set to AA-REQUEST. (And remove
Authorization-Lifetime and Re-Auth-Request-Type)
Best regards,
Pasi
[David Mitton]
I like this suggestion.
Bernard had complained about a similar issue in #404 wrt to 802.1x, but I had
problems working out all the details.
If there are no further comments, I'll incorporate this approach in NASREQ
making sure it works with IEEE 802.1x or 802.1aa or whatever it is this week.
Recommended Resolution: Accept
Issue 424: Route-Record AVP in Responses
Submitter name: Pasi Eronen
Submitter email address: pasi.eronen@nokia.com
Date first submitted: September 1, 2003
Reference:
http://www.merit.edu/mail.archives/aaa-wg/msg05062.html
Document: base and nasreq
Comment type: T/E
Priority: 1
Section: various
Rationale/Explanation of issue:
Oops, I know it's kinda late to notice this... but there
seems to be some inconsistencies about the Route-Record AVP
in some of the following: Base, NASREQ, my head.
Route-Record AVP use in requests seems to be ok, but
it is not clear if responses should have Route-Record AVPs.
- The AVP occurrence tables (in both Base and NASREQ) show
that Accounting-Answers MAY have Route-Record AVPs, but
all other responses MUST NOT have them.
- There's no text saying when or if agents or servers
should add Route-Record AVP(s) to responses.
- Base (Section 2.10) says that "...the local Diameter agent,
on receiving a Diameter response authorizing a session,
MUST check the Route-Record AVPs...".
- NASREQ (Section 9.2) says that RADIUS translation should
add Route-Record AVPs to AA-Answers. (Route-Record is
mentioned several times in Section 9, but all the other
cases apply only to requests, so they're probably ok).
Proposed change:
I'm not totally sure what the correct change would be
(that is, should answers have Route-Record AVPs or not).
They were removed in issue 228, but the text about path
authorization (added in issue 390) clearly assumes we
have them.
[Bernard Aboba] After looking at this, my conclusion is that Record-Route AVPs
can be
included either in requests or responses and that the lack of occurrence
in the AVP tables in Diameter Base was a typo. I think this because the
text in Base 2.10 seems to assume that Record-Route AVPs are in responses,
and because they are allowed in Accounting-Responses.
Based on this, it would appear that the issue is an inconsistency in
Diameter Base, and that the NASREQ text assume Record-Route in responses
is correct.
Anyone else have an opinion in this?
[John Loughney] I concur. The text about the Record-Route AVPs was written
before my
time (I think); I assume it was meant that these AVPs are assumed
to be in responses.
[Pasi Eronen]
Yes, I guess we could allow Route-Record AVPs in responses well.
However, we still need to clarify how they get there... what
would be the best way to get this specified? Having NASREQ
update RFC3588? A new RFC that updates RFC3588
BTW, the current text in NASREQ isn't consistent with what IMHO
would be the most logical way to add the Route-Records (proxies
add them to responses one by one). But there isn't any clearly
specified alternative it would be consistent with either..
[Bernard Aboba] We could submit an errata for RFC 3588, since it is RFC 3588
that is
internally inconsistent. Then we could clarify how they get there in
NASREQ.
[Pasi Eronen] Here are the proposed fixes:
Errata for RFC3588:
o Section 6.2.2: add the following text after the first paragraph:
"A proxy or relay agent MUST append a Route-Record AVP to all
responses forwarded. The AVP contains the identity of the peer
the response was received from."
o Section 10.1: Update the AVP occurrence table to specify that
RAA/ASA/STA messages can have zero or more Route-Record AVPs.
Updates for NASREQ -13b:
o Section 9.2: Remove the following list item:
"4. Route-Record AVPs (in the proper order)"
o Section 9.2: Remove the following bullet:
"The Route-Record AVPs MUST be added to the Diameter message, in
the same order they were present in the request. The gateway's
position in the forwarding should be properly recorded."
o Section 9.2: Replace the bullet
"The response's Origin-Host information is created from the
FQDN of the source IP address of the RADIUS message."
with
"The response's Origin-Host information is created from the FQDN
of the source IP address of the RADIUS message. The same FQDN
is also stored to a Route-Record AVP."
o Section 10.1: Update AVP occurrence table to specify that
AAA message can have zero or more Route-Record AVPs.
A couple of related editorials/typos:
o Section 9.3.3: Replace
"...lookup on the source address and NAS-IP-Address
attributes..."
with
"...lookup on the source address and NAS-IPv6-Address attribute..."
o Section 9.3.3: Add to end of last paragraph
"...other action is taken."
(seems this was chopped off at some point)
(BTW, while figuring out these changes, I found a couple
of other inconsistencies in the RADIUS-Diameter translation.
I'll post these in a separate message.)
Proposed Resolution: Discuss
Issue 425: Misspelled AVP in NASREQ
Submitter name: Pasi Eronen
Submitter email address: pasi.eronen@nokia.com
Date first submitted: September 1, 2003
Reference:
http://www.merit.edu/mail.archives/aaa-wg/msg05063.html
Document: nasreq
Comment type: E
Priority: 2
Section: 9.3
Rationale/Explanation of issue:
I also noticed that "Route-Record" is misspelled as "Record-Route"
several times in NASREQ. All of the cases apply only to requests,
so this is purely editorial (and independent of the other
issue related to this AVP).
Proposed change: search and replace.
[David Mitton] I will fix that. Thanks.
Proposed Resolution: Accept
Issue 426: Diameter/DynAuth RADIUS translation
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: September 1, 2003
Reference:
http://www.merit.edu/mail.archives/aaa-wg/msg05067.html
Document: nasreq-12
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:
Update the references:
[RADDynAuth] M. Chiba, M Dommety, M. Eklund, D. Mitton, B. Aboba,
"Dynamic Authorization Extensions to Remote
Authentication Dial In User Service (RADIUS)",
RFC 3576, August 2003.
[RADIUSIANA] B. Aboba, "IANA Considerations for RADIUS", RFC 3575,
August 2003.
[RAD802.1X] P. Congdon, et.al "IEEE 802.1X RADIUS Usage Guidelines",
RFC 3580, September 2003.
Update Section 6.1 to include the new Service-Type value:
17 Authorize Only [RFC3576]
Delete the following text from Section 9.1:
" If the Diameter translation system receives a message as specified
in
[RADDynAuth], it may translate it into a Diameter Re-Auth-Request
message. The consistency and security rules of that
specification
MUST be applied to the processing and forwarding of this type of
message."
Add the following to Section 9.1:
As described in Section 3.2 of [RADDynAuth], a Service-Type of "Authorize
Only" is used in a Disconnect-Request or CoA-Request message, in order to
allow for easier translation between RADIUS and Diameter. In order to
simplify implementation, a RADIUS/Diameter gateway receiving a RADIUS
Disconnect-Request without a Service-Type value of "Authorize Only"
MAY reply with a Disconnect-Nak with an Error-Cause attribute with
value 405," Unsupported Service" and no Service-Type attribute.
Similarly, a RADIUS/Diameter gateway
receiving a RADIUS CoA-Request without a Service-Type value of
"Authorize Only" MAY reply with a CoA-Nak with an Error-Cause
attribute with value 405, "Unsupported Service" and no Service-Type
attribute.
When included within a RADIUS Disconnect-Request or CoA-Request, a
Service-Type Attribute with value "Authorize Only" indicates that the
Request only contains NAS and session identification attributes.
A RADIUS CoA-Request is translated to a Diameter Re-Authorization
Request (RAR), and a RADIUS Disconnect-Request is translated to a Diameter
Session-Termination-Request (STR).
A Diameter Re-Authorization Request (RAR) message will receive a
Diameter Re-Authorization Answer (RAA) reply which is translated to a
RADIUS CoA-NAK containing a Service-Type Attribute with value "Authorize Only"
and an Error-Cause Attribute with value "Request Initiated."
A Diameter Session-Termination-Request (STR) message will receive a
Diameter Session-Termination-Answer (STA) message reply which is translated
to a RADIUS Disconnect-Nak containing a Service-Type Attribute with value
"Authorize Only" and an Error-Cause Attribute with value "Request
Initiated."
After a Diameter Re-Authorization Answer (RAA) is sent, a
Diameter AA-Request will then be sent and is translated to
a RADIUS Access-Request with a Service-Type attribute with value "Authorize
Only",
attempting reauthorization. This Access-Request contains the NAS
attributes from the CoA-Request, as well as the session
attributes from the Request legal for inclusion in an Access-Request.
The RADIUS server will send back an Access-Accept to (re-)authorize
the session or an Access-Reject to refuse to (re-)authorize it. This is
translated to a Diameter AA-Answer.
After a Diameter Session-Termination-Answer (STA) is sent, a
Diameter Abort-Session-Request (ASR) will be sent and is translated to a
RADIUS Access-Request with a Service-Type attribute with value "Authorize
Only", attempting reauthorization. This Access-Request contains the NAS
and session attributes from the Disconnect-Rquest. The RADIUS server
send back an Access-Reject to terminate the session. This is translated to
a Diameter Abort-Session-Answer (ASA)."
Add the following to Section 9.2:
"If the Diameter/RADIUS gateway supports [RADDynAuth], it may translate
a Diameter Re-Authorization-Request (RAR) message to a RADIUS CoA-Request
with a Service-Type value of "Authorization Only". It is possible that the
NAS receiving this message will not support [RADDynAuth], in which case
an ICMP Port Unreachable message will be returned to the Diameter/RADIUS
gateway. However, even if the NAS supports [RADDynAuth], it may not
support a Service-Type value of "Authorization Only" in a CoA-Request
message. In this case
it will respond with a CoA-Nak and (optionally) an Error-Cause attribute with
value 405," Unsupported Service" and no Service-Type attribute. If a
Diameter/RADIUS gateway receives such a packet, or an ICMP port unreachable
message, or if it does not support [RADDynAuth], then it SHOULD reply
to the AAA server with a Diameter Re-Authorization-Answer (RAA) message with a
Result-Code AVP of "DIAMETER_COMMAND_UNSUPPORTED".
If in response to a CoA-Request sent to the NAS, the Diameter/RADIUS
gateway receives a RADIUS CoA-NAK containing a
Service-Type Attribute with value "Authorize Only"
and an Error-Cause Attribute with value "Request Initiated",
this is translated to a Diameter Re-Authorization-Answer (RAA)
with a Result-Code AVP of "DIAMETER_LIMITED_SUCCESS" sent to the
AAA server.
Subsequently, the Diameter/RADIUS gateway should receive a RADIUS Access-Request
from the NAS, with a Service-Type of "Authorize Only". This is
translated to a Diameter AA-Request with an Auth-Request-Type AVP of
AUTHORIZE_ONLY, sent to the AAA server. The AAA server will then reply
with a Diameter AA-Answer, which is translated to a RADIUS Access-Accept
or Access-Reject, depending on the value of the Result-Code AVP.
A Diameter/RADIUS gateway supporting [RADDynAuth] may translate
a Diameter Session-Termination-Request (STR) message received from the
AAA server to a RADIUS Disconnect-Request with a Service-Type value of
"Authorization Only", sent to the NAS.
It is possible that the NAS receiving this message will not support [RADDynAuth],
in which case an ICMP Port Unreachable message will be returned to the
Diameter/RADIUS gateway. Even if the NAS supports [RADDynAuth],
it may not support a Service-Type value of "Authorization Only" in a
Disconnect-Request message. In this case it will respond with a CoA-Nak
and (optionally) an Error-Cause attribute with
value 405," Unsupported Service" and no Service-Type attribute. If
the Diameter/RADIUS gateway encounters these error conditions, or if
it does not support [RADDynAuth], it sends a
Diameter Re-Authorization-Answer (RAA) message with an
Result-Code AVP of "DIAMETER_COMMAND_UNSUPPORTED" to the AAA server.
If the NAS does support [RADDynAuth] and a Disconnect-Request message with a
Service-Type value of "Authorize Only" it will typically reply with a
RADIUS Disconnect-NAK containing a Service-Type Attribute with value "Authorize
Only"
and an Error-Cause Attribute with value "Request Initiated".
A Diameter/RADIUS gateway supporting [RADDynAuth] translates this to a
Diameter Session-Termination-Answer (STA) with a Result-Code AVP of
"DIAMETER_LIMITED_SUCCESS", sent to the AAA Server.
Subsequently, the Diameter/RADIUS gateway should receive a RADIUS Access-Request
from the NAS, with a Service-Type of "Authorize Only". This is
translated to a Diameter Abort-Session-Request (ASR), sent to the AAA server.
The AAA server will then reply with a Diameter Abort-Session-Answer (ASA),
which the Diameter/RADIUS gateway translates to a RADIUS Access-Reject sent
to the NAS."
Proposed Resolution: Accept
Issue 427: Identities in RADIUS Translation
Submitter name: Pasi Eronen
Submitter email address: pasi.eronen@nokia.com
Date first submitted: September 30, 2003
Reference:
http://www.merit.edu/mail.archives/aaa-wg/msg05099.html
Document: NASREQ-12
Comment type: T
Priority: 1
Section: 9.1-9.3
Rationale/Explanation of issue:
While digging the Route-Record issue, I found several possible
problems in RADIUS translation (NASREQ -13b), related to
handling of Origin-Host/Realm and Destination-Host/Real AVPs...
1. Section 9.1 says that:
"If the Diameter Command-Code is set to AA-Answer and the
Result-Code AVP is set to DIAMETER_MULTI_ROUND_AUTH, the
gateway must send a RADIUS Access-Challenge with the
Diameter Session-Id and the Origin-Host AVPs encapsulated
in the RADIUS State attribute, with the prefix
"Diameter/". This is necessary in order to ensure that the
Translation Agent that will receive the subsequent RADIUS
Access-Request will have access to the Session Identifier,
and be able to set the Destination-Host to the correct
value.
Since both Session-Id and Origin-Host are placed into a
single State attribute (only one is allowed), they probably
need to be separated somehow. Can we assume that Origin-Host
doesn't contain any "/" characters? (likely to be true, although
in theory FQDN can contain just about anything)
(A minor note: since only one State attribute is
allowed in RADIUS, this breaks if the AA-Answer already contains
a State AVP. But since the State AVP should be used only
by translation agents, this should occur only if we
have multiple translation steps.)
2. The State attribute above stores the value needed for
Destination-Host, but what about Destination-Realm? Currently
it's taken from the User-Name attribute... and if the
Origin-Realm in AA-Answer is always guaranteed to be the same
as the Destination-Realm in AA-Request, then it should work.
But is this guaranteed?
(If it isn't, maybe we need to store the realm in State
attribute as well?)
3. Earlier Section 9.1 also says that
"If the RADIUS request contained a State attribute, and
the prefix of the data is "Diameter/", the data following
the prefix contains the Diameter Session-Id. If no such
attributes are present, and the RADIUS command is an
Access-Request, a new Session-Id is created. The
Session-Id is included in the Session-Id AVP.
This isn't in sync with the text above... the State attribute
can also contain the value for Destination-Host.
4. Also in Section 9.1:
"The Diameter Origin-Host and Origin-Realm AVPs MUST be
created and added using the information from an FQDN
corresponding to the NAS-IP-Address attribute (preferred
if available), and/or the NAS-Identifier attribute. (Note
that the RADIUS NAS-Identifier is not required to be an
FQDN)"
This text clearly suggests that Origin-Host should contain
the NAS identity, while the text in Section 9.3 says it
should be the translation agent's own identity.
The former seems IMHO more logical (and when forwarding a
RADIUS response to Diameter AA-Answer, the Origin-Host there
is the RADIUS server/proxy identity, not translation
agent)... but maybe there are some problems with this
approach?
A related issue: If this is the NAS identity (e.g. resolved
from NAS-IP-Address), how is the Origin-Realm chosen?
Do we use the translation agent's own realm or what?
5. Just after the text quoted above (also in 9.1)
"The AAA protocol specified in the identity would be
set to "RADIUS"."
Origin-Host/Origin-Realm have type DiameterIdentity, not
DiameterURI, so they don't have a protocol field. Just
delete this sentence.
6. Section 9.2 says that (when translating a RADIUS response
to Diameter AA-Answer)
"The response's Origin-Host information is created from
the FQDN of the source IP address of the RADIUS message."
What about Origin-Realm? Do we use the translation agent's
own realm?
Proposed Resolution: Discuss
Issue 428: NASREQ NITs
Submitter name: John Loughney
Submitter email address: john.loughney@nokia.com
Date first submitted: September 29, 2003
Reference:
http://www.merit.edu/mail.archives/aaa-wg/msg05090.html
Document: NASREQ-12
Comment type: E
Priority: S
Section: 4.8
Rationale/Explanation of issue:
The Originating-Line-Info AVP (AVP Code 94 is of type OctetString and there should be a ')' after 94.
Section 4.10:
4.10. Termination-Action AVP
The Termination-Action AVP is of type Enumerated and indicates what
action the NAS should take when the specified service is completed.
This AVP SHOULD only be present in authorization responses. The
following values are supported as listed in [RADIUSTypes]:
-> Missing AVP code.
Proposed Resolution: Accept
Issue 429: Conflict between NASREQ and EAP
Submitter name: John Loughney
Submitter email address: john.loughney@nokia.com
Date first submitted: September 29, 2003
Reference:
http://www.merit.edu/mail.archives/aaa-wg/msg05092.html
Document: EAP-02
Comment type: T
Priority: S
Section:
Rationale/Explanation of issue:
It seems that NASREQ & EAP have allocated the same AVP codes:
NASREQ:
Tunneling 401
CHAP-Auth 402
EAP:
Accounting-EAP-Auth-Method AVP AVP Code 401
EAP-Payload AVP AVP Code 402
My suggestion is that NASREQ keeps those values, and EAP marks its AVPs
as TBD.
[Pasi Eronen]
I agree (EAP has other AVPs with TBD codes, so it's no problem).
Proposed Resolution: Accept
Issue 430: 3GPP2 comments on NASREQ-13
Submitter name: Elizabeth Kidwell
Submitter email address:
ekidwell@lucent.com
Date first submitted: November 6, 2003
Reference:
Document: NASREQ-13
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:
Please find attached correspondence from 3GPP2 providing comments on the nasreq ID:
http://www.drizzle.com/~aboba/AAA/3gpp2-nas.pdf
Proposed Resolution: Discuss
Issue 431: Identities in RADIUS Translation
Submitter name: Pasi Eronen
Submitter email address: pasi.eronen@nokia.com
Date first submitted: September 30, 2003
Reference:
http://www.merit.edu/mail.archives/aaa-wg/2003-09/msg00037.html
Document: NASREQ 13b
Comment type: T
Priority: 1
Section: 9.1-9.3
Rationale/Explanation of issue:
While digging the Route-Record issue, I found several possible
problems in RADIUS translation (NASREQ -13b), related to
handling of Origin-Host/Realm and Destination-Host/Real AVPs...
1. Section 9.1 says that:
"If the Diameter Command-Code is set to AA-Answer
and the
Result-Code AVP is set to
DIAMETER_MULTI_ROUND_AUTH, the
gateway must send a RADIUS Access-Challenge with
the
Diameter Session-Id and the Origin-Host AVPs
encapsulated
in the RADIUS State attribute, with the prefix
"Diameter/". This is necessary in order to ensure
that the
Translation Agent that will receive the
subsequent RADIUS
Access-Request will have access to the Session
Identifier,
and be able to set the Destination-Host to the
correct
value.
Since both Session-Id and Origin-Host are placed into a
single State attribute (only one is allowed), they probably
need to be separated somehow. Can we assume that Origin-Host
doesn't contain any "/" characters? (likely to be true, although
in theory FQDN can contain just about anything)
(A minor note: since only one State attribute is
allowed in RADIUS, this breaks if the AA-Answer already contains
a State AVP. But since the State AVP should be used only
by translation agents, this should occur only if we
have multiple translation steps.)
2. The State attribute above stores the value needed for
Destination-Host, but what about Destination-Realm? Currently
it's taken from the User-Name attribute... and if the
Origin-Realm in AA-Answer is always guaranteed to be the same
as the Destination-Realm in AA-Request, then it should work.
But is this guaranteed?
(If it isn't, maybe we need to store the realm in State
attribute as well?)
3. Earlier Section 9.1 also says that
"If the RADIUS request contained a State
attribute, and
the prefix of the data is "Diameter/", the data
following
the prefix contains the Diameter Session-Id. If
no such
attributes are present, and the RADIUS command is
an
Access-Request, a new Session-Id is created. The
Session-Id is included in the Session-Id AVP.
This isn't in sync with the text above... the State attribute
can also contain the value for Destination-Host.
4. Also in Section 9.1:
"The Diameter Origin-Host and Origin-Realm AVPs
MUST be
created and added using the information from an
FQDN
corresponding to the NAS-IP-Address attribute
(preferred
if available), and/or the NAS-Identifier
attribute. (Note
that the RADIUS NAS-Identifier is not required to
be an
FQDN)"
This text clearly suggests that Origin-Host should contain
the NAS identity, while the text in Section 9.3 says it
should be the translation agent's own identity.
The former seems IMHO more logical (and when forwarding a
RADIUS response to Diameter AA-Answer, the Origin-Host there
is the RADIUS server/proxy identity, not translation
agent)... but maybe there are some problems with this
approach?
A related issue: If this is the NAS identity (e.g. resolved
from NAS-IP-Address), how is the Origin-Realm chosen?
Do we use the translation agent's own realm or what?
5. Just after the text quoted above (also in 9.1)
"The AAA protocol specified in the identity would
be
set to "RADIUS"."
Origin-Host/Origin-Realm have type DiameterIdentity, not
DiameterURI, so they don't have a protocol field. Just
delete this sentence.
6. Section 9.2 says that (when translating a RADIUS response
to Diameter AA-Answer)
"The response's Origin-Host information is
created from
the FQDN of the source IP address of the RADIUS
message."
What about Origin-Realm? Do we use the translation agent's
own realm?
[Jari Arkko]
|
||||||
Proposed Resolution: Discuss
Issue 432: Type Conflict in MIPv4
Submitter name: Yoshihiro Ohba
Submitter email address:
yohba@tari.toshiba.com
Date first submitted: September 30, 2003
Reference:
http://www.merit.edu/mail.archives/aaa-wg/2003-09/msg00040.html
Document: MIP-14
Comment type: T
Priority: S
Section: 4.0
Rationale/Explanation of issue:
Section 4.0 of draft-ietf-aaa-diameter-mobileip-14.txt says that
MIP-Host-Agent-Host AVP is of type DiameterIdentity:
MIP-Home-Agent- 348 4.11 DiamIdent | M
| P | | V | N |
Host
| | | |
| |
On the other hand, in Section 4.11 the same AVP is defined as type Grouped:
MIP-Home-Agent-Host ::= < AVP Header: 348 >
{ Destination-Realm }
{ Destination-Host }
* [ AVP ]
Which is correct?
Proposed Resolution: Discuss
Issue 433: Abnormal-Termination-Reason AVP
Replaced by Abnormal-Termination-Cause AVP
Submitter name: Harri Hakala
Submitter email address: harri.hakala@ericsson.com
Date first submitted: October 1, 2003
Reference:
http://www.merit.edu/mail.archives/aaa-wg/2003-10/msg00000.html
Document: CCA-00
Comment type: T
Priority: 2
Section: 3.1, 5.1, 7.1, 9.5
Rationale/Explanation of issue:
The Diameter Base protocol contains a Termination-Cause AVP that can be used to
indicate the reason why the session was terminated. The
Abnormal-Termination-Reason
AVP was introduced in the Credit Control Application for the same purpose and
can
be removed as redundant AVP. The Abnormal-Termination-Reason AVP should be
replaced
by the Termination-Cause AVP in Credit-Control-Request message.
Proposed change:
Section 3.1
Replace Abnormal-Termination-Reason with Termination-Cause.
Section 5.1
Remove.
Section 7.1
Replace Abnormal-Termination-Reason with Termination-Cause.
Section 9.5
Remove.
Best Regards.............Harri
Fixes:
http://www.merit.edu/mail.archives/aaa-wg/2003-10/msg00016.html
Proposed Resolution: Accept
Issue 434: Rating Input
Submitter name: Harri Hakala
Submitter email address: harri.hakala@ericsson.com
Date first submitted: October 3, 2003
Reference:
http://www.merit.edu/mail.archives/aaa-wg/2003-10/msg00003.html
Document: CCA-00
Comment type: T/E
Priority: 2
Section: 4
Rationale/Explanation of issue:
There have two ways to provide rating input to the CC server,
either by including them in the Service-Parameter-Info AVP or by re-using AVPs
from other
standard/vendor specific Diameter applications (NASREQ, Mobile IP).
The CCA only describes the first option but not the other. Some rating
functionality is discussed here and there in the draft but a general
principles are not addressed in the draft.
Proposed change:
ADD:
4.x Rating Input
There SHOULD be an agreement between the service providers of the credit control
client and the credit control server in order to know who shall handle the
billing
of which services, which chargeable services are available when roaming etc.
Part of
this process has to cover also the agreed rating input.
There are two ways for providing rating input to the credit control server,
either by
including them in the Service-Parameter-Info AVP or by re-using AVPs from other
Diameter
applications. The general principle for sending rating parameters is that the
service
SHOULD re-use existing AVPs, if the service can use AVPs defined by some
Diameter application.
The Service-Parameter-Info AVP SHOULD be used when the service is not using any
other Diameter
application or can't re-use any AVPs.
The service specific rating input AVPs or the contents of the
Service-Parameter-Info AVP are
not within the scope of this document and SHOULD be defined in another Diameter
application,
standards written by other standardization bodies, or service specific
documentation.
Within a credit control request, setting the "M" bit implies that a
rating server or the credit control server itself SHOULD understand the AVP in
order to rate
the service. However, since different service providers may apply different
rating policies a
mandatory input parameter for one server might be irrelevant for another.
Therefore, if the AVP
is not relevant to the rating process, when the AVP is included within a
credit-control request,
it can be ignored, even if the "M" bit is set.
In case a rating input required for rating process is missing from the Credit
control
request, the Credit control answer MUST contain error code
DIAMETER_RATING_FAILED. A CCR message
with this error MUST contain one or more Failed-AVP AVPs containing the missing
AVPs that caused
the failure.
Fixes:
http://www.merit.edu/mail.archives/aaa-wg/2003-10/msg00041.html
Proposed Resolution: Accept
Issue 435: Use Framed-MTU instead of EAP-MTU AVP?
Submitter name: Pasi Eronen
Submitter email address: pasi.eronen@nokia.com
Date first submitted: October 14, 2003
Reference:
http://www.merit.edu/mail.archives/aaa-wg/2003-10/msg00038.html
Document: EAP-02
Comment type: T
Priority: 1
Section: various
Rationale/Explanation of issue:
I proposed adding EAP-MTU AVP to version -02, but now I've come
to think that actually this is not absolutely necessary, and
complicates RADIUS translation. Any other opinions? (I'm OK
with either choice)
Requested change:
To simplify things, remove the EAP-MTU AVP. Instead of it, use
Framed-MTU as described in RFC3579 (and borrow some text from
there).
Proposed Resolution: Discuss
Issue 436: Multiple services credit control in a
single CC session (Diameter CCA)
Submitter name: Marco Stura
Submitter email address: marco.stura@nokia.com
Date first submitted: October 15, 2003
Reference:
http://www.merit.edu/mail.archives/aaa-wg/2003-10/msg00039.html
Document: draft-ietf-aaa-diameter-cc-00
Comment type: T
Priority: 2
Section: various
Rationale/Explanation of issue:
There may be service elements in certain service environments that provide
multiple services, or
just credit control for multiple services, within the same authorization session
to an end user.
For each of those services the price may be different requiring differentiated
credit control per service.
With the current draft such a service element would need to open multiple credit
control sessions
(or sub-sessions) resulting in increased signaling load and resource usage in
both the CC-client
and in the CC-server.
I propose to address the support of multiple services credit control in a single
CC session
in the Diameter CCA. This means that credit authorization can be requested for
multiple
services, or a group of services, within a single Credit-Control-Request.
Multiple quotas associated
to the relevant service, or group of services, will be returned in the
corresponding Credit-Control-
Answer in order to enable differentiated credit control per service.
The proposal takes already into account the new structure for the
Granted-Service-Unit,
Requested-Service-Unit and Used-Service-Unit AVPs agreed in the past weeks in
AAA mailing
list.
Proposed changes:
Section 4, fourth paragraph
Change
FROM:
There are certain applications that require multiple credit control
sub-sessions. Such applications would send messages with a constant
Session-Id AVP, but a different CC-Sub-Session-Id AVP. If several
credit sub-sessions will be used, all sub-sessions MUST be closed
separately before the closing the main session to be able to report
used units per sub-session. The absence of this AVP implies no sub-
sessions are in use.
TO:
There are certain applications that require multiple credit control
sub-sessions. Such applications would send messages with a constant
Session-Id AVP, but a different CC-Sub-Session-Id AVP. If several
credit sub-sessions will be used, all sub-sessions MUST be closed
separately before the closing the main session to be able to report
used units per sub-session. The absence of this AVP implies no sub-
sessions are in use.
When multiple services are used within one user session and each service or
group of services are subject to different cost, making use of credit control
sub-sessions will result in increased signaling load and resources usage in both
the credit control client and the credit control server. For instance, during
one network access session the end user may use several http-services subject to
different access cost. To optimally support these scenarios, the credit control
application enables for multiple services credit control in a single credit
control session. It is possible to request and allocate multiple quotas as a
credit pool that is shared between multiple services. The services can be
further grouped into rating groups in order to achieve even further aggregation
of credit allocation.
It is also possible to request and allocate multiple quotas on a per service
basis. The mechanism is illustrated in Appendix A (Flow xxx).
Section 4.1.1, fifth paragraph
Change
FROM:
However there MUST be maximum one instance of the same unit type in one
Answer message.
TO:
There MUST be maximum one instance of the same unit type in one
Answer message. In case multiple quotas are conveyed to the credit control
client, there MUST be maximum one instance of the same unit type associated to a
Service-Identifier, or set of Service-Identifiers, or associated to a
Rating-Group.
ADD Service-Identifier and Rating-Group AVPs to section 5.17
The Service-Identifier and the Rating-Group AVPs are used to request units for a
given service(s) or rating group when the service element supports credit
control for multiple services in one credit control session.
If both the AVPs are present, the Rating-Group AVP indicates the rating group to
which the service(s) specified by the Service-Identifier(s) belongs. If only the
Rating-Group-Id AVP is present, this is a credit authorization request for all
the services that belongs to the specified rating group.
A server not implementing the Service-Identifier and the Rating-Group must treat
them as invalid AVPs.
Requested-Service-Unit ::= < AVP Header: TBD >
[ CC-Time ]
[ CC-Money ]
[ CC-Total-Octets ]
[ CC-Input-Octets ]
[ CC-Output-Octets ]
[ CC-Service-Specific-Units ]
*[ Service-Identifier ]
[ Rating-Group ]
ADD Service-Identifier and Rating-group AVPs to section 5.15
The Service-Identifier and the Rating-Group AVPs are used to associate the
granted units to a given service or rating group.
In case both the Service-Identifier and the Rating-Group AVPs are included, the
target of the granted units is(are) always the service(s) indicated by the value
of the Service-Identifier AVP.
Granted-Service-Unit ::= < AVP Header: TBD >
[ CC-Time ]
[ CC-Money ]
[ CC-Total-Octets ]
[ CC-Input-Octets ]
[ CC-Output-Octets ]
[ CC-Service-Specific-Units ]
*[ Service-Identifier ]
[ Rating-Group ]
ADD Service-Identifier and Rating-Group AVPs to section 5.26
The Service-Identifier and the Rating-Group AVPs are used to associate the used
units to a given service or rating group.
When granted service units are associated to a service or rating group, the
credit control client MUST report the corresponding used service units. If the
granted units are associated to a rating group, the units used by each of the
Service-Identifier belonging to that rating group SHOULD be reported if this
information is available to the credit control client. Therefore, multiple
instances of the Used-Service-Unit AVP MAY be present in a request, each
associated to the relevant Rating-Group-Id and to the identifier of the service
(i.e. Service-Identifier) that consumed some of the granted units.
Used-Service-Unit ::= < AVP Header: TBD >
[ CC-Time ]
[ CC-Money ]
[ CC-Total-Octets ]
[ CC-Input-Octets ]
[ CC-Output-Octets ]
[ CC-Service-Specific-Units ]
*[ Service-Identifier ]
[ Rating-Group ]
5.x Rating-Group AVP
The Rating-Group AVP is of type Unsigned32 (AVP Code TBD) and contains the
identifier of a rating group. All the services subject to the same rating type
are part of the same rating group. This is an identifier allocated by the home
service provider and MUST be unique within the home service provider domain.
A usage example of this AVP is illustrated in Appendix A (Flow xxx).
5.y Service-Identifier AVP
The Service-Identifier AVP is of type UTF8String (AVP Code TBD) and contains a
unique identifier of a given service. This is an identifier allocated by the
service provider and MUST uniquely identify a given service (e.g. Service 1@example.com).
A usage example of this AVP is illustrated in Appendix A (Flow xxx).
ADD the Flow xxx to Appendix A
Flow xxx
The Diameter Credit Control Application defines the Rating-Group and
Service-Identifier AVPs that can be used to support credit control for multiple
services in a single credit control session for service elements that have such
capabilities. The flow example hereafter illustrates the usage of these AVPs.
It is assumed that the Service-Identifiers and the Rating-Groups are locally
configured in the Service Element or provisioned by another entity than the
credit control server.
The credit control client may request credit authorization either for all the
possible configured Rating-Groups in one single request, onwards named
all-in-one mode, or for a single Rating-Group upon an external triggering event,
onwards named on-demand mode. The on-demand mode can be used as well to request
individual credit resource limit for each service.
In this example only the all-in-one mode is shown.
A single credit reservation is kept for the credit control session to simplify
the account management tasks. The credit control server reserves an amount of
credit from the user's account and performs rating for all the requested
Rating-Groups and Service-Identifiers against the reserved credit.
For instance, assume a Credit-Control-Request is received with Rating-Group-Id 1
and 2. The credit control server queries the rating server that answers with the
following rating parameters: Rating-Group 1 costs $1/Mbyte and Rating-Group 2
costs $1/minute. The credit control server reserves $20 from the user's account;
this gives 20Mbytes for Rating-Group 1 and 20minutes for Rating-Group 2.
The calculated quotas are conveyed to the credit control client in the CCA
message, each quota associated with the appropriate Rating-Group or
Service-Identifier. At this point the credit control client just need to track
the fraction of reserved credit used by the corresponding service or
Rating-Group, when the sum of the fractions reaches 100% the credit control
client sends an intermediate interrogation since the whole amount of reserved
credit is consumed.
If the credit control client initializes a counter C for each of the received
quota Q (C1 for Q1, C2 for Q2 ... Cn for Qn), the intermediate interrogation
will be sent when sum(C1/Q1 + C1/Q2 + ... + Cn/Qn)>= 1.
Continuing the example, say the end user uses 10 Mbytes from Rating-Group 1 and
10minutes from Rating-Group 2. This means that Rating-Group 1 consumed 50% of
the reservation and Rating-Group 2 consumed the remaining 50%. 0.5 + 0.5 >=1, so
the credit control client sends an intermediate interrogation to report the used
units and request new ones.
Service Element
End-User (CC client) CC Server
|(1)User logon | |
|------------------>|(2)CCR(initial,Requested-Units(Rating-Group 1),
| | Requested-Units(Rating-Group 2)) |
| |---------------------------------------->|
| |(3)CCA(Granted-Units(Rating-Group 1, |
| | Total-Octets)) |
| | Granted-Units(Rating-Group 2, |
| | Time)) |
| |<----------------------------------------|
: : :
|(4)Service-Request (Service 1) |
|------------------>| |
: : :
|(5)Service-Request (Service 2) |
|------------------>| |
: : :
| |(6)CCR(update, Used-Units(Input-Octets, |
| | Output-Octets, |
| | Service-Id 1, |
| | Rating-Group 1),
| | Used-Units(Time, |
| | Service-Id 2, |
| | Rating-Group 2),
| | Requested-Units(Rating-G.1),
| | Requested-Units(Rating-G.2))
| |---------------------------------------->|
| |(7)CCA(Granted-Units(Rating-Group 1, |
| | Total-Octets), |
| | Granted-Units(Rating-Group 2, |
| | Time)) |
| |<----------------------------------------|
: : :
|(8)Service-Request (Service 3) |
|------------------>| |
: : :
|(9) User logoff | |
|------------------>|(10)CCR(term, Used-Units(Input-Octets, |
| | Output-Octets, |
| | Service-Id 1, |
| | Rating-Group 1),|
| | Used-Units(Input-Octets, |
| | Output-Octets, |
| | Service-Id 3, |
| | Rating-Group 1),|
| | Used-Units(Time, |
| | Service-Id 2, |
| | Rating-Group 2),|
| |---------------------------------------->|
| |(11)CCA(term) |
| |<----------------------------------------|
Figure A.xxx: Credit Control for Multiple Services in One Credit
Control Session, flow example
The user logs onto the network (1). The Service Element sends a Diameter
Credit-Control-Request with CC-Request-Type set to INITIAL_REQUEST to the
Diameter credit-control server to perform credit authorization for multiple
rating groups and to establish a credit control session (2). In this message
credit authorization is requested for Rating-Group 1 and Rating-Group 2 by
including two instances of the Requested-Service-Unit AVP. The Diameter
credit-control server checks the end user's account balance, based on the
Rating-Group information rates the request and reserves credit from the end
user's account. Multiple quotas are returned to the Service Element, each
associated with the relevant Rating-Group (3). The user uses service 1 and
service 2 (4, 5). The service 1 belongs to Rating-Group 1 and is volume based
charged, the service 2 belongs to Rating-Group 2 and is time based charged. When
the user has consumed the allotted credit, the Service Element sends a Diameter
Credit-Control-Request with CC-Request-Type set to UPDATE_REQUEST to the credit
control server (6). This message contains the units consumed by each of the used
services in the Used-Service-Unit AVPs and two instances of the
Requested-Service-Unit AVP to request credit re-authorization for the two
Rating-Groups. The used units are associated with the relevant
Service-Identifier and Rating-Group.
The Diameter credit-control server debits the used units from the end user's
account and reserves a new amount of credit that is returned in form of multiple
quotas to the Service Element in the Diameter Credit-Control-Answer (7). Each
quota is associated with the relevant Rating-Group. In addition to service 1 and
service 2, the user now starts using service 3 (8). Service 3 belongs to
Rating-Group 1 and is charged based on volume. The end user logs off from the
network (9). To debit the used units from the end user's account and to stop the
credit control session, the Service Element sends a Diameter
Credit-Control-Request with CC-Request-Type set to TERMINATION_REQUEST to the
credit control server (10).
This message contains the units consumed by each of the used services in the
Used-Service-Unit AVPs. The used units are associated with the relevant
Service-Identifier and Rating-Group. The Diameter credit-control server debits
the used units to the user's account and acknowledges the session termination by
sending a Diameter Credit-Control-Answer to the Service Element (11).
Fixes: http://www.merit.edu/mail.archives/aaa-wg/2003-10/msg00050.html
Proposed Resolution: Accept
Issue 437: Updated security considerations for
Diameter EAP
Submitter name: Pasi Eronen
Submitter email address: pasi.eronen@nokia.com
Date first submitted: October 22, 2003
Reference:
http://www.merit.edu/mail.archives/aaa-wg/2003-10/msg00047.html
Document: EAP-02
Comment type: T/E
Priority: 1
Section: 8
Rationale/Explanation of issue:
The current security considerations section has a lot of text that
doesn't really belong there (e.g. about certificates and
authorization), and some text unnecessarily duplicating issues that
are already well presented in 2284bis and the new EAP key management
framework document.
Suggested change: Replace section 8 with the following text.
8. Security Considerations
8.1 Overview
Diameter peer-to-peer connections can be protected with IPsec or
TLS.
These mechanisms are believed to provide sufficient protection
under
the normal Internet threat model--that is, assuming the authorized
nodes engaging in the protocol have not been compromised, but the
attacker has complete control over the communication channels
between
them. This includes eavesdropping, message modification,
insertion,
man-in-the-middle and replay attacks. The details and related
security considerations are discussed in [BASE].
In addition to authentication provided by IPsec or TLS,
authorization
is also required. Authorization here means the act of
determining if
a Diameter message received from an authenticated Diameter peer
should be accepted (and not authorization of users requesting
network
access from a NAS). In other words, when a Diameter server
receives
a Diameter-EAP-Request, it has to decide if the client is
authorized
to act as a NAS for the specific user, service type, and so on.
Correspondingly, when a NAS contacts a server to send a
Diameter-EAP-Request, it has to determine whether the server is
authorized to act as home server for the realm in question.
Authorization can involve local Access Control Lists (ACLs),
information contained in certificates, or some other means.
See
[BASE] for more discussion and related security considerations.
The hop-by-hop security mechanisms (IPsec and TLS) combined with
proper authorization provide good protection against "outside"
attackers (denial-of-service is, of course, possible). The
remaining
part of this section deals with attacks by nodes that have been
properly authorized (to function as a NAS, Diameter agent, or
Diameter server) but abuse their authorization or have been
compromised. In general, it is not possible to completely
protect
against attacks by compromised nodes, but this section offers some
advice that can be used to limit the extent of the damage.
Attacks involving eavesdropping or modification of EAP messages are
beyond the scope of these document. See [RFC2284bis] for discussion
of these security considerations (including method negotation,
dictionary attacks, and privacy issues). While these attacks can be
carried out by an attacker between the client and the NAS,
compromised NASes and Diameter agents are naturally also in a good
position to modify and eavesdrop the EAP messages.
Similarly, attacks involving whatever link layer protocol is used
between the client and the NAS, such as PPP or IEEE 802.11, are
beyond the scope of this document.
8.2 AVP editing
Diameter agents can modify, insert, and delete AVPs. Diameter
agents
are usually meant to modify AVPs, and the protocol in general
cannot
distinguish well-intentioned and malicious modifications (see
[RFC2607] for more discussion). Similarly, a compromised NAS or
server can naturally include different set of AVPs than expected.
The question is thus "what can an attacker who compromises an
authorized NAS, agent, or server do using Diameter EAP messages?"
Some of the consequences are rather obvious--for instance, a
Diameter
agent can give access to unauthorized users by changing the
Result-Code to DIAMETER_SUCCESS. Other consequences are less
obvious,
and are discussed below (authentication method negotiation attacks
are discussed in the next section).
By including suitable AVPs in an AA-Answer/Diameter-EAP-Answer
messages an attacker (depending on implementation and configuration
details) may be able to:
o Give unauthorized users access, or deny access to
authorized users
(Result-Code).
o Give attacker a login session to a host otherwise protected
by
firewalls, or redirect an authorized user's login
session to a
host controlled by the attacker (Login-Host).
o Route an authorized user's traffic through a host
controlled by
the attacker (various tunneling AVPs).
o Redirect an authorized user's DNS requests to a malicious
DNS
server (various vendor-specific AVPs).
o Modify routing tables at the NAS and thus redirect packets
destined for someone else (Framed-Route,
Framed-Routing).
o Remove packet filters and other restrictions for user
(Filter,
Callback, various vendor-specific AVPs).
o Cause the NAS to call some number, possibly expensive toll
number
controlled by the attacker (callback AVPs)
o Execute Command Line Interface (CLI) commands on the NAS
(various
vendor-specific attributes).
By modifying an AA-Request/Diameter-EAP-Request, an attacker may be
able to:
o Change NAS-Identifier/NAS-Port/Origin-Host (or something)
so that
a valid user appears to be accessing the network
from a different
NAS than in reality.
o Modify Calling-Station-ID (either to hide the true value,
gain
access, or frame someone else).
o Modify password change messages (some vendor-specific
attributes)
o Modify usage information in accounting messages.
o Modify contents of Class/State AVPs?
Some of these attacks can be prevented if the NAS or server can be
configured not to accept some particular AVPs, or accepting them
only
from some nodes.
8.3 Negotiation attacks
This section deals with attacks where the NAS, any Diameter agents,
or Diameter server attempts to cause the authenticating user to
choose some authentication method other than EAP, such as PAP or
CHAP
(negotiation attacks within EAP are discussed in [RFC2284bis],
Section 7.8).
The vulnerability can be mitigated via implementation of
per-connection policy on the part of the authenticating peer, and
per-peer policy on the part of the Diameter server. For the
authenticating peer, authentication policy should be set on a
per-connection basis.
With per-connection policy, an authenticating peer will only
attempt
to negotiate EAP for a session in which EAP support is expected.
As
a result, there is a presumption that an authenticating peer
selecting EAP requires that level of security. If it cannot be
provided, it is likely that there is some kind of misconfiguration,
or even that the authenticating peer is contacting the wrong
server.
In this case, the authenticating peer simply disconnects.
Similarly, with a per-user policy, the home server will not accept
authentication methods other than EAP for users for which EAP
support
is expected.
For a NAS, it may not be possible to determine whether a peer is
required to authenticate with EAP until the peer's identity is
known.
For example, for shared-uses NASes it is possible for one reseller
to
implement EAP while another does not. Alternatively, some
peer might
be authenticated locally by the NAS while other peers are
authenticated via Diameter. In such cases, if any peers of
the NAS
MUST do EAP, then the NAS MUST attempt to negotiate EAP for every
session. This avoids forcing a peer to support more than one
authentication type, which could weaken security.
8.4 Session key distribution
Since there are currently no end-to-end (NAS-to-home server)
security
mechanisms specified for Diameter, any agents that process
Diameter-EAP-Answer messages can see the contents of the
EAP-Session-Key AVP. For this reason, this specification
strongly
recommends avoiding Diameter agents when they cannot be trusted to
keep the keys secret.
In environments where agents are present, several factors should be
considered when deciding whether the agents that are authorized
(and
considered "trustworthy enough") to grant access to users and
specify
various authorization and tunneling AVPs are also "trustworthy
enough" to handle the session keys. These factors include
(but are
not limited to) the type of access provided (e.g., public Internet
or
corporate internet), security level of the agents, and the
possibilities for attacking user's traffic after it has been
decrypted by the NAS.
Note that the keys communicated in Diameter messages are usually
short-term session keys (or short-term master keys that are used to
derive session keys). To actually cause any damage, those
session
keys must end with some malicious party; that party must be able to
eavesdrop, modify, or insert traffic between the user and the NAS
during the lifetime of those keys (e.g., in 802.11i the attacker
must
also eavesdrop the "four-way handshake"); and that eavesdropping or
modification must cause some damage.
8.5 Privacy issues
Diameter messages can contain AVPs that can be used to identify the
user (e.g., User-Name) and approximate location of the user (e.g.
Origin-Host for WLAN access points, Calling-Station-Id for fixed
phone lines). Thus, any Diameter nodes that process the
messages may
be able to determine the geographic location of users.
Note that in many cases, the user identity is also sent in clear
inside EAP-Payload AVPs, and it may be possible to eavesdrop this
between the user and the NAS.
This can mitigated somewhat by using EAP methods that provide
identity protection (see [RFC2284bis], Section 7.3), and using
Session-Id or pseudonyms for accounting.
8.6 Note about EAP and impersonation
If the EAP method used does not provide mutual authentication,
obviously anyone can impersonate as the network to the user.
Even
when EAP mutual authentication is used, it occurs between the user
and the Diameter home server. See for an extensive discussion
about
the details and their implications.
However, one issue is worth pointing out here. As described in
[EAPKey], the current EAP architecture does not allow the home
server
to restrict what service parameters or identities (such as SSID or
BSSID in 802.11 wireless LANs) are advertised by the NAS to the
client. That is, a compromised NAS can change its BSSID or SSID,
thus
appearing to offer a different service than intended. Even if
these
parameters are included in Diameter-EAP-Request messages, the NAS
can
tell different values to the client.
Thus, the possession of the session keys by the NAS proves that the
user is talking to *some* authorized NAS, but a compromised NAS can
lie about its exact identity. See [EAPKey] for discussion how
individual EAP methods can provide authentication of NAS service
parameters and identities.
Note that the usefulness of such authentication may be rather
limited
in many environments. For instance, in wireless LANs the user does
not usually securely know the identity (such as BSSID) of the
"right"
access point--it's simply picked from a beacon message that has the
correct SSID and good signal strength (something that's easy to
spoof). Thus, simply authenticating the identity may not allow the
user to distinguish the "right" access point from all other ones.
Proposed Resolution: Discuss
Issue 438: Updated CCA Security Considerations
Submitter name: John Loughney
Submitter email address: john.loughney@nokia.com
Date first submitted: October 23, 2003
Reference:
http://www.merit.edu/mail.archives/aaa-wg/2003-10/msg00051.html
Document: CCA-00
Comment type: T
Priority: S
Section: 9
Rationale/Explanation of issue:
9. Security Consideration
The Diameter base protocol [DIAMBASE] assumes that each Diameter implementation
uses underlying security, i.e. IPsec or TLS. These mechanisms are believed to
provide sufficient protection under the normal Internet threat model - that is,
assuming the authorized nodes engaging in the protocol have not been
compromised, but the attacker has complete control over the communication
channels between them. This includes eavesdropping, message modification,
insertion, man-in-the-middle and replay attacks. Note also that this application
includes a mechanism for application layer replay protection by the means of
Session-ID from [DIAMBASE], and CC-Request-Number specified in this document.
The Diameter credit control application is often used within one domain and
there may be just single hop between the peers. In these environments the use of
TLS or IPsec is sufficient. The details of TLS and IPsec related security
considerations are discussed in the [DIAMBASE].
Because this application handles monetary transactions (directly or indirectly)
this kind of application increases the interest for various security attacks.
Therefore extra attention should be paid to the authentication of the client and
the server, as well as the possible proxy and relay agents. In addition to this,
authorization of the client shall be emphasised, i.e. that the client is allowed
to perform credit control for a certain user.
Another kind threat is malicious modification, injection or deletion of AVPs or
complete credit control messages. The credit control messages contain sensitive
billing related information (such as subscription Id, granted units, used units,
cost information) whose malicious modification can have economical consequences.
Sometimes simply delaying the credit control messages can cause disturbances in
the credit control client or server.
Even without any modification to the messages an adversary can invite a security
threat by eavesdropping, because the transactions contain private information
about the user. Also by monitoring the credit control messages one can collect
information about credit control server's billing models and business
relationships.
When third party relays or proxy are involved, the hop-by-hop security does not
necessarily provide sufficient protection for Diameter user session. Diameter
messages, such as CCR and CCA, containing sensitive AVPs are NOT RECOMMENDED to
be sent via untrusted Diameter proxy agents since there are no assurance that
third party proxies will not modify the credit control commands or AVP values.
Section 9.1 describes a scenario how to make the situation a single hop if the
security requirements demands that.
9.1 Direct connection with redirects
A Diameter Credit control agent cannot always know whether agents between it and
the end user's Diameter credit control server are reliable. In this case the
Diameter Credit control agent doesn't have a routing entry in its Diameter
Routing Table for the realm of the Credit Control Server in the end user's home
domain. The Diameter Credit control agent can have a default route configured to
a local Redirect agent and it re-directs the CCR message to the redirect agent.
The local Redirect agent then returns a redirect notification (Result-code 3006,
DIAMETER_REDIRECT_INDICATION) to the Credit control agent, as well Diameter
Credit control Server(s) information (Redirect-Host AVP) and information
(Redirect-Host-Usage AVP) how to the routing entry resulting from the
Redirect-Host is to be used. The Diameter credit control agent then forwards the
CCR message directly to one of the hosts identified by the CCA message from the
redirect agent. If the value of the Redirect-Host-Usage AVP is unequal than zero
all following messages are sent to the host specified in the Redirect-Host AVP
until the time specified by the Redirect-Max-Cache-Time AVP is expired.
Fixes: Changes made in CCA-01, except for Jari's comments:
http://www.merit.edu/mail.archives/aaa-wg/2003-10/msg00060.html
Proposed Resolution: Accept
Issue 439: Updated CCA IANA Values
Submitter name: John Loughney
Submitter email address: john.loughney@nokia.com
Date first submitted: October 23, 2003
Reference:
http://www.merit.edu/mail.archives/aaa-wg/2003-10/msg00052.html
Document: CCA-00
Comment type: T
Priority: S
Section:
Rationale/Explanation of issue:
If noone objects, I am going to assign in the current open range values for
The Diameter Credit Control Application. There is 1 pair of commands:
Credit-Control-Request CCR
272 3.1
Credit-Control-Answer CCA
272 3.2
1 Application ID:
Diameter Credit Control 4
A number of AVPs, starting from a value of 411.
Proposed Resolution: Accept
Issue 440: Separation of sent and received bytes in
CCA
Submitter name: Leena Mattila
Submitter email address: leena.mattila@ericsson.com
Date first submitted: October 2, 2003
Reference:
http://www.merit.edu/mail.archives/aaa-wg/2003-10/msg00002.html
Document: CCA-00
Comment type: T
Priority: 2
Section: 5.x, 5.15, 5.17, 5.26, 9.x
Rationale/Explanation of issue:
In the current Credit Control Application it is not possible
to measure the sent and received bytes separately. However,
for some services the direction of the measured data volume
can play an important role in billing, and thus there should
be a possiblity to make a distinction between the sent and
received bytes.
Proposed change:
ADD Section:
5.x Volume-Direction AVP
The Volume-Direction AVP (AVP Code TBD) is of type Enumerated and
indicates in which direction the units of type volume are counted.
INPUT
0
When the Volume-Direction AVP is set to
INPUT the Unit-Value AVP
contains the bytes received from the user.
OUTPUT
1
When the Volume-Direction AVP is set to
OUTPUT the Unit-Value AVP
contains the bytes sent to the user.
Section 5.15
FROM:
If the Unit-Type AVP is set to volume in the
Credit-Control-Answer or
AA Answer command, the Unit-Value AVP specifies the
granted volume in
bytes.
TO:
If the Unit-Type AVP is set to volume in the
Credit-Control-Answer or
AA Answer command, the Unit-Value AVP specifies the
granted volume in
bytes, optionally detailed with direction information (sent or
received bytes). If no direction information is included, the
Unit-Value AVP contains the total volume.
FROM:
It has the following ABNF grammar:
<Granted-Service-Unit>::=< AVP Header: TBD >
{ Unit-Type }
{ Unit-Value }
[ Currency-Code ]
TO:
It has the following ABNF grammar:
<Granted-Service-Unit>::=< AVP Header: TBD >
{ Unit-Type }
{ Unit-Value }
[ Currency-Code ]
[ Volume-Direction ]
Section 5.17
FROM:
If the Unit-type AVP is set to volume in the Credit-Control-Request
command, the Unit-Value AVP specifies the requested volume
in bytes.
TO:
If the Unit-type AVP is set to volume in the Credit-Control-Request
command, the Unit-Value AVP specifies the requested volume
in bytes,
optionally detailed with direction information (sent or received
bytes). If no direction information is included, the Unit-Value AVP
contains the total volume.
FROM:
It has the following ABNF grammar:
<Requested-Service-Unit>::=< AVP Header: TBD >
{ Unit-Type }
{ Unit-Value }
[ Currency-Code ]
TO:
It has the following ABNF grammar:
<Requested-Service-Unit>::=< AVP Header: TBD >
{ Unit-Type }
{ Unit-Value }
[ Currency-Code ]
[ Volume-Direction ]
Section 5.26
FROM:
If the Unit-Type AVP is set to volume in the Credit-Control-Request
command, the Unit-Value AVP specifies the used volume in bytes.
TO:
If the Unit-type AVP is set to volume in the Credit-Control-Request
command, the Unit-Value AVP specifies the used volume in bytes,
optionally detailed with direction information (sent or received
bytes). If no direction information is included, the Unit-Value AVP
contains the total volume.
FROM:
It has the following ABNF grammar:
<Used-Service-Unit>::=< AVP Header: TBD >
{ Unit-Type }
{ Unit-Value }
[ Currency-Code ]
TO:
It has the following ABNF grammar:
<Used-Service-Unit>::=< AVP Header: TBD >
{ Unit-Type }
{ Unit-Value }
[ Currency-Code ]
[ Volume-Direction ]
ADD Section:
9.x Volume-Direction AVP
As defined in Section 5.x, the Volume-Direction AVP (AVP Code
TBD) defines the values 0-1. All remaining values are available for
assignment via Designated Expert [IANA].
Fixes:
http://www.merit.edu/mail.archives/aaa-wg/2003-10/msg00044.html
Proposed Resolution: Accept
Issue 441: Failure procedures updated
Submitter name: John Loughney
Submitter email address: john.loughney@nokia.com
Date first submitted: September 2, 2003
Reference:
http://www.merit.edu/mail.archives/aaa-wg/2003-09/msg00008.html
Document: CCA-00
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:
After some discussion, we are proposing the following changes to the Credit
Control
Failover procedure. I believe Avi raised this point in his review.
We'd appreciate
comments on this, we plan on incorporating this into the next version of the
draft.
thanks,
John
1) Change the second and third paragraphs in section 4.1.4 Failure Procedures
FROM
If a communication failure occurs during an ongoing credit-control session the
credit-control client can move the credit control message stream to an
alternative server if the value of the CC-Session-Failover AVP is set to
FAILOVER SUPPORTED. A secondary Credit control server name received for instance
from the AAA server, can be used as an address of the backup server. If the
CC-Session-Failover AVP is set to FAILOVER_NOT SUPPORTED the credit control
message stream MUST NOT be moved to backup server and the credit control client
will terminate or continue the service depending on the value set in the
Credit-Control-Failure-Handling AVP. The Credit-Control-Failure-Handling AVP MAY
be sent from the authorization server and in the Credit-Control-Answer from the
credit-control server. For new credit-control sessions, failover to an alternate
credit-control server SHOULD be performed, if possible.
The timer, Tx (as defined in section 10), is used in the credit-control client
to supervise the communication with the credit-control server.
TO
If a failure occurs during an ongoing credit-control session the credit-control
client may move the credit control message stream to an alternative server if
the value of the CC-Session-Failover AVP is set to FAILOVER SUPPORTED. A
secondary Credit control server name received for instance from the AAA server
or locally configured, can be used as an address of the backup server. If the
CC-Session-Failover AVP is set to FAILOVER_NOT SUPPORTED the credit control
message stream MUST NOT be moved to backup server.
For new credit control sessions, failover to an alternative credit-control
server SHOULD be performed if possible. For instance, if an implementation of
the credit control client can determine primary credit control server
unavailability it can establish the new credit control sessions with a possibly
available secondary credit control server.
The AAA client/agent is typically using only a single persistent transport
connection to the AAA agent or server, but it may have connections to multiple
AAA agents or servers and treat them as primary/secondary or balance load
between them. The AAA transport profile [AAATRANS] defines the application layer
watchdog algorithm that enables failover from a peer that has failed and is
controlled by the timer Twinit. The recommended default value for Twinit is 30
seconds. Since the AAA infrastructure is common to several different types of
AAA applications, tuning the timer Twinit to a lower value in order to satisfy
the requirements of real-time applications, such as the Diameter Credit Control
application, will certainly increase the probability of premature failover
significantly and potentially cause congestive collapse in heavy loaded
networks. For prepaid services, however, the end user expects an answer from the
network in a reasonable time, thus the Diameter credit control client shall
react faster than the underlaying base protocol. Therefore this specification
defines the timer Tx that is used by the credit-control client (as defined in
section 10) to supervise the communication with the credit-control server. When
the timer Tx elapses the credit-control client takes an action to the end user
according to the Credit-Control-Failure-Handling AVP. The
Credit-Control-Failure-Handling AVP MAY be sent from the authorization server
and in the Credit-Control-Answer from the credit-control server.
When Tx expires, the Diameter credit control client always terminates the
service if the Credit-Control-Failure-Handling (CCFH) AVP is set to the value
TERMINATE. The credit control session may be moved to an alternative server only
in case a protocol error DIAMETER_TOO_BUSY or DIAMETER_UNABLE_TO_DELIVER is
received before Tx expires, therefore, the value TERMINATE is not appropriate if
proper failover behavior is desired.
If the Credit-Control-Failure-Handling AVP is set to the value CONTINUE or
RETRY_AND_TERMINATE, the service will be granted to the end user upon the timer
Tx expires. An answer message with granted-units may arrive later on due to the
base protocol transport failover occurred in the path to the Credit Control
Server (Twinit default value is 3 times more than the Tx recommended value). The
credit control client SHOULD grant the service to the end user, start monitoring
the resource usage and wait for the possible late answer until the timeout of
the request (e.g. 120 seconds). If the request fails and the
CC-Session-Failover AVP is set to FAILOVER_NOT SUPPORTED, the credit control
client terminates or continues the service depending on the value set in the
CCFH and MUST free all the reserved resources for the credit control session.If
a protocol error DIAMETER_UNABLE_TO_DELIVER or DIAMETER_TOO_BUSY is received or
the request timeout and the CC-Session-Failover AVP is set to FAILOVER
SUPPORTED, the credit control client MAY send the request to a backup server if
possible. If the credit control client receives a successful answer from the
backup server, it continues the credit control session with such a server. If
also the re-transmitted request fails, the credit control client terminates or
continues the service depending on the value set in the CCFH and MUST free all
the reserved resources for the credit control session.
2) Add the following sentence at the end of section 4.1.4
In order to support the failover between credit control servers information
transfer about the credit control session and account state SHOULD take place
between the primary and the secondary credit control server. Implementations
supporting the credit control session failover MUST also ensure proper detection
of duplicate or out of sequence messages. The communication between the servers
is regarded as an implementation issue and is outside of the scope of this
specification.
3) Change the first and fourth paragraphs in section 4.2.5 Failure Procedures
FROM
Failover to an alternate credit-control server is allowed for one time event
since the server is not maintaining session states. There MAY exist protocol
transparent Diameter relays and redirect agents or Diameter credit-control
proxies between credit-control client and credit-control server. Failover may
occur at any point in the path between credit-control client and credit-control
server in the event that a transport failure is detected with a peer, as
described in [DIAMBASE].
If the requested action is DIRECT_DEBITING and the
Direct-Debiting-Failure-Handling AVP is set to TERMINATE_OR_BUFFER the
credit-control client SHOULD terminate the service if it can determine from the
result code or error code in the answer message that units have not been
debited. Otherwise the credit-control client SHOULD grant the service to the end
user and store the request in the credit-control application level non-volatile
storage. The credit-control client MUST mark these request messages as possible
duplicate by setting the T-flag in the command header as described in [DIAMBASE]
section 3. If the Direct-Debiting-Failure-Handling AVP is set to CONTINUE the
service SHOULD be granted even if credit-control messages can't be delivered. If
the timer Tx expires the credit-control client MUST continue the service and
eventually buffer the request according to the value of the
Direct-Debiting-Failure-Handling AVP.
TO
Failover to an alternative credit-control server is allowed for one time event
since the server is not maintaining session states, for instance, if the credit
control client receives a protocol error DIAMETER_UNABLE_TO_DELIVER or
DIAMETER_TOO_BUSY it can re-send the request to an alternative server if
possible. There MAY exist protocol transparent Diameter relays and redirect
agents or Diameter credit-control proxies between credit-control client and
credit-control server. Failover may occur at any point in the path between
credit-control client and credit-control server in the event that a transport
failure is detected with a peer, as described in [DIAMBASE].
If the requested action is DIRECT_DEBITING and the
Direct-Debiting-Failure-Handling AVP is set to TERMINATE_OR_BUFFER, the
credit-control client SHOULD terminate the service if it can determine,
eventually after a possible re-transmission attempt to an alternative credit
control server, from the result code or error code in the answer message that
units have not been debited. Otherwise the credit-control client SHOULD grant
the service to the end user and store the request in the credit-control
application level non-volatile storage (Note that re-sending the request at a
later time is not a guarantee that the service will be debited, since the user's
account may be empty at the time when the server successfully processes the
request). The credit-control client MUST mark these request messages as possible
duplicate by setting the T-flag in the command header as described in [DIAMBASE]
section 3. If the Direct-Debiting-Failure-Handling AVP is set to CONTINUE, the
service SHOULD be granted even if credit-control messages cannot be delivered
and messages are not buffered.
If the timer Tx expires the credit-control client MUST continue the service and
wait for a possible late answer. If the request timeout the credit control
client re-transmit the request (marked with T-flag) to a backup credit control
server if possible. In the event that also the re-transmitted request timeout or
a temporary error is received in answer to such a request, the credit control
client eventually buffers the request according to the value of the
Direct-Debiting-Failure-Handling AVP. If a failed answer is received for the
re-transmitted request, the credit control client free all the resources
reserved for the event message.
4) Change the 'Failure to send' definition in section 4.5
FROM
In the state table, the event 'Failure to send' means that the Diameter
credit-control client is unable to communicate with the desired destination
(i.e. the answer message is not received within the validity time of the
request). This could be due to the peer being down, or due to a physical link
failure in the path to/from the credit-control server.
TO
In the state table, the event 'Failure to send' means that the Diameter
credit-control client is unable to communicate with the desired destination or
with a possibly defined alternative destination in case failover procedure is
supported (e.g. the request timeout and the answer message is not received).
This could be due to the peer being down, or due to a physical link failure in
the path to/from the credit-control server.
5) Change the 'Temporary error' definition in section 4.5
FROM
The event 'Temporary error' means that the Diameter credit-control client
received a transient failure notification in the Credit-Control-Answer command
(i.e. the peer sending back a transient failure or temporary protocol error
notification DIAMETER_TOO_BUSY, or DIAMETER_LOOP_DETECTED in the Result-Code AVP).
TO
The event 'Temporary error' means that the Diameter credit-control client
received a protocol error notification DIAMETER_TOO_BUSY,
DIAMETER_UNABLE_TO_DELIVER or DIAMETER_LOOP_DETECTED in the Result-Code AVP of
the Credit-Control-Answer command. The above protocol error notification may be
ultimately received in answer to the re-transmitted request to a possibly
defined alternative destination if failover is supported.
6) Change the 'Failed answer' definition in section 4.5
FROM
The event 'Failed answer' means that the Diameter credit-control client received
non-transient failure (permanent failure) notification in the
Credit-Control-Answer command.
TO
The event 'Failed answer' means that the Diameter credit-control client received
non-transient failure (permanent failure) notification in the
Credit-Control-Answer command. The above permanent failure notification may be
ultimately received in answer to the re-transmitted request to a possibly
defined alternative destination if failover is supported.
7) Update the state machine in section 4.5 as follow
In the following state machine table the failover to a possibly secondary server
upon 'Temporary error' or 'Failure to send' is not explicitely described. Moving
an ongoing credit control message stream to an alternative server is, however,
possible if the CC-Session-Failover AVP is set to FAILOVER_SUPPORTED as
described in section 4.3.4.
Re-sending a credit control event to a an alternative server is supported
as described in section 4.2.5.
CLIENT, SESSION BASED for the first interrogation with CCR
State Event
Action New State
---------------------------------------------------------------
Idle Client or device requests
Send PendingI
access/service
CC initial
req.,
start Tx.
PendingI Successful CC initial
Stop Tx Open
answer
received
PendingI Failure to send, or
Grant Idle
temporary
error and
service to
credit-control fault
end user
handling
equal to CONTINUE
PendingI Failure to send, or
Terminate Idle
temporary
error and end
user's
credit-control fault service
handling
equal to TERMINATE
or equal to RETRY_AND_TERMINATE
PendingI Tx expired and credit
Terminate Idle
Control fault
handling end user's
equal to
TERMINATE service
PendingI Tx expired and credit-control Grant
PendingI
fault
handling equal to service to
CONTINUE or
equal to end user
RETRY_AND_TERMINATE
PendingI CC initial answer
Terminate Idle
received with
result code end user's
SERVICE_
DENIED or service
USER_UNKNOWN
PendingI CC initial answer
Grant Idle
received with
result code service
equal to
credit-control N/A to end user
PendingI Failed CC initial answer
Grant Idle
received and
credit-control Service to
fault
handling
end user
equal to
CONTINUE
PendingI Failed CC initial answer
Terminate Idle
received and
credit-control end user's
failure
handling equal to service
TERMINATE or
equal to
RETRY_AND_TERMINATE
PendingI User service terminated
Queue PendingI
termination
event
PendingI Change in rating condition Queue
PendingI
changed
rating
condition
event
CLIENT, SESSION BASED for intermediate and final interrogations
State Event
Action New State
---------------------------------------------------------------
Open Granted unit elapses
Send PendingU
and no final
unit
CC update
indication
received req.,
start Tx.
Open Granted unit elapses
Terminate PendingT
and final
unit indication end user's
received
service, send
CC termination
req.,
start Tx.
Open Change in rating condition
Send PendingU
in queue
CC update
req.,
Start Tx.
Open Service terminated in queue
Send PendingT
CC termination
req.,
start Tx
Open Change in rating condition
Send PendingU
or
Validity-Time elapses CC update
req.,
Start Tx.
Open User service terminated
Send PendingT
CC termination
req.,
start Tx
PendingU Successful CC update
Stop Tx Open
answer
received
PendingU Failure to send, or
Grant Idle
temporary
error and
service to
credit-control fault
end user
handling
equal to CONTINUE
PendingU Failure to send, or
Terminate Idle
temporary
error and end
user's
credit-control fault service
handling
equal to TERMINATE
or equal to RETRY_AND_TERMINATE
PendingU Tx expired and credit-control Terminate
Idle
fault
handling equal to end user's
TERMINATE
service
PendingU Tx expired and credit-control Grant
PendingU
fault
handling equal to service to
CONTINUE or
equal to end user.
RETRY_AND_TERMINATE
PendingU CC update answer
Terminate Idle
received with
result code end user's
SERVICE_DENIED service
PendingU CC update answer
Grant Idle
received with
result code service
equal to
credit-control N/A to end user
PendingU Failed CC update
Grant Idle
answer
received and credit service to
control fault
handling equal end user.
to CONTINUE
PendingU Failed CC update
Terminate Idle
answer
received and credit end user's
control fault
handling service
equal to
TERMINATE or
equal to RETRY_AND_TERMINATE
PendingU User service terminated
Queue PendingU
termination
event
PendingU Change in rating
Queue PendingU
condition
changed
rating
condition
event
PendingT Successful CC
Idle
termination
answer received
PendingT Tx expired
PendingT
PendingT Failure to send, or temporary
Idle
error or
failed answer
PendingT Change in rating condition
PendingT
CLIENT, EVENT BASED
State Event
Action New State
----------------------------------------------------------------
Idle Client or device requests
Send PendingE
a one-time
service
CC event
req.,
Start Tx.
Idle Request in storage
Send PendingB
stored
request
PendingE Successful CC event
Idle
answer
received
PendingE Failure to send, temporary
Indicate Idle
error or
failed CC event service
answer
received, or
error
Tx expired,
requested
action
GET_BALANCE or
PRICE_ENQUIRY
PendingE CC event answer
Terminate Idle
received with
result code end user's
SERVICE_DENIED or service
USER_UNKNOWN and Tx running
PendingE CC event answer
Grant Idle
received with
result code service
credit-control N/A, requested to end
action
DIRECT_DEBITING user
PendingE Failure to send, temporary Grant
Idle
error or
failed CC event service
answer
received, requested to end
action
DIRECT_DEBITING and user
fault
handling equal to
CONTINUE
PendingE Failed CC event
Terminate Idle
answer
received or temporary end user's
error, requested action
service
DIRECT_DEBITING and
fault
handling equal to
TERMINATE_OR_BUFFER and
Tx running
PendingE Tx expired, requested Grant
PendingE
action DIRECT_DEBITING service
to end
user
PendingE Failure to send, requested Store
Idle
action
DIRECT_DEBITING and request with
fault
handling equal to T-flag
TERMINATE_OR_BUFFER
PendingE Temporary error, requested Store
Idle
action
DIRECT_DEBITING and request
fault
handling equal to
TERMINATE_OR_BUFFER and
Tx expired
PendingE Failed answer or answer
Idle
received with result code
SERVICE DENIED or USER_UNKNOWN,
requested action
DIRECT_DEBITING and Tx expired
PendingE Failed CC event answer
Indicate Idle
received,
requested
service
action REFUND
error and
delete request
PendingE Failure to send or
Store Idle
Tx expired,
requested request
action REFUND
with T-flag
PendingE Temporary error
Store Idle
and requested
action request
REFUND
PendingB Successful CC answer
Delete Idle
received
request
PendingB Failed CC answer
Delete Idle
received
request
PendingB Failure to send or
Idle
temporary error
8) Change the description of the Tx timer in section 10
FROM
Tx timer
When real-time credit-control is required, the credit-control client contacts
the credit-control server before and during the service is provided to an end
user. Due to real-time nature of application the communication delays SHOULD be
minimized, e.g. to avoid too long service set up time experienced by the end
user. The Tx timer is introduced to control the waiting time in the client in
the PENDING state.
The recommended value is 10 seconds.
TO
Tx timer
When real-time credit-control is required, the credit-control client contacts
the credit-control server before and during the service is provided to an end
user. Due to real-time nature of application the communication delays SHOULD be
minimized, e.g. to avoid too long service set up time experienced by the end
user. The Tx timer is introduced to control the waiting time in the client in
the PENDING state. When the Tx timer elapses the credit-control client takes an
action to the end user according to the value of the
Credit-Control-Failure-Handling AVP or according to the value of the
Direct-Debiting-Failure-Handling AVP.
The recommended value is 10 seconds.
9) Change the section 5.10
FROM
The Credit-Control-Failure-Handling AVP (AVP Code TBD) is of type
Enumerated. The credit-control client uses information in this AVP
to
decide what to do if the sending of credit-control messages to the
credit-control server has been for instance temporarily prevented
due
to a network problem.
TERMINATE
0
When the Credit-Control-Failure-Handling AVP is set to TERMINATE
the
service MUST only be granted as long as there is a connection to
the
credit-control server. If the credit-control client does not
receive
any Credit-Control-Answer message within the Tx timer (as defined
in
section 10) the credit-control request is regarded failed. The
moving
of already started credit-control session to alternative server is
not allowed.
This is the default behavior if the AVP isn't included in the reply
from the authorization or credit-control server.
CONTINUE
1
When the Credit-Control-Failure-Handling AVP is set to CONTINUE the
service SHOULD be granted even if credit-control messages can't be
delivered.
TO
The Credit-Control-Failure-Handling AVP (AVP Code TBD) is of type
Enumerated. The credit-control client uses information in this AVP
to
decide what to do if the sending of credit-control messages to the
credit-control server has been for instance temporarily prevented
due
to a network problem. Depending on the service logic, the
credit-control server can order the client to terminate the service
immediately when there is a reason to believe that the service
cannot
be charged, or to try failover to an alternative server, if
possible,
and then either terminate or grant the service should also the
alternative connection fail.
TERMINATE
0
When the Credit-Control-Failure-Handling AVP is set to TERMINATE
the
service MUST only be granted as long as there is a connection to
the
credit-control server. If the credit-control client does not
receive
any Credit-Control-Answer message within the Tx timer (as defined
in
section 10) the credit-control request is regarded failed and the
end
user's service session is terminated.
This is the default behavior if the AVP isn't included in the reply
from the authorization or credit-control server.
CONTINUE
1
When the Credit-Control-Failure-Handling AVP is set to CONTINUE the
credit-control client SHOULD re-send the request to an alternative
server in case of transport or temporary failures, provided that
failover procedure is supported in the credit-control server
and the credit-control client, and an alternative server is
available.
Otherwise, the service SHOULD be granted even if credit-control
messages can't be delivered.
RETRY_AND_TERMINATE
2
When the Credit-Control-Failure-Handling AVP is set to
RETRY_AND_TERMINATE the credit-control client SHOULD re-send the
request to an alternative server in case of transport or temporary
failures, provided that failover procedure is supported in the
credit-control server and the credit-control client, and an
alternative server is available. Otherwise, the service SHOULD not
be granted when the credit-control messages can't be delivered.
Proposed Resolution: Accept
Issue 442: Cost-Information AVP enhancement
Submitter name: Harri Hakala
Submitter email address: harri.hakala@ericsson.com
Date first submitted: September 17, 2003
Reference:
http://www.merit.edu/mail.archives/aaa-wg/2003-09/msg00020.html
Document: Diameter CCA-00
Comment type: T
Priority: 2
Section: 5.8
Rationale/Explanation of issue:
In Diameter CCA-00 the Cost-Information AVP can be used to return
accumulated cost for session (always type of money) without taking
a credit-reservation into account, that is it specifies how much
the service has cost so far.
In case of service price enquiry operation (e.g. for Advice Of Charge) the
cost should often be returned as a cost rate (e.g. cost for the service is
1$/minutes) instead of money. With the current Cost-Information AVP structure
cost per unit cannot be returned.
Proposed changed:
Section 5.8 Cost-Information AVP
FROM:
The Cost-Information AVP (AVP Code TBD) is of type Grouped and is
used to return the cost information of a service in the Accounting-
Answer command. The included Unit-Value AVP contains the cost
estimate (always type of money) of the service in case of price
enquiry or the accumulated cost estimation in the case of credit
control session.
The Currency-Code specifies in which currency the cost was given.
......
TO:
The Cost-Information AVP (AVP Code TBD) is of type Grouped and is
used to return the cost information of a service in the Accounting-
Answer command. The included Unit-Value AVP contains the cost
estimate (always type of money) of the service in case of price
enquiry or the accumulated cost estimation in the case of credit
control session.
The Currency-Code specifies in which currency the cost was given.
The Cost-Unit specifies the unit when the service cost is a
cost per unit (e.g. cost for the service is 1$/minute).
.....
CHANGE the AVP format in section 5.8
FROM
<Cost-Information>::=< AVP Header: TBD >
{ Unit-Value }
{ Currency-Code }
TO
<Cost-Information>::=< AVP Header: TBD >
{ Unit-Value }
{ Currency-Code }
[ Cost-Unit ]
ADD 5.x Cost-Unit AVP
5.x Cost-Unit AVP
The Cost-Unit AVP (AVP Code TBD) is of type UTF8String
and specifies the applicable unit to the Cost-Information
when the service cost is a cost per unit (e.g. cost of
the service is 1$/minute). The Cost-Unit can be for
instance minute, hour, day, KBytes, MBytes etc.
Proposed Resolution: Accept
Issue 443: Missing CCA flows
Submitter name: Harri Hakala
Submitter email address: harri.hakala@ericsson.com
Date first submitted: September 17, 2003
Reference:
http://www.merit.edu/mail.archives/aaa-wg/2003-08/msg00024.html
Document: Diameter CCA-00
Comment type: T
Priority: S
Section: Appendix A
Rationale/Explanation of issue:
In the issue 407, Credit Control Review, we were advised
to provide some message diagrams explaining the protocol
usage. In the current CCA draft (draft-ietf-aaa-diameter-cc-00)
we have described some message flows in Appendix A, Credit
Control sequences.
However, the example flows for the refund and price enquiry cases
were not included in the above version. To close this part of the
issue, we have prepared some additional message flows to clarify
these cases.
Flows are available here,
Price Enquiry:
http://standards.ericsson.net/harri/Price_enquiry.txt
Refund:
http://standards.ericsson.net/harri/Refund.txt
All comments and suggestions are most welcome.
Proposed Resolution: Accept
Issue 444: Graceful Service Termination
Submitter name: Marco Stura
Submitter email address: marco.stura@nokia.com
Date first submitted: October 15, 2003
Reference:
http://www.merit.edu/mail.archives/aaa-wg/2003-08/msg00016.html
Document: draft-ietf-aaa-diameter-cc-00
Comment type: T
Priority: S
Section: various
Rationale/Explanation of issue:
I just noticed that we have an issue for the GST proposal.
Actually the GST proposal is to address the below comment
within the issue 408 raised by Avi Lior.
"Redirect
In many instances in the text the action to take when a user resources
are no longer available is to terminate the session. That is one
possible action, the other possible action is to restrict access (or
direct the user) to a portal where they can recharge their account
etc..."
Should we really have issue 419 or perhaps Avi's (and others) could
review the GST proposal to check if the comment within issue 408 is
properly addressed?
Proposed Resolution: Discuss
Issue 445: Key Compromise
Submitter name: Radia Perlman
Submitter email address: radia.perlman@sun.com
Date first submitted: November 13, 2003
Reference:
http://www.merit.edu/mail.archives/aaa-wg/msg00026.html
Document: draft-ietf-aaa-diameter-mobileip-15.txt
Comment type: T
Priority: S
Section: various
Rationale/Explanation of issue:
The document is incomprehensible. To my amazement, after reading it n times,
I was starting to understand some of it, and found some fishy things. I
tracked down the 1st author (Pat Calhoun), and it was somewhat distressing
that he also did not understand the document.
Basically, the AAA guys have gone off and invented all sorts of things, and
security people haven't been paying attention because nobody wanted to wade
through all the muck of new terminology and badly written documents.
From my current understanding, the purpose of this document is to allow a
Sprint customer to roam into MCI territory and have MCI be able to bill
Sprint for the usage.
There are a bunch of access points, that don't have user information (like
Radius), but there is a AAA database at Sprint, and at MCI, etc. When a user
connects to an access point, the access point gets the user's information
from the AAA database. The AAA server acts like the KDC in Kerberos, and
invents a session key to give to the access point and the user. This is
according to Pat, who I caught in the hall. The document implies that
instead of a Kerberos-like protocol where the session key is encrypted in a
KDC-endpoint shared secret, the keys are sent over TLS sessions. So in the
case of inter-realm, the intermediaries would see the keys. When I pointed
out that the document did not imply it worked the way Pat said he didn't know
why the document said that...that it was a long time since he saw the document,
and I should instead try to talk to the 2nd author.
[Pete McCann] The topic of Kerberos has come up before in the development of
AAA,
and it wasn't pursued. I think the main problem with Kerberos is the
un-scalability of distributing all the required secret keys in an
inter-realm environment. I know there has been some work on
inter-realm authentication in Kerberos, but it requires all pairs of
realms to configure secret keys, and/or for the client to get a whole
sequence of tickets starting from the home realm and ending with a
ticket for the visited realm.
Instead, the current draft (I hope you were reading draft-15, which
was submitted just before the cut-off, and not some prior version)
allows the visited realm (in fact, the FA within the visited realm) to
open a TLS connection to the home realm, where the endpoints of this
connection are authenticated using server/client certificates. Then,
the AMR message is sent through this TLS connection. The AMR message
contains a copy of the Mobile IP Registration Request, which contains
its own authentication extension, and includes replay protection based
on a Challenge from the visited realm and a timestamp/nonce from the
home realm. By verifying the Registration Request, the home network
can prove that the visited realm at least did receive a valid, recent
Mobile IP Registration Request and can authorize the session. The
secret key (for use in the MN-FA mobility security association) is
then sent through the TLS connection in the AMA message. In this way
it is not visible to any intermediaries.
A similar procedure is used for communicating a secret key to the home
agent, when it is dynamically allocated in the home or visited network.
I hope this helps you to understand some of the security properties of
the Diameter Mobile IP application. As for the clarity of the
document, could you be a bit more specific on what you found to be
confusing? Perhaps we can do a few more edits before submitting it.
[Bernard Aboba] Use of Kerberos was examined for use in Mobile
applications (such as in IEEE 802.11i where it was initially
mandatory-to-implement), but was not pursued due to the following
limitations:
a. Extensibility. In order to allow services to be provisioned, the PACS
field in the Kerberos ticket would need to be extended to support AAA
attributes used today for service definition. My understanding is that
there is little enthusiasm for such extensions in Kerberos WG.
b. IP specificity. Kerberos tickets are bound to an IP address. This
is problematic in mobility applications where the Care-of-Address may
change frequently. Binding the ticket to the Home Address introduces
a chicken-egg problem if the intent is to use Kerberos to secure the
MIPv4 Registration or MIPv6 Binding Update itself.
c. Fast Handoff. In mobile applications, elements such as NAS
devices, Foreign Agents, etc. cannot share the same keys with
the KDC in order to avoid cascading vulnerabilities. This implies
that Kerberos tickets need to be obtained to each point of attachment
individually. However, in order to enable fast handoff, it's necessary
to avoid round-trips all the way from the mobile node to the KDC,
particularly in cross-realm situations where multiple conversations
could be required. In order to address this issue, substantial
changes to Kerberos would be required in order to enable the Mobile
Node to obtain multiple tickets in a single transaction. This
would represent a major change to RFC 1510.
d. Ticket size. Due to ASN.1 encoding Kerberos tickets are fairly
large objects and when integrated with existing mobility protocols,
are likely to result in fragmentation.
e. Dictionary attack vulnerabilities. As described in the paper
below, Kerberos is vulnerable to online dictionary attacks:
http://www.isoc.org/isoc/conferences/ndss/99/proceedings/papers/wu.pdf
This vulnerability, while potentially hard to exploit on a wired
network, is very easy to exploit on a wireless network where a
passive eavesdropper can gain access to the wireless medium.
This implies that Kerberos, unless used with PKINIT, is
insecure for use in wireless authentication.
Proposed Resolution: Discuss
Issue 446: Diameter EAP comments
Submitter name: Julien Bournelle
Submitter email address:
Julien.Bournelle@int-evry.fr
Date first submitted: December 13, 2003
Reference:
http://www.merit.edu/mail.archives/aaa-wg/msg00013.html
Document: EAP-03
Comment type: T
Priority: S
Section: 2.2, 2.8.1
Rationale/Explanation of issue:
Hi,
I've just read the diameter-eap draft and I have some minor comments:
-1- in §2.2 s/respons/respond
-2- In the second scenario described in §2.2, the NAS sends the DER
message directly to the home server. Why do not send it to its local
Diameter Server ?
-3- In the same paragraph, it is said that the DEA may include an
EAP-MSK-Key AVP that contains keying material for protecting the
communication between the user and the NAS. In the roaming scenario, it
would be the home server which will provide this key. So what happen if
the NAS do not want to use this key ?
-4- In §2.8.1, I just wanted to note that we are going to face problem
if we use an EAP method with identity protection in roaming
scenario.(NAS won't be able to route Request)
[Jari Arkko]
-1- in §2.2 s/respons/respond -2- In the second scenario described in §2.2, the NAS sends the DER message directly to the home server. Why do not send it to its local Diameter Server ?
Section 2.2 does not discuss the possibility of local proxies yet. This is handled in Section 2.3, which has a number of different scenarios, including scenario 2 where redirects are used to run the EAP AAA end-to-end between the NAS and the home server, and scenario 4 which is the typical RADIUS-like proxy model.
-3- In the same paragraph, it is said that the DEA may include an EAP-MSK-Key AVP that contains keying material for protecting the communication between the user and the NAS. In the roaming scenario, it would be the home server which will provide this key. So what happen if the NAS do not want to use this key ?
This is ultimately a link-layer dependent issue. Home servers would typically provide the keying material, but depending on the link layer in question, the NAS would use the keying material in different ways. Presumably there can be cases where the keying material is not used at all. I would say in this case the NAS simply throws the AVP away. Do you see an issue here?
-4- In §2.8.1, I just wanted to note that we are going to face problem if we use an EAP method with identity protection in roaming scenario.(NAS won't be able to route Request)
Yes. Note that if only the user name part, not the domain, is hidden, then there is no issue. Some EAP methods use this kind of identity protection. This is discussed in RFC 2284bis. If one wants even domain identity protection over the wireless, then there has to be (a) some sort of a tunnel EAP method -- with implied consequences -- that is terminated at the NAS or (b) some new link layers that could protect even the initial stages of EAP negotiation. But you can't have domain identity protection from the NAS, otherwise roaming doesn't work. You could perhaps use <encrypted_NAI>@anonymizer.com, but even then you would reveal your domain to someone else than your home network. Also, link-layer and tunnel-based identity protection mechanisms would likely be just authenticate the NAS/AP end with a certificate but not the client end. Such schemes would then still be vulnerable to identity protection attacks from insiders, e.g., everyone who has a cert from the trusted CA could trick you to reveal your identity. Some of these issues should probably go into 2.8.1. I looked at RFC 3579 too, but it did not say much about the issue. Perhaps a reference to RFC2284bis Section 7.3 would be sufficient.
[Bernard Aboba]
I would say there are two orthogonal issues: how the key is delivered, and whether the AAA server is requesting that security services be provided. The keying AVPs only address the first issue; if security is required, this needs to be encoded separately (as it is in the RFC 2548 attrbutes). For example, the key could be provided, and the AAA server could be indifferent to whether it is used or not. Or it could *require* that it be used. The difference between these two cases is particularly important in fast handoff or context transfer, where you don't necessarily want a host to move from an access point that supports security to one that does not. > If one wants even domain identity protection over the wireless, > then there has to be (a) some sort of a tunnel EAP method -- with > implied consequences Not necessarily. Identity protection can be provided within a method without allowing any arbitrary EAP method to be executed inside of it.
[Jari Arkko] I think you mean that the username part can be hidden by methods. I'm not sure the domain name part can be hidden by methods, unless the method does tunneling of some sort. We have the following constraints: o To get to the right home server, we need the domain o The domain can not be exposed on the wireless interface So lets assume its an EAP method that provides the domain identity protection. Since the domain is hidden over wireless, and needs to be known for AAA routing, there has to be a node that does the translation. Assuming that the selection of the EAP method is transparent to everyone else except the client and the home server, it does not seem possible to terminate a domain-hiding EAP method at some intermediate node -- unless that method did some sort of general tunneling where the terminated part did not know what was going on inside. But I could be missing something.
[Julien Bournelle] > Section 2.2 does not discuss the possibility of local proxies yet. > This is handled in Section 2.3, which has a number of different > scenarios, including scenario 2 where redirects are used to > run the EAP AAA end-to-end between the NAS and the home server, and > scenario 4 which is the typical RADIUS-like proxy model. that's right but in Diameter-Mobile-IPv4, the FA (<=> NAS) sends requests to its local Diameter Server (AAAF). Here, the NAS can send requests to: - redirect agent - proxy agent - to the home server so it appears that there is a different approach between the two drafts. > This is ultimately a link-layer dependent issue. Home servers would > typically > provide the keying material, but depending on the link layer in question, > the NAS would use the keying material in different ways. Presumably > there can be cases where the keying material is not used at all. I would > say in this case the NAS simply throws the AVP away. > > Do you see an issue here? The home server may "think" that it exists a "protection" between its client and the local NAS but I'm not sure that is an issue. > >-4- In §2.8.1, I just wanted to note that we are going to face problem > >if we use an EAP method with identity protection in roaming > >scenario.(NAS won't be able to route Request) > > Yes. Note that if only the user name part, not the domain, is hidden, > then there is no issue. Some EAP methods use this kind of identity > protection. This is discussed in RFC 2284bis. ok I didn't know (thanks)
[Jari Arkko]
Hi, On Sat, Dec 13, 2003 at 11:00:14AM +0200, Jari Arkko wrote:-2- In the second scenario described in §2.2, the NAS sends the DER message directly to the home server. Why do not send it to its local Diameter Server ?Section 2.2 does not discuss the possibility of local proxies yet. This is handled in Section 2.3, which has a number of different scenarios, including scenario 2 where redirects are used to run the EAP AAA end-to-end between the NAS and the home server, and scenario 4 which is the typical RADIUS-like proxy model.
that's right but in Diameter-Mobile-IPv4, the FA (<=> NAS) sends
requests to its local Diameter Server (AAAF). Here, the NAS can send
requests to:
- redirect agent
- proxy agent
- to the home server
so it appears that there is a different approach between the two drafts.
Perhaps -- though from the point of view of protocols, the NAS will be sending a message to the local diameter entity. Its then up to that entity whether it responds with a redirect, proxies the request, or handles it by itself. Do you see an issue here?
This is ultimately a link-layer dependent issue. Home servers would typically
provide the keying material, but depending on the link layer in question,
the NAS would use the keying material in different ways. Presumably
there can be cases where the keying material is not used at all. I would
say in this case the NAS simply throws the AVP away.
Do you see an issue here?
The home server may "think" that it exists a "protection" between its
client and the local NAS but I'm not sure that is an issue.
Based on what Bernard said, this may be an issue if there is an expectation that security is provided where it is really not. It is not certain, however, that this is a specific issue for Diameter EAP -- it seems that the same problem appears for most of the authorization AVPs. Maybe 'M' bit would help.
Proposed Resolution: Discuss
Issue 447: Missing ABNFs in NASREQ
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: January 8, 2004
Reference:
http://www.merit.edu/mail.archives/aaa-wg/msg00068.html
Document: NASREQ-13
Comment type: T
Priority: S
Section: various
Rationale/Explanation of issue:
In reading the NASREQ draft and Diameter Base again, I've concluded that NASREQ is missing a section or two detailing the ABNFs for use of NASREQ with several commands defined in Diameter Base: Session-Termination-Request/Answer Re-Auth-Request/Answer While the ABNF of these commands is defined in Diameter Base, there is no provision for inclusion of AVPs defined in NASREQ within these commands, because the AVPs are defined in NASREQ, not Diameter Base. Nevertheless, use of NASREQ AVPs in these commands seems useful/likely, but NASREQ doesn't describe what is legal and what isn't. For example, it might be reasonable to specify which session to terminate or re-authorize based on the Calling-Station-Id. I *think* that this involves merely allowing additional of optional AVPs to the commands, so that use of a different applicationID or command isn't required. But there could be a bigger problem.
Proposed Resolution: Discuss
Issue 448: Diameter EAP editorial comments
Submitter name: Glen Zorn
Submitter email address: gwz@cisco.com
Date first submitted: 10 Jan 2004
Reference:
http://www.merit.edu/mail.archives/aaa-wg/msg00076.html
Document: eap-03
Comment type: E
Priority: S
Section: 1, 2.2
Rationale/Explanation of issue:
In Section 1, paragraph 5 there are missing articles:
Change "Diameter EAP application relies heavily on [NASREQ],"
to:
"The Diameter EAP application relies heavily on [NASREQ],"
Change "Diameter EAP application defines new Command-Codes and new AVPs,"
to:
"The Diameter EAP application defines new Command-Codes and new AVPs,"
In Section 2.2, I question whether 802.1x qualifies as a link-layer.
remove "or IEEE 802.1X [IEEE-802.1X]" from sentence 1, paragraph 1.
In Section 2.2, Sentence 2 of paragraph 2 seems to be incomplete.
Change to: "The Result-Code AVP in the message will be set to DIAMETER_MULTI_ROUND_AUTH, signifying that a subsequent request is expected."
Proposed Resolution: Accept
Issue 449: Miscellaneous NASREQ edits
Submitter name: David Mitton
Submitter email address: david@mitton.com
Date first submitted: February 16, 2004
Reference:
http://www.merit.edu/mail.archives/aaa-wg/msg00239.html
Document: NASREQ-13
Comment type: T
Priority: S
Section: various
Rationale/Explanation of issue:
Edits to draft 14 Diameter-Nasreq
2/15/2004
Document Editor: David Mitton
Pre-publication copy availible at:
http://www.circularnetworks.com/draft-ietf-aaa-diameter-nasreq-14.txt
Inputs:
- IESG Review comments
- WG Issue #430
- WG email wrt RADIUS Dyn Auth errors (12-Nov-2003, Yoon-Young Lee)
- errors found while editing
---
Changes made:
1.1 Terminology
- remove CMS
- Add references for: LAT, ARAP, IPX, PAP
2.2 Session Re-Auth
- Clarify Re-Auth Timeout and sequence.
- Clarify that a server Re-Auth request always results in a NAS directed
AAR/AAA sequence. Remove one sentence that described an Authorization
update.
3.0 Messages
- Added ABNF sections (3.3-3.10) for all Base messages used.
Text primarily copied from Base, some definition details omitted,
and NAS specific terminology subsituted for abstract in Base.
5.x, 6.12, 6.13 AppleTalk, ARAP
- Numerous typos, object clarifications,
- references added
6.11 IPX
- Reference added.
6.15.2-.6 LAT [error in draft 14 should be 6.16.x]
- Reference added
- fix refs to Service-Type, should be Login-Service-Type
7.5 Tunneling
- fix Server-Endpoint text error. RFC 2868 said "client" where server
was meant.
8. Accounting
- grammarical error
- assigned Accouting-Auth-Method AVP code 406
9. RADIUS/Diameter Interactions
- Rewrote 9.1.1, 9.2.1 to fix errors in Diameter messages and abiguities
of behaviors.
10.2.x Acounting AVP Occurence tables
Problems found while reconciling RADIUS with ABNF
- Base session identifing AVPs were added
- several minor fixes to occurences, e.g.:
Accounting-Realtime-Required, Acct-Interim-Interval, ACA returns.
12. Security
- Added sentence:
Use of this application of Diameter MUST take into consideration the
security issues and requirements of the Base protocol.
13. References:
- Update transport to RFC, other updates
- Update UTF-8
- Add AppleTalk, ARAP, IPX, LAT, PAP
- Move ISO-LATIN reference to informative
---
Outstanding issues and errata:
- WG Issue #431 outstanding
- Error in header level for 6.16 LAT Services
- David Spence contact info out-of-date
Document should be progressed.
If no further followup on issue #431, then drop it.
Proposed Resolution: Discuss
Issue 450: Comments on EAP-04
Submitter name: Jari Arkko
Submitter email address: jari.arkko@piuha.net
Date first submitted: February 17, 2004
Reference:
http://www.merit.edu/mail.archives/aaa-wg/msg00242.html
Document: EAP-04
Comment type: T
Priority: S
Section: various
Rationale/Explanation of issue:
- Section 2.3 beginning: do we need the note anymore? It seems that
the flows have been discussed in at least one WG meeting, and have
lived through a couple of versions...
- In Section 2.3.3, change
The NASREQ application is used here for authorization because the
realm-specific routing table does support routing based on
application, but not more...TO BE CLARIFIED.
to
The NASREQ application is used here for authorization because the
realm-specific routing table supports routing based on application,
but not on Diameter commands.
- Section 2.8.5 may be in conflict with EAP channel bindings. Perhaps
you should recommend that the diameter server at least sends all
AVPs to the backend auth server.
- AVP occurrence table in 5.1 is missing EAP-Reissued-Payload
and EAP-Master-Session-Key AVPs. The correct occurrence counters
for these are:
Attribute Name
| DER | DEA |
------------------------------------|-------+-------|
EAP-Reissued-Payload
| 0 | 0-1 |
EAP-Master-Session-Key
| 0 | 0-1 |
- In Section 3.2, s/2. the/2. The/
- s/can't/cannot/g
Proposed Resolution: Discuss
Issue 451: Interim vs. STOP Record
Submitter name: Avi Lior
Submitter email address: avi@bridgewatersystems.com
Date first submitted: February 19, 2004
Reference:
http://www.merit.edu/mail.archives/aaa-wg/msg00247.html
Document: NASREQ-14
Comment type: T
Priority: S
Section: 2.2, 9.1
Rationale/Explanation of issue:
According to NASREQ-14 every change in authentication or authorization
MUST generate an Accounting-Record-Type of INTERIM_RECORD.
Requested changes:
I belive that changes caused by re-authentication or authorization
should cause a new session to begin and therefor a STOP_RECORD followed
by a START_RECORD MUST be generated.
Besides INTERIM_RECORDS may be disabled. So if the text stands then at
least state that accounting interim would be sent regardless of whether
the server has enabled interims or not.
Also, in Section 9.1:
Requested changes:
Change:
I guess the safest bet is to translate it to Session-Timeout
value (with value from Authorization-Lifetime AVP, the smaller
one) and Termination-Action set to AA-REQUEST. (And remove
Authorization-Lifetime and Re-Auth-Request-Type)
Change To:
The safest bet is to translate it to Session-Timeout
value (with value from Authorization-Lifetime AVP, the smaller
one) and Termination-Action set to AA-REQUEST. (And remove
Authorization-Lifetime and Re-Auth-Request-Type)
Proposed Resolution: Discuss
Issue 452: Accounting-Session-Id in ACA command
Submitter name: Avi Lior
Submitter email address: avi@bridgewatersystems.com
Date first submitted: February 19, 2004
Reference:
http://www.merit.edu/mail.archives/aaa-wg/msg00251.html
Document: NASREQ-14
Comment type: T
Priority: S
Section: 3.10
Rationale/Explanation of issue:
[ Accounting-Session-Id ] appears in Accounting-Answer (ACA) Command
Requested changes:
This probably should be changed to [Acct-Session-Id].
Proposed Resolution: Discuss
Issue 453: Problem with Accounting-Session-Id and
Session-Id
Submitter name: Avi Lior
Submitter email address: avi@bridgewatersystems.com
Date first submitted: February 19, 2004
Reference:
http://www.merit.edu/mail.archives/aaa-wg/msg00252.html
Document: NASREQ-14
Comment type: T
Priority: S
Section: 3.10
Rationale/Explanation of issue:
When the corresponding response is received by the Translation Agent, it
says that Acct-Session-Id attribute is to be placed in Session-Id.
The problem is that Acct-Session-Id will always change when there are
multiple session in RADIUS. In diameter Session-Id remains constant and
therefore placing it in
Session-Id will violate Diameter.
What really needs to happen is much more complex.
Requested changes:
Acct-Session-Id attribute should be placed in Accounting-Sub-Session-Id AVP.
The Translation Agent should be the one generating a Session-Id for the
session and its sub-sessions.
It will place Session-Id in the diameter messages.
Proposed Resolution: Discuss
Issue 454: Diameter NASREQ Conflict with Base
Submitter name: Bernard Aboba
Submitter email address: aboba@niternaut.com
Date first submitted: February 19, 2004
Reference:
http://www.merit.edu/mail.archives/aaa-wg/msg00090.html
Document: NASREQ-13
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:
As Casey Stengel said "I've made up my mind, but I made it up both ways." NASREQ contradicts Base (and RFC 3576) on the use of RAR/RAA. Personally, my vote is with Base.
> >Since we wrote the "authorize only" stuff in for Diameter compatibility, > >I'm OK with removing it. However, I'm still not clear that Diameter Base > >allows the single transaction model for Reauthorization. > > Okay, I think you're on to something. I've re-read the Base. RAR really > doesn't say much, but RAA says: > "A successful RAA message MUST be followed by an application-specific > authentication and/or authorization message." Yes. My understanding was that the intent was initiate a Request/Response sequence. > However, I find DiamNasReq section 2.2 para 3 already says: > If the Re-Auth-Request-Type is AUTHORIZE_ONLY, the > message will contain AVPs to modify the current service. This seems like a fundamental change in the usage of RAR/RAA, compared to what is defined in the Base protocol. > Sooo... I think we (in the more expansive WG sense) have been here before. > Either we extend RAR/RAA explicitly to cover this (which seems to be what > was done, perhaps weakly and obscurely), or we make the extra message > exchange something that the Diameter/RADIUS gateway has to provide. The original discussion on RFC 3576 assumed that an extra exchange was required to accomodate Diameter RAR/RAA behavior. Reading Base, that assumption seems to have be justified. So unless Base was in error, RFC 3576 is correct in this instance, the Diameter/RADIUS gateway needs to accomodate the extra exchange, and NASREQ needs to be compatible with the operation of RAR/RAA defined in Base. > summing up: I am in favor of killing the extra exchange on > Disconnect-Request and declaring it a bug in RFC 3576. This makes sense because ASR/ASA in Diameter is a single transaction, so I think that NASREQ is correct here, and RFC 3576 is wrong. > I'm in favor of this one step RAR message, but perhaps we should test that. > The text in 2.2 should be beefed up a bit... which segues in to the next > topic.... Unless the one-step RAR message is defined in Base, I don't think that NASREQ can change the nature of the Base RAR/RAA exchange this way. Also, RFC 3576 describes why a one-step RAR message is problematic. The issue is semantic ambiguity -- is a given AVP used for session identification or authorization change? The two-step exchange is cleaner in that respect. > More ABNFs? > Do we want to "describe" all NAS applications usage of Base messages with > an ABNF? > This would include: Re-Auth;RAR/RAA, Session-Termination;STR/STA, > Session-Abort; ASR/ASA, Accounting;ACR/ACA Adds up real quick. > > I don't think it's real hard to write, but it will add several pages of text. > > Final summary: > With my "Protocol Architect" hat on, I like the completeness and > clarity this would add. I agree. Frankly, the confusion over usage of RAR/RAA and other commands is likely to become a stumbling block if we don't fix this now. > I'll work issue 431 until I'm ready to commit on this one. Let's see what other members of the AAA WG have to say on this one.
[Marco Stura]
> This seems like a fundamental change in the usage of RAR/RAA, > compared to > what is defined in the Base protocol. Yes, I'm of the same opinion. The RAR/RAA in Base protocol is designed to initiate an application specific Request/Answer sequence. > > Sooo... I think we (in the more expansive WG sense) have > been here before. > > As Casey Stengel said "I've made up my mind, but I made it up > both ways." > NASREQ & Base seem to be in contradiction on the use of RAR/RAA. > Personally, my vote is with Base. I'm in support of the base as well.
Proposed Resolution: Discuss
Issue 455: User-name handling
Submitter name: Joe Salowey
Submitter email address: jsalowey@cisco.com
Date first submitted: 3/3/2004
Reference:
http://www.merit.edu/mail.archives/aaa-wg/msg00313.html
Document: eap
Comment type: 'E'ditorial
Priority: '1' Should fix
Section: 2.8.1
Rationale/Explanation of issue:
The draft says "...the Diameter server SHOULD return the user's identity
by inserting it in the User-Name AVP of susequent Diameter-EAP-Answer
packets." It is not clear which user identity this is referring to.
If
it is referring to the user's real identity this is only available once
the EAP method completes. It probably should state:
"...the Diameter Server SHOULD return the real user's identity by
inserting it in the User-Name AVP of Diameter-EAP-Answer packets that
contain a Result-Code of DIAMETER-SUCCESS."
It might also be good to discuss that the real user-name MAY be omitted
or replaced with a different billing identifier if identity privacy is
required in the DIAMETER channel.
[Pasi Eronen] Does this look ok?
Replace in Section 2.8.1
"Therefore, the Diameter Server SHOULD return the user's
identity by inserting it in the User-Name AVP of subsequent
Diameter-EAP-Answer packets. Without the user's identity,
the Session-Id AVP MAY be used for accounting and billing,
however operationally this could be very difficult to manage."
by
"Therefore, the Diameter Server SHOULD return the user's
identity by inserting a User-Name AVP to Diameter-EAP-Answer
messages that have a Result-Code of DIAMETER_SUCCESS. A
separate billing identifier or pseudonym MAY be used for
privacy reasons (see Section 8.5). If the user's identity is
not available to the NAS, the Session-Id AVP MAY be used for
accounting and billing; however operationally this could be
very difficult to manage."
[Joe Salowey] Looks good.
Proposed Resolution: Accept
Issue 456: Error in Diameter Base
Submitter name: Stefan Goeman
Submitter email address:
Stefan.Goeman@siemens.com
Date first submitted: 3/3/2004
Reference:
http://www.merit.edu/mail.archives/aaa-wg/msg00298.html
Document: RFC 3588
Comment type: T
Priority: S
Section: 6.1.8
Rationale/Explanation of issue:
I believe there is an error in the Diameter Base Protocol RFC. I refer to Figure 6 in section 6.1.8 Relaying and Proxying Requests.
First of all, there is a small typo with the mno.net and example.net things, but this is not the real problem I have.
The text in section 6.1.8 says that "A relay of proxy agent MUST append a Route-Record AVP to all requests forwarded. The AVP contains the identity of the peer the request was received from." This is reflected in Figure 6. In Figure 6, (Origin-Host=nas.mno.net) and (Route-Record=nas.mno.net) (Remember my first remark on the typo).
However, when I read the text in section 6.7.1 Route-Record AVP, I read "The Route-Record AVP is of type DiameterIdentity. The identity added in this AVP MUST be the same as the one received in the Origin-Host of the Capabilities Exchange message". Applying this to Figure 6, I assume that the CE message are between DRL and HMS. In these messages Origin-Host would be the identity of DRL. So, I think that in Figure 6 it should be (Origin-Host=nas.mno.net) and (Route-Record=drl.mno.net).
Proposed Resolution: Discuss
Issue 457: Editorial NIT in NASREQ-14
Submitter name: Johan Hermans
Submitter email address:
johan.rh.hermans@alcatel.be
Date first submitted: 3/3/2004
Reference:
http://www.merit.edu/mail.archives/aaa-wg/msg00255.html
Document: NASREQ-14
Comment type: E
Priority: 1
Section: 4.4
Rationale/Explanation of issue:
para 4.4 Nas-Port-Type
draft 13 contained the new values (22-25) which can be found in <http://www.iana.org/assignments/radius-types>
since September, but draft 14 skipped them again.
22 Wireless - CDMA2000 [McCann] 23 Wireless - UMTS [McCann]
24 Wireless - 1X-EV [McCann]
25 IAPP [IEEE 802.11f][Kerry]
Not so important, because the list is informational anyway.
Proposed Resolution: Discuss
Issue 458: Editorial Comment on EAP-04
Submitter name: Yoshihiro Ohba
Submitter email address:
yohba@tari.toshiba.com
Date first submitted: 2/29/2004
Reference:
http://www.merit.edu/mail.archives/aaa-wg/msg00292.html
Document: EAP-04
Comment type: E
Priority: 1
Section: 3.2
Rationale/Explanation of issue:
The following AVPs seem to be missing in the ABNF:
EAP-Reissued-Payload
EAP-Master-Session-Key
Accounting-EAP-Auth-Method
Please check.
Proposed Resolution: Discuss
Issue 459: IESG Review of Diameter MIP-16
Submitter name: Bert Wijnen
Submitter email address: bwijnen@lucent.com
Date first submitted: 2/23/2004
Reference:
http://www.merit.edu/mail.archives/aaa-wg/msg00256.html
Document: MIP-16
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:
AAA WG,
The IESG discussed this document on their telechat of Last Thursday.
Below are two DISCUSS concerns that need to be addressed or answered.
Beside this, Thomas Narten of the iESG has also had an email exchange with
authors. Basically he is OK with the doc, but he had some little things and
nits. If I understood the response from Tom correctly, then he has already
prepared fixes for those.
So I think that with one more (hopefully quick) respin we can get this one
approved.
Thanks,
Bert
----------------------------------------------------------------
DISCUSS:
========
Steve Bellovin (DISCUSS):
Nit: it speaks of xyz.com instead of example.com
2.2 says
Security considerations may require that the HAR
be sent directly
from the AAAH to the HA without the use of
intermediary Diameter
agents. This requires that a security association
between the AAAH
and HA be established, as in Figure 4.
If the HA is in the foreign network, how does AAAH get suitable information
to set up a secure session?
7: "the keys in this regime are symmetric in the sense they are
used in both directions" is a very bad idea.
----------------------------------------------------------------
Russ Housley (DISCUSS):
I am uncomfortable proceeding with this document without seeing [MIPKEYS]
too. The reference was difficult to track down. Once I finally found it, it
is in 'Publication Requested' state.
Proposed Resolution: Discuss
Issue 460: Key Name AVP
Submitter name: Joe Salowey
Submitter email address: jsalowey@cisco.com
Date first submitted: 3/3/2004
Reference:
Document: eap-04
Comment type: T
Priority: '1' Should fix
Section: 4.1
Rationale/Explanation of issue:
Since EAP keying has the concept of the key name this should probably be
returned along with the Master Key.
"4.1.5 EAP-Master-Session-Key-Name AVP
The EAP-Master-Session-Key-Name AVP (AVP Code TBD) is of type
OctetString. It contains the name used to identify the
EAP-Master-Session-Key. Exactly how this name is used depends upon the
link layer in question, and is beyond the scope of this document. This
AVP can optionally be present whenever an EAP-Master-Session-Key AVP is
present.
Since there currently are no standard RADIUS attribtues for key name
this attribute does not translate to or from RADIUS in a standard way."
Proposed Resolution: Discuss
Issue 461: Alternate Uses and Conflicting AVPs
Submitter name: Joe Salowey
Submitter email address: jsalowey@cisco.com
Date first submitted: 3/3/2004
Reference:
Document: eap
Comment type: E
Priority: '1' Should fix
Section: 2.8.2 and 2.8.5
Rationale/Explanation of issue:
Since EAP keying has the concept of the key name this should probably be
returned along with the Master Key.
It might be goos to provide some motivation behind the 2.8.2
recommendation. I think the basic reason is that often lower layer
protocols do not distingush between authentication and authorization.
In these protocols the EAP-Success translates to a granting of access.
If one were dealing with lower layer protocols that handled this
differently then perhaps the having conflicting AVPs in some cases might
not be so bad.
The alternate use of using Diameter to interface to an EAP
authentication server from an authorization server introduces some
interesting behavior. It could be possible that the authentication
succeeds and the authorization fails. In this case it would seem that
the authorization server should turn the EAP-Payload to an EAP-Failure
to be in line with 2.8.2. It might also be noted that this behavior
when used with certain EAP methods may cause a EAP timeout in lower
layers that expect the authorization decision to match the EAP
Authentication decision.
[Pasi Eronen] I think the key name part of this issue is already
covered by issue #460. Would this change be ok?
Change Section 2.8.2 from
"A Diameter-EAP-Answer message containing an EAP-Payload of
type EAP-Success or EAP-Failure MUST NOT have the Result-Code
AVP set to DIAMETER_MULTI_ROUND_AUTH. Also, the Result-Code
SHOULD match the contained EAP packet (successful Result-Code
if EAP-Success, and a failure Result-Code for EAP-Failure).
TO BE WRITTEN: clarify this."
To
"A Diameter-EAP-Answer message containing an EAP-Payload of
type EAP-Success or EAP-Failure MUST NOT have the Result-Code
AVP set to DIAMETER_MULTI_ROUND_AUTH. Also, the Result-Code
SHOULD match the contained EAP packet: a successful Result-Code
for EAP-Success, and a failure Result-Code for EAP-Failure.
When the encapsulated EAP packet does not match the result
implied by the Result-Code AVP, the combination is likely to
cause confusion, because the NAS and peer will arrive at
different conclusions as to the outcome of the
authentication. For example, if the NAS receives a failure
Result-Code with an encapsulated EAP Success, it will not
grant access to the peer. However, on receiving the EAP
Success, the peer will be lead to believe that it
authenticated successfully.
This situation can be difficult to avoid when Diameter proxy
agents make authorization decisions (that is, proxies can
change the Result-Code AVP sent by the home server), or when
Diameter is used for communicating with a backend
authentication server (see Section 2.8.5). The responsibility
for avoiding conflicts lies with the EAP server. The NAS or
proxy agents MUST NOT "manufacture" or modify EAP packets in
order to correct contradictory messages they receive."
[Joe Salowey] I don't think this works. Contradictory messages SHOULD NOT
be
allowed, but EAP-Messages MUST NOT be modified. This basically says that an
intermediate proxy SHOULD NOT fail authorization, is this what we want to
say? It seems that either you should allow EAP-Success to be turned into
EAP-Failure (not the other way around) or disallow proxies.
[Pasi Eronen] I think the "MUST NOT modify EAP messages" part is more
important; that's essentially attempting a man-in-the-middle
attack against the protocol, and many EAP methods have e.g.
method-specific result indications that prevent this
from even working.
[Joe] It sounds like you are arguing for not allowing an intermediary to
change and authorization decision. The basic problem is that an EAP
authentication decision in not necessarily an authorization decision. By
enforcing no conflicts and no modifications we make successful
authentication equivalent to successful authorization. I do not think this
is so good.
Perhaps authenticate and authorize functionality should only be used in
cases where the authentication decision is equivalent to authorization. In
other cases two separate authentication followed by authorization messages
should be used.
[Pasi Eronen] I agree, EAP success/failure and Diameter success/failure
Result-Code are two separate things. I'm proposing that
we enforce the "no modifications to EAP messages" part,
but allow conflicting messages with a note explaining
why they may cause problems (this is what RFC3579 also does).
A separate Diameter AUTHORIZE_ONLY exchange doesn't really
help here, because the NAS does not have any conflicts about
what to do (it's not supposed to look inside the EAP packet).
What is really missing is a secure way to notify the client
that "EAP went OK, but I decided anyway not to give you access".
For instance, the 802.11i four-way handshake could have had some
field denoting "authorization failed" (which would be protected
with keys derived from PMK).
[Joe Salowey] yes, I agree I agree about the authorize only. I'm not
as strict on
modifications to EAP-Success and EAP-Failures.
[Pasi Eronen] Other than that, it's IMHO enough to say that "there are
circumstances where conflicting messages can't be avoided,
but you should be aware that it causes some problems".
I don't think we have to solve these problem in this document;
neither does RFC3579...
[Joe] Maybe, but how does this work in 802.1x case if AAA rejects, but EAP
indicates success? If we don't solve it here then where do we solve it?
[Pasi Eronen] Since we don't have a protected "authorization failure" exchange
between the client and NAS, we seem to be stuck with either
attempting MitM attack against EAP, or sending conflicting
messages. Both usually lead to the same situation: a timeout
before the client discovers that it didn't actually get access.
In 802.11i, it seems the timeout for conflicting messages isn't
necessarily that long. The client is expecting the first
message of four-way handshake; the default retransmission
timeout is 100 ms, and the default number of retransmissions
is 3. Therefore, if the client doesn't receive something in, say,
one second after EAP Success, it could deduce that something went
wrong...
(If the NAS or proxy changes the EAP Success to Failure, and
the client ignores the Failure message because it had contradicting
method-specific indication, it seems the timeout would have
to be much longer than this.)
In plain 802.1X for e.g. wired Ethernet switch ports the timeout
could be longer, sure (no response to any ARP or DHCP
messages). But IMHO this is not something that absolutely
needs to be solved... (and the successor of 802.1X/11i looks
like a more logical place to solve this than Diameter EAP spec).
[Joe] Not all lower layers behave consistently. Perhaps we need to better
describe the potential problems with how the lower layers behave and make
recommendation upon that. I included a modification to text below also
including EAP message modification text that aligns more closely with 3579.
"A Diameter-EAP-Answer message containing an EAP-Payload of
type EAP-Success or EAP-Failure MUST NOT have the Result-Code
AVP set to DIAMETER_MULTI_ROUND_AUTH.
When used with lower layers that treat authentication as sufficient
for authorization the Result-Code should match the contained EAP
packet: a successful Result-Code
for EAP-Success, and a failure Result-Code for EAP-Failure. In this
case
when the encapsulated EAP packet does not match the result
implied by the Result-Code AVP, the combination is likely to
cause confusion, because the NAS and peer will arrive at
different conclusions as to the outcome of the
authentication. For example, if the NAS receives a failure
Result-Code with an encapsulated EAP Success, it will not
grant access to the peer. However, on receiving the EAP
Success, the peer will be lead to believe that it
authenticated successfully.
This situation can be difficult to avoid when Diameter proxy
agents make authorization decisions (that is, proxies can
change the Result-Code AVP sent by the home server), or when
Diameter is used for communicating with a backend
authentication server (see Section 2.8.5). Since the
responsibility for
avoiding conflicts lies with the Diameter
server, the NAS MUST NOT "manufacture" EAP result packets in order
to
correct contradictory messages that it receives. This
behavior,
originally mandated within [IEEE8021X], will be deprecated in the
future.
"
Proposed Resolution: Discuss
Issue 462: Typo in NASREQ-14
Submitter name: Ignacio Goyret
Submitter email address: igoyret@lucent.com
Date first submitted: 3/16/04
Reference:
Document:
NASREQ-14
Comment type: E
Priority: S
Section: 7
Rationale/Explanation of issue:
The table in section 7, page 46, contains a typo that conflicts with the text in
section 7.10.
Requested change:
The table reads:
Tunnel-Client- 90 7.10 Unsigned32 | M | P | | V | Y |
Auth-Id | | | | | |
^^^^^^^^^^^
It should read:
Tunnel-Client- 90 7.10 OctetString| M | P | | V | Y |
Auth-Id | | | | | |
^^^^^^^^^^^
Proposed Resolution: Accept
Issue 463: Incomplete ABNFs
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: 6/1/04
Reference:
Document:
EAP-06
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:
"A Diameter client MUST NOT send a Diameter-EAP-Request encapsulating an
EAP Request packet, and a Diameter server receiving such packet MUST
respond with a failure Result-Code.."
Two periods at the end of the sentence.
This document does not define the ABNF for use with the ASR, ASA, RAR,
RAA, STR, or STA commands. This is probably very similar to the ABNFs
used with NASREQ, in which case a reference to [NASREQ] may suffice.
I believe that this application shares many of the same RADIUS/Diameter
translation considerations as NASREQ Section 9. It should probably
explicitly state this, particularly as regards the RADIUS
Dynamic Authorization considerations described in Sections 9.1.1 and
9.2.1 of NASREQ.
Proposed Resolution: Accept
Issue 464: Application-Id Usage
Submitter name: Yoshihiro Obha
Submitter email address:
yohba@tari.toshiba.com
Date first submitted: 6/14/04
Reference:
http://www.merit.edu/mail.archives/aaa-wg/msg00688.html
Document:
NASREQ, EAP, MIP, CC
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:
Maybe this was discussed in the past but why can't we use application
id for the base protocol (=0) for RAR, RAA, STR, STA, ASR, ASA, ACR
and ACA commands instead of NASREQ's application id? All those
commands that are re-defined in the NASREQ draft have no new required
AVPs specific to NASREQ. So it does not make sense to me to use
NASREQ application id for those messages.
[Bernard Aboba] This makes sense.
RFC 3588 says that changing the Application-ID is a last resort:
" Should a new Diameter usage scenario find itself unable to fit within
an existing application without requiring major changes to the
specification, it may be desirable to create a new Diameter
application. Major changes to an application include:
- Adding new AVPs to the command, which have the "M" bit set.
- Requiring a command that has a different number of round
trips to
satisfy a request (e.g., application foo has a
command that
requires one round trip, but new application bar
has a command
that requires two round trips to complete).
- Adding support for an authentication method requiring
definition
of new AVPs for use with the application.
Since a new EAP
authentication method can be supported within
Diameter without
requiring new AVPs, addition of EAP methods does
not require the
creation of a new authentication application.
Creation of a new application should be viewed as a last resort.
An
implementation MAY add arbitrary non-mandatory AVPs to any command
defined in an application, including vendor-specific AVPs without
needing to define a new application. Please refer to Section
11.1.1
for details."
In Diameter MIP, the AMR/AMA, HAR/HAA and ACR/ACA commands meet this criteria,
but usage of STR/STA does not. RAR/RAA is not used.
It looks like this also applies to AAR/AAA, ACR/ACA, STR/STA, RAR/RAA in
NASREQ & EAP.
We need to be clear on how Application-IDs are used in all commands. Leaving
this "implicit" can
lead to confusion.
The requested change is for an Application ID of "Diameter Common Messages"
wherever there are no mandatory AVPs are added.
[Pasi Eronen] This seems to imply that a new application can't borrow only
a subset of mandatory commands from an existing application..?
Otherwise we could get a conflict. Let's assume that application
X has commands C1 and C2, and application Y defines a new
command C3 and borrows C1 from X (without any new mandatory
AVPs).
It seems that a Diameter server implementing only Y can't
advertise support for X, since it does not implement C2.
But using application identifier of X for C1 is not allowed
either, since this seems to contradict the text saying that
"When a request is routed, the target server MUST have
advertised the Application Identifier (see Section 2.4) for
the given message".
Another related issue is whether two different applications
could use the same AVP (in the same command and with the same
application ID) for slightly different purposes. At least this
happens all the time with RADIUS, but perhaps the different uses
can be distinguished even if the application ID is the same...
[Bernard Aboba] If application Y defines a new command C3, then it needs to
advertise
application Y, since otherwise it can't be guaranteed that Diameter peers
will select a path that will allow command C3 to be sent from Diameter
client to server.
The question is whether it should also advertise the application that it
inherited command C1 from, even though it doesn't support command C2.
If the application-Id in question is Diameter Base (Application-ID 0) I
think there is no issue, since this is mandatory-to-implement for all
Diameter peers.
However, if we are talking about multiple inheritance (e.g. inheriting
commands from an Application-Id other than Base authentication and
accounting) I think we have a problem. I'd interpret RFC 3588 as allowing
an out for this, since the number of round-trips is changed (e.g. the
common is disallowed altogether).
Does this make sense?
In this particular case, is there any issue with advertising Diameter Base
Common Messages as well as EAP? I think there isn't because EAP supports
all Base commands. However, there might be an issue with advertising
NASREQ where the NAS or server doesn't support PAP/CHAP (AAR/AAA).
Proposed Resolution: Discuss
Issue 465: Key Naming
Submitter name: Jari Arkko
Submitter email address:
jari.arkko@piuha.net
Date first submitted: 4/21/04
Reference:
http://www.merit.edu/mail.archives/aaa-wg/msg00449.html
Document:
EAP-08
Comment type: T
Priority: S
Section: 4.1.4
Rationale/Explanation of issue:
I do see the point of being able to name a the MSK.
However, I would suggest that we define this AVP
in a separate document when there is a specific use
case and need for it, because I think adding it
to the Diameter EAP document creates some problems
for us (more on that below).
I would also note that we may need AMSK names, though
informing applications of them probably takes place through
some node-internal API rather than a AAA protocol.
About the problems that I mentioned:
o I think its fine to say that the exact use of
the name information is link layer dependent.
I take it that this means the client side?
But I feel uneasy about defining an attribute
unless we also specify how the server fills
in the information.
o We can expect the EAP Keying Framework document
to specify this, perhaps, but then we create
a dependency from this document to the EAP
Keying Framework, which is likely ready later
than this document (and is Informational).
o Current systems do not use the key name for
anything.
o As you point out, there is no corresponding
RADIUS attributes. This would imply that all
Diameter clients would have to prepare for the
possibility that they don't get this attribute,
in case the server was RADIUS. Likewise all
servers would have to prepare for the possibility
that their attribute is stripped off by a Diameter
to RADIUS gateway. So it seems hard to even
consider relying on this information.
[Bernard Aboba]
In reading Diameter EAP-08, Section 4.1.4 says:
" The EAP-Key-Name AVP (AVP Code TBD-BY-IANA) is of type OctetString.
It contains an opaque key identifier (name) generated by the EAP
method. Exactly how this name is used depends on the link layer in
question, and is beyond the scope of this document (see [EAPKey] for
more discussion).
It should be noted that not all link layers use this name, and
currently most EAP methods do not generate it. The home Diameter
server SHOULD include this AVP in Diameter-EAP-Response only if an
empty EAP-Key-Name AVP was present in Diameter-EAP-Request."
I'd suggest that the second paragraph should be changed to say:
"It should be noted that not all link layers use this name, and
currently most EAP methods do not generate it. Since the NAS
operates in pass-through, it cannot know the Key-Name before
receving it from the AAA server. As a result, a Key-Name
AVP sent in a Diameter-EAP-Request MUST not contain any data.
A home Diameter server receiving a Diameter-EAP-Request
with a Key-Name AVP with non-null data MUST silently
discard the AVP. In addition, the home Diameter
server SHOULD include this AVP in Diameter-EAP-Response only if an
EAP-Key-Name AVP with non-null data was present in Diameter-EAP-Request."
Proposed Resolution: Discuss
Issue 466: Missing QoSFilterRule AVP
Submitter name: Bernard Aboba
Submitter email address:
aboba@internaut.com
Date first submitted: 7/1/04
Reference:
http://www.merit.edu/mail.archives/aaa-wg/msg00449.html
Document:
NASREQ, RFC 3588 Errata
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:
RFC 3588 defines a QoS Filter Rule syntax in Section 4.3. My
understanding was that this syntax was to be used by the
QoS-Filter-Rule AVP in NASREQ. Among other things, the need for QoS
filters was described in the original AAA and NASREQ requirements
documents.
Did this AVP somehow get lost on the cutting room floor?
[Pasi Eronen] It's not present in any version of NASREQ (00..16).
Perhaps it could be left to a separate document?
There has been some discussion at RADIUSEXT about the
"bandwidth" attributes that provide a subset of the
QoSFilterRule functionality; I'm wondering if that
subset would be sufficient for many cases...?
BTW, as I mentioned on the RADIUSEXT mailing list a while ago,
some parts of the QoSFilterRule syntax got lost somewhere in
the process, too. Perhaps the missing text (salvaged from
BASE -09) should be filed as an errata issue for RFC3588?
DSCP <color>
color values as defined in [DIFFSERV]. Exact
matching of DSCP values is required (no masks or
ranges).
metering <rate> <color_under> <color_over>
The metering option provides Assured Forwarding,
as defined in [DIFFSERVAF], and MUST be present
if the action is set to meter. The rate option is
the throughput, in bits per second, which is used
by the access device to mark packets. Traffic
above the rate is marked with the color_over
codepoint, while traffic under the rate is marked
with the color_under codepoint. The color_under
and color_over options contain the drop
preferences, and MUST conform to the recommended
codepoint keywords described in [DIFFSERVAF]
(e.g. AF13).
The metering option also supports the strict
limit on traffic required by Expedited
Forwarding, as defined in [DIFFSERVEF]. The
color_over option may contain the keyword "drop"
to prevent forwarding of traffic that exceeds the
rate parameter.
[Bernard Aboba] I'm not sure this is possible, because it would probably have
to be a
mandatory AVP, and addition of mandatory AVPs to an existing application
requires defining a new Application-Id, which would break compatibility
with the existing NASREQ Application.
For that reason, I'd prefer if this AVP were to be defined in NASREQ.
This might also allow us to address the issue of the missing text.
[Jari Arkko]
For that reason, I'd prefer if this AVP were to be defined in NASREQ.
Yes.
This might also allow us to address the issue of the missing text.
Do we remember why the missing text was taken away?
[Bernard Aboba] I've done a bit more archeology, and here is what I've found. Apparently, QoS-Filter-Rule AVP was never included in NASREQ. However, the QoS-Filter-Rule data type first found its way into the Diameter Base specification with draft-ietf-aaa-diameter-07.txt, submitted in July 2001. The text remained unchanged until the second half of it was removed in draft-ietf-aaa-diameter-10.txt, submitted in April 2002. This looks like an editing mistake, rather than an intentional removal, since I can't find an Issue for which the removal might be a resolution. The mistake was apparently not detected prior to publication of RFC 3588. To understand how QoS-Filter-Rule AVP got into Diameter Base in the first place, I went back to the original requirements documents. In terms of NASREQ QoS support, the original requirement came from RFC 2881 (NASREQNG). Section 9.3.6 says: A NAS may delivery different qualities, types, or levels of service to different users based on policy and identity. NAS's may perform bandwidth management, allow differential speeds or methods of access, or even participate in provisioned or signaled Quality of Service (QoS) networks.
This was the original requirement that QoS-Filter-Rule AVP was trying to address. The NASREQ requirement was then rolled up into RFC 2989, "Criteria for Evaluating AAA Protocols for Network Access". This document included "Support for Access Rules, Restrictions, Filters" as a MUST for NASREQ, with a footnote e) clarifying the requirement: [e] This requirement refers to the ability to of the protocol to describe access operational limitations and authorization restrictions to usage to the NAS which includes (but is not limited to): 1. Session expirations and Idle Timeouts 2. Packet filters 3. Static routes 4. QoS parameters Given the importance of the QoS requirement for NASREQ (a MUST), the history within Diameter Base (apparent editorial mistake), and the relative ease with which the issue can be fixed (inclusion of a paragraph such as the following), I think this issue really does need to be addressed.
[Bernard Aboba] Here is the proposed resolution: Submit an errata to RFC 3588 with the complete QoSFilterRule definition (see below).
Add QoS-Filter-Rule AVP to the ABNFs and tables in NASREQ. Insert a new section in NASREQ: X.X QoS-Filter-Rule AVP The QoS-Filter-Rule AVP (AVP Code XXX) is of type QoSFilterRule, and provides QoS filter rules that need to be configured on the NAS for the user. One or more such AVPs MAY be present in an authorization response.
Note: Due to an editorial mistake in [RFC3588], the complete QoSFilterRule definition was not included. It is reprinted here for clarification. QoSFilterRule The QosFilterRule format is derived from the OctetString AVP Base Format. It uses the ASCII charset. Packets may be marked or metered based on the following information that is associated with it: Direction (in or out) Source and destination IP address (possibly masked) Protocol Source and destination port (lists or ranges) DSCP values (no mask or range) Rules for the appropriate direction are evaluated in order, with the first matched rule terminating the evaluation. Each packet is evaluated once. If no rule matches, the packet is treated as best effort. An access device that is unable to interpret or apply a QoS rule SHOULD NOT terminate the session. QoSFilterRule filters MUST follow the format: action dir proto from src to dst [options] tag - Mark packet with a specific DSCP [DIFFSERV]. The DSCP option MUST be included.
meter - Meter traffic. The metering options MUST be included. dir The format is as described under IPFilterRule in [RFC3588]. proto The format is as described under IPFilterRule in [RFC3588].
src and dst The format is as described under IPFilterRule in [RFC3588]. options: DSCP <color> color values as defined in [DIFFSERV]. Exact matching of DSCP values is required (no masks or ranges). metering <rate> <color_under> <color_over> The metering option provides Assured Forwarding, as defined in [DIFFSERVAF], and MUST be present if the action is set to meter. The rate option is the throughput, in bits per second, which is used by the access device to mark packets. Traffic above the rate is marked with the color_over codepoint, while traffic under the rate is marked with the color_under codepoint. The color_under and color_over options contain the drop preferences, and MUST conform to the recommended codepoint keywords described in [DIFFSERVAF] (e.g. AF13). The metering option also supports the strict limit on traffic required by Expedited Forwarding, as defined in [DIFFSERVEF]. The color_over option may contain the keyword "drop" to prevent forwarding of traffic that exceeds the rate parameter. The rule syntax is a modified subset of ipfw(8) from FreeBSD, and the ipfw.c code may provide a useful base for implementations.
Proposed Resolution: Accept
Issue 467: Diameter EAP Keying Model Issues
Submitter name: Bernard Aboba
Submitter email address:
aboba@internaut.com
Date first submitted: 7/5/04
Reference:
http://www.merit.edu/mail.archives/aaa-wg/msg00740.html
Document:
EAP-08
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:
The Diameter EAP document assumes the EAP keying model
described in [KEYFRAME]. This assumption is pervasive
within the document, such as in the Key-Name support.
However, recently another EAP keying model has been
submitted for consideration in RADEXT:
http://www.ietf.org/internet-drafts/draft-zorn-radius-keywrap-00.txt
http://www.ietf.org/internet-drafts/draft-zorn-radius-keyreq-01.txt
Since there can only be a single keying model for EAP keying in Diameter,
RADIUS and EAP, the differences between the Diameter EAP model
and the two above drafts need to be resolved.
Since the Diameter EAP document is in AAA WG last call, there is
no better time to discuss (and resolve) this than now.
Proposed Resolution: Discuss
Issue 468: Oversight of One AVP in AAA Message
Submitter name: Javier Gonzalez Gallego
Submitter email address:
ggfj@nortelnetworks.com
Date first submitted: 7/7/04
Reference:
http://www.merit.edu/mail.archives/aaa-wg/msg00771.html
Document: NASREQ-16
Comment type: T
Priority: S
Section: 3.2
Rationale/Explanation of issue:
In the AAA message, the *[Failed-AVP] is missing. This is needed to report some of the permanent failures as inicated by RFC 3588.
To follow the pattern of other Answer messages (RAA), it
should be inserted after
[ Error-Message ]
[ Error-Reporting-Host ]
Requested change:
Before:
<AA-Answer> ::= < Diameter Header: 265, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Auth-Request-Type }
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ User-Name ]
[ Service-Type ]
* [ Class ]
* [ Configuration-Token ]
[ Acct-Interim-Interval ]
[ Error-Message ]
[ Error-Reporting-Host ]
[ Idle-Timeout ]
[ Authorization-Lifetime ]
....
(Skipped text)
Proposed Resolution: Discuss
Issue 469: Application-Id Requirements
Submitter name: Bernard Aboba
Submitter email address:
aboba@internaut.com
Date first submitted: 8/17/04
Reference:
Document: RFC 3588
Comment type: T
Priority: S
Section: 1.2.3, 1.2.4
Rationale/Explanation of issue:
RFC 3588, Section 1.2.3 describes when a new authentication Application
Identifier is needed. Section 1.2.4 describes when new accounting
Application Identifiers are required.
Included in the list of conditions requiring a new Application-ID is:
" - Adding new AVPs to the command, which have the "M" bit set."
Given the discussion since the publication of RFC 3588, I now believe that
the above sentence is in error. A new Application-ID should not be
required due to addition of AVPs to an application, whether the mandatory
bit is set or not.
I am curious what the WG thinks about this. Given that we are just now
getting ready to publish Diameter applications as RFCs, it is possible to
correct this mistake. Below I argue that letting this sentence remain in
the spec could prove costly.
ANALYSIS
Section 1.2.3 states:
"An implementation MAY add arbitrary non-mandatory AVPs to any command
defined in an application, including vendor-specific AVPs without
needing to define a new application."
So addition of an AVP by itself does not require a new
Application-ID, if the 'M' bit is not set.
So what is it about the 'M' bit that changes the situation so
fundamentally?
Let's review the purpose of the 'M' bit.
The purpose of the Mandatory bit was to enable implementations
that receive an AVP they do not support to determine whether they can
ignore that AVP, or whether a fatal error has occurred.
In other words, the purpose of the Mandatory bit was to enable Diameter
applications to be extended while maintaining well defined behavior.
Given this, if a Diameter application were to be extended with new AVPs
without obtaining a new Application ID, what happens?
Since no new Application-ID is used, Diameter peers will negotiate
capabilities with the existing Application-IDs, oblivious as to whether
new 'M' bit AVPs will be used or not. As a result, Diameter connections
will be established all along the path between the Diameter peers.
If the new AVPs do not have the 'M' bit set, then a Diameter peer can
ignore them, presumably without harm. If the AVPs have the 'M' bit set,
then a Diameter peer doesn't support them, then a fatal error
will result -- but Diameter error messages will make it clear what the
problem was. What is done on receipt of the error message is
implementation dependent -- but one possibility would be to stop sending
the offending AVP to the peer that objected.
Note that in most cases, Diameter agents will not care about new AVPs,
whether they have the 'M' bit set or not. Relays and Redirects won't
care. Proxies might care -- but if they do then they can send their own
fatal errors.
Now let us look at what happens if a new Application-ID is required.
Since Diameter peers exchange the supported Application-IDs within the
CER/CEA exchange, if the new Application-IDs are not supported by one or
more peers along the path, then the Diameter messages won't get routed to
the destination. The end result is the same -- an attempt to send a
non-understood AVP with the 'M' bit set will result in an Error-Message
coming back, but now the error message will be returned from an
intermediary unable to find a Diameter peer to deliver to, rather than
from the endpoint peer.
This is a bit like the distinction between receiving a "host unreachable"
ICMP message and a "port unreachable" ICMP message. Not a great
difference.
However, consider the downside to requiring a new Application-ID due to
addition of a new mandatory AVP:
* Proliferation of Application-IDs.
What if it is necessary to extend an application with multiple
additional mandatory AVPs? Do we now need a new Application-ID for
each potential set of mandatory AVPs? For example, what if we want to
extend Diameter EAP with additional wired 802 VLAN attributes as well as
some WLAN attributes and perhaps some filter attributes? Do we need to
obtain 3 new application-IDs?
Or as an alternative, do we require each application to support
versioning?
* Additional work in intermediaries. Do intermediaries now need a
"Dictionary" of Application-IDs? Why isn't an AVP dictionary sufficient
(if one is needed at all)?
* Inheritance effects. Diameter EAP depends on NASREQ. Say I want to
extend NASREQ with some additional filter attributes. Does this mean that
both NASREQ and EAP applications need new Application-IDs to support this?
* Bureaucratic overhead. New Application-IDs are allocated by Expert
Review. Who is volunteering to be the Expert to "review" all these new
Application-IDs? Why isn't review of the new AVP definitions sufficient?
Based on the limited upside and substantial downside of requiring new
Application-IDs due to addition of AVPs with the 'M' bit set, my
conclusion is that the sentence requiring this in RFC 3588 was an error.
Assuming that the AAA WG agrees with this, then my recommendation is to
post an errata to the RFC Editor to this effect.
[Stura Marco] I fully share your view and analysis. Therefore I support
sending an RFC
3588 errata as you recommend.
[Jari Arkko] Thanks for posting this, and yes, I also agree with your
analysis. I would in addition point out that the distinction
between a syntactically mandatory and a policy-wise mandatory
attribute is often fuzzy. And we have always allowed nodes
to reject a transaction if they have a policy that requires
something that wasn't sent or was sent with a wrong value.
For instance, do you require a particular AVP Foo-Parameter
because its your policy that you only serve link layer FOO
even if you use NASREQ, or do you require it because you
are doing NASREQ-Foo which has Foo-Parameter marked as
mandatory?
Of course, with NASREQ-Foo you can increase the granularity
of negotiation. But we are not prohibiting people to come
up with a new application identifier if their application
really is different. Just that you would not *have* to do it.
For instance, if people come up with three new security-related
(=> mandatory) new features usable in the network access
context, does this mean that one has to develop NASREQ-F1,
NASREQ-F2, NASREQ-F3, NASREQ-F1-and-F2, and so on just
to be able to mark the attributes as mandatory?
Proposed Resolution: Discuss