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?