One document matched: draft-ietf-aaa-diameter-cms-sec-04.txt
Differences from draft-ietf-aaa-diameter-cms-sec-03.txt
AAA Working Group Pat R. Calhoun
Internet-Draft Black Storm Networks
Category: Standards Track Stephen Farrell
<draft-ietf-aaa-diameter-cms-sec-04.txt> Baltimore Technologies
William Bulley
Merit Network, Inc.
March 2002
Diameter CMS Security Application
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
The Diameter base protocol leverages either IPsec or TLS for
integrity and confidentiality between two Diameter peers, and allows
the peers to communicate through relay and proxy agents. Relay agents
perform message routing, and other than routing AVPs, do not modify
Diameter messages. Proxy agents, on the other hand, implement policy
enforcement, and actively modify Diameter messages.
This Diameter application describes how a security association is
established by two peers through agents, and how authentication,
integrity, confidentiality and data origin authentication are
achieved using a mixture of symmetric and asymmetric transforms, by
Calhoun, Farrell, Bulley,expires September 2002 [Page 1]
Internet-Draft March 2002
encapsulating Cryptographic Message Syntax (CMS) data within AVPs.
CMS is also used to carry X.509 certificates.
Table of Contents
1.0 Introduction
1.1 Requirements language
1.2 Establishing Security Relationship through relay agents
1.3 Establishing Security Relationship through proxy agents
1.4 Using Redirect agents in lieu of DSA
1.5 When to use DSAs
1.6 Advertising application support
1.7 CMS Processing of Grouped AVPs.
2.0 AVP Format
3.0 Key Management
3.1 Usage Scenario
3.2 Certificate Requirements
3.3 Algorithms
3.4 Reuse of CMS Content Encryption Keys
4.0 Command-Codes Values
4.1 Diameter-Security-Association-Request
4.2 Diameter-Security-Association-Answer
4.3 Proxy-Diameter-Security-Association-Request
4.4 Proxy-Diameter-Security-Association-Answer
5.0 Diameter Security Association Message Flow
6.0 Diameter Security AVPs
6.1 CMS-Signed-Data AVP
6.2 CMS-Encrypted-Data AVP
6.3 Example Encodings
6.4 Local-CA-Info AVP
6.4.1 CA-Name AVP
6.4.2 Key-Hash AVP
6.5 OCSP-Nonce AVP
6.6 AAA-Node-Cert AVP
6.7 OCSP-Responses AVP
6.8 CA-Chain AVP
6.9 OCSP-Request-Flags AVP
6.10 DSAR-Target-Realm AVP
6.11 DSA-TTL AVP
7.0 Result-Code AVP Values
7.1 Transient Failures
7.2 Permanent Failures
8.0 AVP Occurrence Tables
9.0 IANA Considerations
9.1 Command Codes
9.2 AVP Codes
9.3 Result-Code AVP Values
Calhoun, Farrell, Bulley,expires September 2002 [Page 2]
Internet-Draft March 2002
9.4 Application Identifier
9.5 OCSP-Request-Flags AVP Values
10.0 Security Considerations
11.0 References
12.0 Acknowledgements
13.0 Authors' Addresses
14.0 Full Copyright Statement
15.0 Expiration Date
Calhoun, Farrell, Bulley,expires September 2002 [Page 3]
Internet-Draft March 2002
1.0 Introduction
The Diameter base protocol [BASE] leverages either IPsec or TLS for
integrity and confidentiality between two Diameter peers. However,
the Diameter protocol also allows peers to communicate through relay
and proxy agents, and in such environments security information is
lost at each agent.
Relay agents perform message routing, and other than routing AVPs, do
not modify Diameter messages. Proxy agents, on the other hand,
implement policy enforcement, and actively modify Diameter messages.
See [BASE] for a more comprehensive definition of the role of relay
and proxy agents.
There are two main techniques used in this specification. Digital
signatures (along with digital certificates) provide authentication,
integrity and data origin authentication. Encryption provides
confidentiality (using asymmetric techniques to encrypt a content
encryption key, which is then used for bulk encryption). Both
techniques can be used simultaneously to provide all the specified
security services.
This Diameter application makes use of Cryptographic Message Syntax
(CMS), which is the method used to secure MIME (S/MIME) messages.
This application was designed to allow Diameter implementations to
use existing S/MIME toolkits in order to comply with this
specification.
This specification contains two different set of messages. The
Diameter Security Association (DSA) messages are used to establish a
security assocation, while the Proxy Diameter Security (PDS) messages
are used to request that a security association be established by a
third party.
The following details the necessary support for both types of
messages based on the type of Diameter node:
- Diameter servers: MUST support DSA messages; MAY support PDS messages
- Proxy agents: MUST support DSA messages; MUST support PDS messages
- Diameter clients: SHOULD support DSA messages; MUST support PDS
messages
- Relay agents: MAY support DSA messages; MAY support PDS messages
- Redirector agents: MAY support DSA messages; MAY support PDS messages
1.1 Requirements language
In this document, the key words "MAY", "MUST", "MUST NOT",
"optional", "recommended", "SHOULD", and "SHOULD NOT", are to be
Calhoun, Farrell, Bulley,expires September 2002 [Page 4]
Internet-Draft March 2002
interpreted as described in [MUSTSHOULD].
1.2 Establishing a Security Relationship through relay agents
The AAA Working Group has defined a set of requirements in [AAAREQS]
to allow for Diameter peers to communicate securely through Relay
agents. This requirement calls for AVP integrity and confidentiality
between two peers communicating through agents. The term agent is
used in this specification for either a relay or a proxy agent.
Figure 1 provides an example of two Diameter peers establishing a
Diameter Security Association (DSA) through Relay agents. The
participants of a DSA are the peers where the DSA setup messages
terminate. In this example, the participants of the DSA would the NAS
(access device), and the Home Server.
mno.net mno.net xyz.net abc.com
+------+ <----> +------+ <----> +------+ <----> +------+
| | TLS |Agent | IPSec |Agent | IPSec | Home |
| NAS | | | | | | |
| | | 1 | | 2 | |Server|
+------+ +------+ +------+ +------+
<-------------------------------------------->
Diameter Security Association
Figure 1: Diameter Security Association
When one or more agents are used between two communicating Diameter
peers, the use of hop-by-hop security mechanisms (e.g. TLS, IPSec)
is unsuitable, since Diameter messages are processed at the
application layer at each agent. Therefore, an alternative mechanism
is required to protect portions of the message at the application
layer.
Allowing for a security association to be established through
Diameter relays allows the participants of the DSA to detect whether
protected AVPs have been modified en-route, and hides sensitive data
from intermediate agents. Furthermore, the Mobile IP and NASREQ
Working Groups have stated in [CDMAREQ, MIPREQ] that data origin
authentication of Diameter data, such as Accounting related AVPs, is
necessary.
Figure 2 provides an example of a message sent by an access device
(NAS), through Diameter relay agents, to its intended destination,
the home server. In this example, Proxy 2 modifies the contents of
the foo AVP, perhaps due to mis-configuration, or maliciously. This
specification would allow the participants of the DSA to detect such
a problem, as long as the AVP being modified was protected.
Calhoun, Farrell, Bulley,expires September 2002 [Page 5]
Internet-Draft March 2002
(Request) (Request) (Request)
[AVP(foo)=x] [AVP(foo)=x] [AVP(foo)=y]
+------+ -----> +------+ -----> +------+ -----> +------+
| | |Relay | |Proxy | | Home |
| NAS | | | | | | |
| | | 1 | | 2 | |Server|
+------+ <----- +------+ <----- +------+ <----- +------+
(Answer) (Answer) (Answer)
[AVP(foo)=b] [AVP(foo)=b] [AVP(foo)=a]
Figure 2: Diameter agent modifying AVP
This document defines the Diameter commands that are used to
establish a DSA through Diameter agents, and specifies how
encapsulating CMS objects [CMS] in Diameter AVPs can provide
authentication, integrity, confidentiality and data origin
authentication. CMS objects MAY also be used to transport X.509
certificates and revocation lists.
Establishing a DSA through relay agents requires that the initiator
issues a Diameter Security Association Request (DSAR) message. In the
example provided in figure 1, NAS would issue the DSAR with the
Destination-Realm AVP set to abc.com. The Home Server would process
the request, and respond by issuing a Diameter Security Association
Answer (DSAA) message. If the DSAA message contains a Result-Code
indicating success, the DSA is established between the NAS and the
home server.
Once the DSA is established, participants with private keys MAY apply
digital signatures to protect one or more AVPs within a message. In
the example provided in Figure 2, the Foo AVP would be protected by
the digital signature, and any modification of the AVP by the relay
agents, would be detected since the signature validation algorithm
would fail.
1.3 Establishing Security Relationship through proxy agents
As previously discussed, proxy agents typically modify Diameter
messages to implement policy enforcement. An example of a proxy
server would be an aggregating server, which typically sits one
Diameter hop away from the access device, and enforces policy in
order to protect the access device from receiving AVPs that could
cause harm (e.g. excessive number of filters, unsupported tunneling
protocol). Although in theory such checks could be performed on the
access device, these devices are typically embedded systems, and not
easily configurable. The proxy agent's behavior, on the other hand,
is typically under control of the network operator.
Calhoun, Farrell, Bulley,expires September 2002 [Page 6]
Internet-Draft March 2002
Diameter messages between two participants of a DSA would fail
verification if a proxy agent were to modify any protected AVPs.
Therefore proxy agents that modify AVPs MAY prevent the establishment
of DSAs based on local configuration.
In this section, we discuss the capabilities provided by this
Diameter application which allow proxy agents to secure AVPs on
behalf of an access device. The following scenarios are envisioned:
- The access device does not have the cryptographic ability to
handle CMS functions locally, and therefore requests such
services from the local agent, such an an aggregating relay or
proxy agent. The NAS may have been configured to always issue a
PDSR to its local agent for CMS services. In such cases, the
agent MUST select the values for the DSA-TTL.
- The access device has the cryptographic ability to perform CMS
functions, but a proxy agent is in the route towards the home
server, and it returned a failure to the DSAR messages stating
that it was not willing to allow the DSA to traverse through it.
Such agents MAY attempt to re-use the values from the initial
DSAR sent by the access device. In such cases,the PDSR initiator
SHOULD include the Destination-Host AVP to ensure that the PDSR
is received by the same proxy agent.
- The access device may have the cryptographic ability to perform
CMS functions locally, but does not request a DSAR to request a
DSA. The local agent, however, has been configured to establish
DSAs with certain realms automatically, hiding the existence of
the DSAs from the access device.
In the above scenarios, the first two occur at the explicit request
of the access device, while the last one occurs without any messaging
from the access device. In the latter case, the proxy agent acts as
an access device of sorts and the rules in section 1.2 should be used
instead.
When a local agent receives a DSAR, it has the following options:
- The local agent rejects the DSAR by sending a DSAA message whose
Result-Code AVP is set to DIAMETER_NO_CMS_THROUGH_PROXY. The
DSAA SHOULD include the CMS-Signed-Data AVP, signed by the proxy
agent, and include its certificate to allow the access device to
validate the originator of the DSAA. The access device can then
determine whether it is willing to provide service, based on its
local policy.
- The local agent rejects the DSAR by sending a DSAA message whose
Result-Code AVP is set to DIAMETER_CAN_ACT_AS_CMS_PROXY,
informing the access device that the agent is willing to
Calhoun, Farrell, Bulley,expires September 2002 [Page 7]
Internet-Draft March 2002
establish the DSA on its behalf. The DSAA MUST include the CMS-
Signed-Data AVP, signed by the proxy agent, and include its
certificate to allow the access device to validate the
originator of the DSAA. If the access device is willing to use
the agent's services, it issues a Proxy-Diameter-Security-
Association-Request (PDSR) which MUST contain the target realm.
The local agent MAY use any of the parameters provided by the
access device in the previous DSAR attempt when establishing the
DSA. Once the DSA is established, the agent MUST issue a Proxy-
Diameter-Security-Association-Answer (PDSA). The PDSA MUST
contain the TTL setting agreed by the proxy agent for its DSA.
This information will allow the access device to re-issue a PDSR
prior to the proxy's DSA expiry if it needs the DSA to remain
active.
Note that an access device MAY be configured to always issue a PDSR
to its aggregating proxy, reducing the number of round trips.
Similarly, an aggregating proxy MAY be configured to initiate an DSAR
regardless of whether a PDSR was sent by the access device.
mno.net mno.net xyz.net abc.com
+------+ +------+ +------+ +------+
| | |Proxy | |Relay | | Home |
| NAS | | | | | | |
| | |Agent | |Agent | |Server|
+------+ +------+ +------+ +------+
------------->
(DSAR) Destination-Realm = abc.com
<-------------
(DSAA) Result-Code = DIAMETER_CAN_ACT_AS_CMS_PROXY
------------->
(PDSR) DSAR-Target-Realm = abc.com
---------------------------->
(DSAR) Destination-Realm = abc.com
<----------------------------
(DSAA) Result-Code = DIAMETER_SUCCESS
<-------------
(PDSA) Result-Code = DIAMETER_SUCCESS
Figure 3: Establishing Security through Proxy Agent
An optimized approach also allows the PDSR to be sent by the access
Calhoun, Farrell, Bulley,expires September 2002 [Page 8]
Internet-Draft March 2002
device without the DSAR-Target-Realm AVP. This message is used to
inform the proxy that it MUST establish a DSA for all realms it will
be communicating with on behalf of the access device. DSAs are
typically established once the first request for a given realm has
been recelived by the proxy agent, but it MAY establish certain DSAs
with known realms in advance.
If a DSA for a given realm cannot be established, the proxy agent
MUST reject the access device's request, and set the Result-Code AVP
to DIAMETER_NO_DSA_ESTABLISHED. Although the proxy agent MAY receive
many PDSRs from access devices, only one DSA per realm need be
established. Furthermore, the proxy is responsible for re-
establishing the DSA prior to expiration without any involvement by
the access device.
It is important to note that proxy agents establishing DSA's on
behalf of a client will most likely need to reorder AVPs during the
encryption process, in order to fit the encrypted AVPs within a CMS-
Encrypted-Data AVP. This is contrary to the rule established in the
Diameter base protocol [BASE], which states that proxy agents SHOULD
NOT reorder AVPs.
Allowing the first hop agent to be used to establish the DSA with the
home server may reduce the current concerns that the cryptographic
operations resulting from this specification MAY overburden embedded
access devices.
1.4 Using Redirect agents in lieu of DSA
When a redirect agent is used, allowing an access device, relay or
proxy agent to communicate directly with the home server, the hop-by-
hop security mechanisms specified in the base protocol may be
sufficient.
However, there are certain business models where signing of selected
Diameter AVPs (e.g. accounting) MAY be desired, even when redirect
agents are used. Figure 4 shows an example where the relay agent
contacts the redirect agent to retrieve the necessary information for
it to communicate directly with the home server, which MAY include
the home server's certificates.
The relay agent MAY then initiate a DSA with the home server, using
the certificates provided by the redirect agents.
Calhoun, Farrell, Bulley,expires September 2002 [Page 9]
Internet-Draft March 2002
+------+
| |
| DRD |
| |
+------+
^ |
2. Request | | 3. Redirection
| | Notification
| v
+------+ ---------> +------+ <--------> +------+
| | 1. Request | | 4. DSAR/DSAA | |
| NAS | | DRL | | HMS |
| | 6. Answer | | 5. Request/Answer | |
+------+ <--------- +------+ <--------> +------+
mno.net mno.net abc.com
Figure 4: DSA Setup following redirect
The CMS specification allows for Diameter AVPs to be multiply-signed
(see section 6.1), which may prove useful in business models that
require both parties to sign accounting data in parallel. This scheme
provides some assurance that both parties agreed to the accounting
data, which MAY be used for settlement purposes.
1.5 When to use DSAs
Given that asymmetric transform operations are expensive, access
devices and/or Diameter agents MAY wish to restrict establishment of
a DSA to cases where the participants belong to a different
administrative domain.
1.6 Advertising application support
Diameter nodes conforming to this specification MAY advertise support
by including the value of two (2) in the Auth-Application-Id or the
Acct-Application-Id AVP of the Capabilities-Exchange-Request and
Capabilities-Exchange-Answer command [BASE].
1.7 CMS Processing of Grouped AVPs.
Grouped AVPs are processed as a whole, there is no partial signing or
encryption mechanism defined.
Only the P flag (resp. MAY Encr) setting for a Grouped AVP need be
set to Y to allow the Grouped AVP to be signed (resp. encrypted).
That is, the AVPs within the Grouped AVP need not have their "P" bit
Calhoun, Farrell, Bulley,expires September 2002 [Page 10]
Internet-Draft March 2002
set (resp. MAY Encr) in order to be part of a signed (resp.
encrypted) Grouped AVP.
Where a Grouped AVP is to be signed, implementations MAY set the "P"
bit for each of the AVPs within the Grouped AVP. When verifying
signatures over a Grouped AVP, implementations MUST NOT insist that
the "P" bit has been set for AVPs within the group.
Where a Grouped AVP is to be encrypted, implementations MUST NOT fail
encryption due to one of the members of the group being defined so as
to prevent encryption ("MAY Encr" set to "N"). Similarly following
decryption, implementations MUST NOT produce an error if one of the
group members is defined so as to prevent encryption. The Grouped AVP
itself, of course, MUST be defined to allow encryption.
Where a Grouped AVP is defined to disallow encryption then that
Grouped AVP MUST NOT include any AVPs which are defined so as to
allow encryption (since the member of the group might be erroneously
sent in clear, if included in such a Grouped AVP).
2.0 AVP Format
The Diameter base protocol [BASE] details the AVP header, which
includes the 'P' bit, but does not specify how the 'P' bit is used.
The 'P' bit, known as the protected AVP bit, is used to indicate
whether the AVP is protected by a digital signature. When set, the
AVP is protected and the contents cannot be changed by agents without
detection.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V M P r r r r r| AVP Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-ID (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+-+-+-+-+
Figure 5: Diameter AVP Header
All Diameter specifications MUST specify whether the 'P' bit can be
set or not, as is done in section 4.6 of [BASE] and section 6 below.
For AVPs that are designed to be changed at each hop (such as the
Proxy-Info AVP) Diameter nodes MUST NOT allow the 'P' bit to be set.
Diameter implementations MUST check whether AVPs with their 'P' bit
Calhoun, Farrell, Bulley,expires September 2002 [Page 11]
Internet-Draft March 2002
set are allowed to have that setting. If not, an appropriate error
message MUST be issued containing DIAMETER_INVALID_AVP_BIT_COMBO
result code.
3.0 Key Management
For origin authentication, CMS itself already provides sufficient key
management without the need for additional specification. Basically,
the originating Diameter node signs and includes whatever
certificates are necessary for validation of the digital signature.
Section 3.1 provides an example of how the Diameter CMS Security
application is used.
In order to encrypt AVPs for a recipient, the originating Diameter
node must have a copy of the recipient's public key. There are many
well-known key retrieval schemes (e.g. LDAP [CERTLDAP]), but this
specification also allows for the transportation of certificates
within Diameter AVPs, which is expected to simplify implementations.
Section 3.2 describes how Diameter node names are encoded within such
certificates.
Finally, it is anticipated that the overhead of asymmetric encryption
for each Diameter message sent to a given peer could be significant.
Section 3.4 specifies how CMS encryption keys MAY be reused for
multiple Diameter messages.
3.1 Usage Scenario
When a Diameter node is about to send a message, it must determine
whether a DSA should be established or not. We assume the Diameter
node knows the user's realm, perhaps through the User-Name AVP.
Implementations MAY cache the information required to establish a
DSA. However, they MUST honor time-to-live settings so that
certificates MUST re-validated (possibly including revocation checks)
once the DSA has expired.
Revalidations SHOULD also occur before the DSA expires according to
PKI policies. During the process of certificate path validation some
implementations will calculate a duration for which the certificate
path may be considered "safe". For example, if an implementation did
not support certificate revocation checks, then the "safe" period
would be from the time of initial validation until the earliest
notAfter time in the set of certificates in the path. An
implementation which does support certificate revocation checks will
typically be able to calculate a "safe" period based additionally on
Calhoun, Farrell, Bulley,expires September 2002 [Page 12]
Internet-Draft March 2002
the earliest nextUpdate field in a CRL or OCSP response. Basically,
the safe period is from the time of certificate validation to the
earliest value from the set of notAfter and nextUpdate fields
encountered during certificate validation.
However, implemetors should note that CAs MAY issue additional CRLs
before the nextUpdate period. Generally it is a matter of local PKI
policy as to whether an implementation will make additional checks
even during the calculated "safe" period. For the purposes of this
specification implementations are not required to make such checks
and MAY assume that no re-validation of certificates is required
during the "safe" period defined above.
We use Diameter Security Association Request (DSAR) and Diameter
Security Association Answer (DSAA) messages to establish a DSA, which
specifies which AVPs should be encrypted, signed or both, as well as
which public key(s) to use.
The originating node sends the DSAR message to a server in the
destination realm. The DSAR message contains:
- TTL for this DSA (seconds)
- the realm part of the user's NAI
- the list of direct trust CA's that the originating Diameter
node has configured into it for certificate validation. A
"direct trust" CA is one that the node is willing to use as the
"top" of a certificate chain, sometimes confusingly known as a
"root CA."
- a flag indicating whether the originating Diameter node wishes
to receive certificate status information using OCSP messages.
If this flag requires a fresh OCSP response, a nonce to be used
by the destination Diameter node in OCSP requests MUST also be
supplied. See [OCSP] for more details on the certificate status
protocol and messages.
The destination node MUST check that the provided elements of the
DSAR are valid. It MUST check, at least, that:
- Its local policy allows the given TTL, realm, AVP protection
expectations, certification status, and other parameters.
- A common "top" of the certificate chain can be found between the
home and foreign domains.
If these conditions can not be verified, the destination node MUST
return a DSAA with the Result-Code AVP set to
DIAMETER_NO_DSA_ESTABLISHED.
In the event the DSAR requested OCSP validation, via the OCSP-
Calhoun, Farrell, Bulley,expires September 2002 [Page 13]
Internet-Draft March 2002
Request-Flags AVP, and OCSP is not locally supported, the DSAA MUST
be returned with the Result-Code AVP set to
DIAMETER_OCSP_NOT_SUPPORTED. Otherwise, the destination node returns
the DSAA message which contains:
- TTL for this DSA (seconds)
- a chain of CA certificates (possibly empty)
- public key certificates for the Diameter servers in the realm,
all of which MUST validate up to one of the CA's contained in
the DSAR message, via the chain of CA certificates above;
- (optionally, if OCSP an response was requested in the DSAR and
OCSP is supported) a list of OCSP responses for the
certificates in question. If a fresh response was required and
a nonce value was included, each response will contain the
nonce from the DSAR message
The originating Diameter node now has to check the response. Any
failure results in error messages, auditing and not sending the
Diameter message.
DSAA Checks:
- the certificate chain provided in the DSAA is cryptographically
correct, passes the (relevant parts of the) path validation
algorithm specified in [CERTPROF] and terminates at a CA
mentioned in the DSAR message
- the name in the certificate is consistent with the rules
detailed in section 3.2.
- the DSAA message MUST include the CMS-Signed-Data AVP, the
signature MUST be validated and the signer's certificate chain
MUST terminate as a CA mentioned in the DSAR message
- the expiration of the TTL MUST be less or equal to the earliest
expiration of all certificates in the message, encoded in the
notAfter field.
If the initiator's policy is such that certificate status is
required, it MAY indicate that it requires an OCSP response from the
DSA peer in the DSAA message, via the OCSP-Request-Flags AVP.
Further, the initiator MAY request that the OCSP response be fresh
(non-cached) via the OCSP-Request-Flags and OCSP-Nonce AVPs. Upon
receipt of a DSAR message requesting an OCSP response, the receiver
issues an OCSP request and returns the response within the DSAA
message's OCSP-Responses AVP. The sender of the DSAA MAY included a
cached OCSP response, unless the requestor specifically requested a
fresh response.
The nonce value is to be (the beginning of) the nonce in the OCSP
response. The reason for this is that the responder MAY add
Calhoun, Farrell, Bulley,expires September 2002 [Page 14]
Internet-Draft March 2002
additional bits to the nonce, but the nonce provided in the OSCP-
Nonce MUST be present at the beginning of the nonce of the OSCP
response.
The DSAR message MAY include the CMS-Signed-Data AVP. If the
originating node has a private key, and it includes AVPs whose 'P'
bit are set, the CMS-Signed-Data AVP MUST be present.
The DSAA MUST include the CMS-Signed-Data, signed by a Diameter agent
or server within the user's realm, to prevent an intermediate node
from modifying the protection expectations for AVPs.
Depending upon the security technique required (digital signature,
encryption or both), then the originating node prepares the CMS
related AVPs as required.
If certificate revocation is enabled, anytime a certificate is used
from the local certificate cache, a revocation check MUST be
performed.
Once the DSA is in place, any Diameter messages created by a DSA peer
that has a private key MUST contain a signature over all AVPs whose
definition states that their 'P' bit MAY be set.
Furthermore, these peers MUST encrypt any AVPs whose definition
states that they MAY be encrypted.
Note: [BASE] includes the "MAY encr" column when describing AVPs. For
the originator "MAY encr" as used in [BASE] means that if a message
containing that AVP is to be sent via a proxy/agent (as opposed to
directly) then the message MUST NOT be sent unless there is a DSA
between the originator and the recipient OR the originator has
locally trusted configuration that indicates that CMS need not be
used.
3.2 Certificate Requirements
Certificates used for the purposes of Diameter MUST conform to the
PKIX profile [CERTPROF], and MUST also include a Diameter node's
FQDN, which is typically added in the Origin-Host AVP [BASE], as one
of the values of the subjectAltName extension of the Certificate.
The FQDN is to be encoded as a dNSName within the subjectAltName.
For Diameter nodes (capable of acting as recipients for
confidentiality), the FQDN MUST be of the form
"Diameter-<xxx>.<realm>". Other Diameter nodes MAY use this naming
scheme. Note that this naming constraint is for PKI purposes only,
Calhoun, Farrell, Bulley,expires September 2002 [Page 15]
Internet-Draft March 2002
and in no way restricts a Diameter's host name.
The naming scheme presented here is intended to:
- make it simple to use existing certification authorities (CAs)
for Diameter CMS
- allow CAs to ensure that only "proper" Diameter certificates are
accepted by Diameter nodes
- allow Diameter certificates to be used for other purposes where
that meets a CA's practices.
These names are used for two purposes:
1. Where a Diameter node is verifying a signature it needs to be
able to compare the identity of the signer against the identity
in the Origin-Host AVP.
2. Where a Diameter node is encrypting AVPs, it needs to be able
to ensure that it uses a public key for the intended recipient.
This requires comparing the identity in a Certificate against
the FQDN of the intended recipient (which is assumed to be
known).
In either case, the presence of the required FQDN as a dNSName value
in the subjectAltName extension of a verified public key certificate
satisfies the matching requirement.
Note that there MAY also be other values in the subjectAltName
extension, (either using dNSName or other elements of the CHOICE),
these can be safely ignored, but implementations MUST be able to
handle their presence.
Note also that the PKIX profile [CERTPROF], section 4.1.2.6,
specifies the rules for the relationship between the subjectAltName
extension and the subject field of public key certificates.
For multiple Diameter servers within a realm that share a public key,
each server's identity is encoded in the subjectAltName extension.
This allows any server within a realm to decrypt AVPs intended for
that realm.
Note that once operational experience has been gained, a future
document may specify a restricted profile of [CERTPROF] in order to
simplify implementation.
3.3 Algorithms
For all uses of CMS in this specification the mandatory to implement
Calhoun, Farrell, Bulley,expires September 2002 [Page 16]
Internet-Draft March 2002
algorithms are as follows:
- Hashing:
sha-1 (see [CMS] section 12.1.1)
- Signature (the hash algorithm is specified separately):
rsaEncryption (see [CMS] section 12.2.2)
- Content Encryption:
des-ede3-cbc (see [CMS] section 12.4.1)
- Asymmetric key transport:
rsaEncryption (see [CMS] 12.3.2.1)
- Symmetric key encryption (only needed in conjunction with
[RCEK]):
id-alg-CMS3DESwrap (see [CMS] section 12.3.3.1)
At some point in future, AES will replace 3DES.
3.4 Reuse of CMS Content Encryption Keys
This section describes an efficiency improvement which MAY be
supported by Diameter nodes. If a node doesn't support this feature,
then it MUST (and naturally will), treat all packets with re-used
content encryption keys as a cryptographic failure. The originating
node MAY then attempt to re-send the packets using asymmetric key
transport. If a node does support this feature, then the MUST/SHOULD
statements in this section apply, otherwise not.
Once a CMS-Encrypted-Data AVP has been exchanged between two Diameter
peers, then they share a symmetric cryptographic key (the content
encryption key) which can be used to encrypt further Diameter AVPs
between the peers by using the scheme specified in [RCEK]. The peers
MUST first take part in an DSAR/DSAA exchange in order to distribute
the required asymmetric keys.
Although the use of symmetric encryption might be used to provide
integrity or confidentiality, it does not provide data origin
authentication with proof of origin.
[RCEK] leaves open some issues, namely how to handle loss of a shared
secret (say following a peer re-boot) and for how long to continue to
use a shared secret (the maximum number of decryptions required).
Where a Diameter node receives a CMS-Encrypted-Data AVP, but doesn't
have the required shared secret, that node SHOULD return the
DIAMETER_KEY_UNKNOWN error message. The peer MAY then use the
DSAR/DSAA exchange to rebuild their Diameter security association.
In [RCEK], the default value for the maximum number of decryptions
Calhoun, Farrell, Bulley,expires September 2002 [Page 17]
Internet-Draft March 2002
allowed (CEKMaxDecrypts) when re-using a content encryption key is 1.
In general this default SHOULD be used, but if a Diameter node
"knows" that more than one CMS-Encrypted-Data AVP will be exchanged
between the nodes, then the CEKMaxDecrypts setting MAY be set higher.
Diameter nodes MUST be able to support a maxDecrypts setting of 1000.
Note that the CEKMaxDecrypts value used does not affect that DSA-TTL.
The DSA-TTL dictates the lifetime of the DSA, while the
CEKMaxDecrypts dictates how often rekeying will occur within the CMS
protocol. A content encryption key MUST NOT be reused once the DSA
has expired.
Implementations MUST be able to support a DSA-TTL of one day, and
nodes which support certificate checking (e.g. CRLs, OCSP) that are
re-establishing a DSA due to expiration of the TTL MUST re-validate
the certificate.
4.0 Command-Codes Values
This section defines new Command-Code [BASE] values that MUST be
supported by all Diameter implementations that conform to this
specification. The following Command Codes are currently defined in
this document:
Command-Name Abbrev. Code Reference
--------------------------------------------------------
Diameter-Security- DSAR 304 4.1
Association-Request
Diameter-Security- DSAA 304 4.2
Association-Answer
Proxy-Diameter-Security- PDSR 305 4.3
Association-Request
Proxy-Diameter-Security- PDSA 305 4.4
Association-Answer
4.1 Diameter-Security-Association-Request
The Diameter-Security-Association-Request command, indicated by the
Command-Code field set to 304 and the 'R' bit set in the message
flags field, is sent by a Diameter node to establish a Diameter
Security Association. The DSAR message MUST NOT be used simply as a
convenient certificate distribution protocol without establishing a
DSA. The CMS-Signed-Data AVP MUST be present if any AVP in the
message has the 'P' bit set.
Message Format
Calhoun, Farrell, Bulley,expires September 2002 [Page 18]
Internet-Draft March 2002
<DSAR> ::= < Diameter-Header: 304, REQ, PXY >
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Auth-Application-Id }
{ OCSP-Request-Flags }
{ DSA-TTL }
* { Local-CA-info }
0*1[ CA-Chain ]
* [ AAA-Node-Cert ]
0*1[ OCSP-Nonce ]
0*1[ Origin-State-Id ]
0*1[ Destination-Host ]
0*1[ CMS-Signed-Data ]
* [ AVP ]
* [ Proxy-Info ]
* [ Route-Record ]
4.2 Diameter-Security-Association-Answer
The Diameter-Security-Association-Answer command, indicated by the
Command-Code field set to 304, with the 'R' bit in the Command Flags
cleared, in response to a DSAR. The CMS-Signed-Data AVP MUST be
present if any AVP in the message has the 'P' bit set. If the Result-
Code AVP indicates success, the CA-Chain, AAA-Node-Cert, DSA-TTL and
CMS-Signed-Data AVPs MUST be present.
Message Format
<DSAA> ::= < Diameter-Header: 304, PXY >
{ Result-Code }
{ Origin-Host }
{ Auth-Application-Id }
{ DSA-TTL }
* { Local-CA-info }
0*1[ CA-Chain ]
* [ AAA-Node-Cert ]
0*1[ Origin-Realm ]
0*1[ Error-Message ]
0*1[ Error-Reporting-Host ]
* [ OCSP-Responses ]
0*1[ CMS-Signed-Data ]
0*1[ Origin-State-Id ]
* [ AVP ]
* [ Proxy-Info ]
Calhoun, Farrell, Bulley,expires September 2002 [Page 19]
Internet-Draft March 2002
4.3 Proxy-Diameter-Security-Association-Request
The Proxy-Diameter-Security-Association-Request command, indicated by
the Command-Code field set to 305 and the 'R' bit set in the Command
Flags field, is sent by a Diameter node to request that a downstream
proxy establishes a Diameter Security Association with a server in a
given realm on its behalf.
Message Format
<PDSR> ::= < Diameter-Header: 305, REQ, PXY >
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Auth-Application-Id }
0*1[ DSAR-Target-Realm ]
0*1[ Origin-State-Id ]
0*1[ Destination-Host ]
* [ AVP ]
* [ Proxy-Info ]
* [ Route-Record ]
4.4 Proxy-Diameter-Security-Association-Answer
The Proxy-Diameter-Security-Association-Answer command, indicated by
the Command-Code field set to 305 and the 'R' bit cleared in the
Command Flags field, is sent by a Diameter node in response to an
PDSR message.
Message Format
<PDSA> ::= < Diameter-Header: 305, PXY >
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
{ Auth-Application-Id }
{ DSA-TTL }
0*1[ Error-Message ]
0*1[ Error-Reporting-Host ]
0*1[ Origin-State-Id ]
* [ Redirect-Host ]
0*1[ Redirect-Host-Usage ]
0*1[ Redirect-Max-Cache-Time ]
* [ AVP ]
* [ Proxy-Info ]
Calhoun, Farrell, Bulley,expires September 2002 [Page 20]
Internet-Draft March 2002
5.0 Diameter Security Association Message Flow
This section contains an example of a NAS in realm xyz.com,
communicating with its local relay agent, which in turn communicates
with a server in ABC.COM's network. In the following example, once
the initial capabilities exchange is complete, the NAS receives a
request for access from alice@abc.com, which causes the DSA setup to
be initiated, followed by the application-specific authentication
request.
Although the example doesn't specifically use bi-directional digital
signature and encryption, this feature is supported.
+-------+ +-------+ +---------+
| NAS | | Relay | | abc.com |
| | | Agent | |Home Srv |
+-------+ +-------+ +---------+
| | |
|CER apps 1, 2 | |
(a) |------------------->| |
|CAA apps -1 | |
(b) |<-------------------| |
| . |CER apps 1, 2 |
(c) | |<-------------------|
| |CEA apps -1 |
(d) | |------------------->|
->| User alice@abc.com | |
(e) | Requests Access | |
| | |
| DSAR | |
| Dest-Realm=abc.com | |
(f) |--------------------+------------------->|
| | DSAA |
| | Origin-Host=foo |
(g) |<-------------------+--------------------|
| Auth-Request + | |
| CMS-Signed-Data | |
| Dest-Host=foo | |
(h) |--------------------+------------------->|
| | Auth-Answer + |
| | CMS-Encrypted-Data |
(i) |<-------------------+--------------------|
Figure 6: Example of a DSA Setup
(a) NAS sends a CER message to its relay agent indicating that it
supports applications 1 (NASREQ) and 2 (CMS Security).
(b) The relay agent sends a CEA message to the NAS indicating that
Calhoun, Farrell, Bulley,expires September 2002 [Page 21]
Internet-Draft March 2002
it is a relay supporting all Diameter applications.
(c) ABC.COM's Home Server sends a CER message to a relay agent
indicating that it supports applications 1 (NASREQ) and 2
(CMS Security).
(d) The relay agent sends a CEA message to ABC.COM's Home Server
indicating that it is a relay supporting all Diameter
applications.
(e) The NAS receives a request for access from a user
(alice@abc.com).
(f) The NAS issues an DSAR message, with the Destination-Realm AVP
set to abc.com.
(g) ABC.COM's Home Server processes the DSAR message, and replies
with the DSAA message.
(h) The NAS issues an authentication request with the Destination-
Host AVP set to the value of the Origin-Host AVP in the DSAA.
The message includes the CMS-Signed-AVP, which authenticates
the AVPs that were requested by the Home Server in the DSAA.
(i) The Home Server successfully authenticates the user, and
returns a reply, which includes the CMS-Encrypted-Data AVP,
whose contents include the AVPs that require encryption.
6.0 CMS Security AVPs
This section contains AVPs that are used to establish a Diameter
Security Association, and to transport CMS objects. Except as
specifically constrained, the profile of CMS algorithm and structure
usage is as specified in the S/MIME v3 message specification [MSG].
Calhoun, Farrell, Bulley,expires September 2002 [Page 22]
Internet-Draft March 2002
+---------------------+
| AVP Flag rules |
|----+-----+----+-----|----+
AVP Section | | |SHLD| MUST|MAY |
Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr|
-----------------------------------------|----+-----+----+-----|----|
AAA-Node-Cert 351 6.6 OctetString|M,P | | | V | N |
CA-Chain 353 6.8 OctetString| M | P | | V | N |
CA-Name 349 6.4.1 UTF8String | M | P | | V | N |
CMS-Encrypted- 355 6.2 OctetString| M | P | | V | N |
Data | | | | | |
CMS-Signed-Data 310 6.1 OctetString| M | | | P,V | N |
DSA-TTL 362 6.11 Unsigned32 | M | P | | V | N |
DSAR-Target- 360 6.10 UTF8String | M | P | | V | N |
Realm | | | | | |
Key-Hash 350 6.4.2 OctetString| M | P | | V | N |
Local-CA-Info 348 6.4 Grouped | M | P | | V | N |
OCSP-Nonce 358 6.5 OctetString| M | P | | V | N |
OCSP-Request- 361 6.9 Enumerated | M | P | | V | N |
Flags | | | | | |
OCSP-Responses 359 6.7 OctetString| M | P | | V | N |
The profile of CMS algorithm and structure usage is conformant to
that specified in the S/MIME v3 message specification [MSG]. This
makes is simpler to base an implementation of this specification upon
an existing S/MIME toolkit.
No MIME encoding of binary data is required for this specification.
This is different from the use of CMS in S/MIME, but is acceptable
since Diameter is a binary protocol and investigation has not shown
this to cause problems when using existing CMS & S/MIME toolkits.
6.1 CMS-Signed-Data AVP
The CMS-Signed-Data AVP (AVP Code 310) is of type OctetString and
contains the Basic Encoding Rules (BER) encoding of a CMS object
[CMS] of type ContentInfo. This means that where a set of AVPs is to
be signed, the set of AVPs with the 'P' bit set MUST first be
catenated together in the order in which they occur in the Diameter
message. The result of this encoding is used as input into the
signing process.
Note that the AVPs themselves are not encapsulated within the CMS-
Signed-Data AVP. Instead, the digest value of the AVPs produced in
the signature process MUST be included in the CMS-Signed-Data AVP, as
a message-digest attribute (defined in section 11.2 of [CMS]) in the
Calhoun, Farrell, Bulley,expires September 2002 [Page 23]
Internet-Draft March 2002
SignerInfo value.
Multiple Diameter entities MAY add their signatures to an existing
CMS-Signed-Data AVP. Multiple signatures are added within the
countersignature attribute (defined in section 11.4 of [CMS]) and not
as additional SignerInfo values. The countersignature attribute
requires that the signatures occur sequentially, meaning that each
signature covers the existing signatures in the CMS object.
The initial signature, and any additional countersignatures, MUST
cover the exact same set of AVPs, in the order they are present in
the message.
Note that the CMS-Signed-Data AVP itself MUST NOT be used in the
generation of the signature, and therefore MUST NOT have its 'P' bit
set.
The eContent field of the EncapsulatedContentInfo structure MUST be
absent since the digital signature covers data outside of the object.
If a receiver cannot verify correctly the signature carried by the
CMS-Signed-Data AVP, it SHOULD return the DIAMETER_INVALID_AUTH
Result-Code AVP value defined in section 7.1.
When AVPs are to be both encrypted and signed, the CMS-Encrypted-Data
AVP MUST be created first. This AVP MUST then have the 'P' bit set
and be one of the inputs to the signing process as described above.
(Any other processing resulting in the same output can be used.) This
means that signing is "outside" encryption.
No more than one CMS-Signed-Data AVP MUST be present in any given
Diameter message.
6.2 CMS-Encrypted-Data AVP
The CMS-Encrypted-Data AVP (AVP Code 355) is of type OctetString with
the OctetString containing the Basic Encoding Rules (BER) encoding of
a CMS object [CMS] of type ContentInfo.
All AVPs to be encrypted are concatenated. This value is then:
- encrypted according to normal CMS rules,
- used as the value of the EncryptedContent field within
EnvelopedData.
The contentType of the EncryptedContentInfo value MUST be id-
data [MSG].
Calhoun, Farrell, Bulley,expires September 2002 [Page 24]
Internet-Draft March 2002
A CMS-Encrypted-Data AVP contains exactly one EnvelopedData.
Where one or more AVP would be encrypted within separate
EnvelopedData structures, then separate CMS-Encrypted-Data AVPs
MUST be used.
Thus, implementations MUST be able to support the presence of
multiple CMS-Encrypted-Data AVPs and MUST be able to decrypt any
EnvelopedData for which it is a recipient, as indicated in the
EnvelopedData's RecipientInfos field [CMS].
If the recipient is not specified in a RecipientInfo, it MAY
choose to process the message or return an answer with the
Result-Code AVP set to DIAMETER_NO_DSA_RECIPIENT. If the
recipient is in the RecipientInfos and an error occurs during
decryption, then the recipient MUST answer with the Result-Code
set to DIAMETER_INVALID_AVP_VALUE.
Diameter nodes SHOULD implement content encryption key reuse
(see section 3.4 above).
If a receiver detects that the contents of the CMS-Encrypted-
Data AVP are invalid, it SHOULD answer with the Result-Code set
to DIAMETER_INVALID_CMS_DATA.
Zero or more CMS-Encrypted-Data AVP MAY be present in any
Diameter message.
6.3 Example Encodings
In order to clarify the contents of and the relationships between
CMS-Signed-Data and CMS-Encrypted-Data AVPs we present the following
example of how these AVPs are calculated.
First, some short-hand:
- The "|" character represents concatenation
- EnvelopedData-fnc(x,y) represents the EnvelopedData produced as
output of a function with x as the to-be-encrypted-data and y as
the parameters (e.g. recipient information).
- SignedData (y) represents the SignedData produced as output of a
function with the catenation of the 'P is set' AVPs as the
to-be-digested-data (which is not part of the output!) and y
as the parameters (e.g. signer information).
The scenario calls for a message containing 7 AVPs s,t,e,p,h,e' and n
to meet the following:
AVPs s, t and e are to be encrypted for recipient P.
Calhoun, Farrell, Bulley,expires September 2002 [Page 25]
Internet-Draft March 2002
AVPs e, p and h are to be encrypted for recipient A.
AVPs s, and e' are to be signed by originator T.
AVP s is to be sent to recipient A.
AVP n needs neither signing nor encryption.
Note that though there is no explicit requirement that AVP s be
encrypted for A, since it will be encrypted for P, we also have to
encrypt it for A. Implementations SHOULD NOT send the same AVP both
encrypted and in clear.
The resulting message will look like:
AVP1='P is set', EnvelopedData-fnc(s|t|e,P)
AVP2='P is set', EnvelopedData-fnc(s|e|p|h,A)
AVP3='P is set', e'
AVP4='P is clear', n
AVP5='P is clear', SignedData(T)
The result of this is that all AVPs except n are actually signed even
though signing of t and e wasn't explicitly required. However, this
is no harm.
6.4 Local-CA-Info AVP
The Local-CA-Info AVP (AVP Code 348) is of type Grouped. The Grouped
Data field has the following ABNF grammar:
Local-CA-Info ::= < AVP Header: 348 >
{ CA-Name }
{ Key-Hash }
6.4.1 CA-Name AVP
The CA-Name AVP (AVP Code 349) is of type UTF8String. The AVP
contains the DN (in LDAP string syntax [LDAPSTR]) of the Certificate
Authority, e.g. "CN=CA;O=Baltimore Technologies;C=IE".
6.4.2 Key-Hash AVP
The Key-Hash AVP (AVP Code 350) is of type OctetString, and contains
the SHA-1 hash of a public key.
The hash MUST be calculated over the representation of the CA public
key which would be present in an X.509 public key certificate,
specifically, the input for the hash algorithm MUST be the DER
encoding of a SubjectPublicKeyInfo representation of the key. Note:
This includes the AlgorithmIdentifier as well as the BIT STRING. The
Calhoun, Farrell, Bulley,expires September 2002 [Page 26]
Internet-Draft March 2002
rules given in [CERTPROF] for encoding keys MUST be followed.
Since this AVP is used for indexing and not for security (since
Diameter nodes SHOULD validate certificates), there is no need to
support more than one hash algorithm here.
6.5 OCSP-Nonce AVP
The OCSP-Nonce AVP (AVP Code 358) is of type OctetString, and
contains a random value (RECOMMENDED to be at least 128 bits)
generated by the Diameter node.
6.6 AAA-Node-Cert AVP
The AAA-Node-Cert AVP (AVP Code 351) is of type OctetString and
contains a public key certificate for the AAA node. Note: this AVP
contains no CA certificates, just the end-entity certificate.
Certificates MUST follow the naming conventions described in section
3.2.
6.7 OCSP-Responses AVP
The OCSP-Responses AVP (AVP Code 359) is of type OctetString, and
contains an OCSP response message from an OCSP responder. If the
OCSP-Request-Flags AVP indicating a response was required in the
corresponding request message, the OCSP-Responses AVP MUST be
present. Furthermore, the OCSP-Request-Flags AVP MAY request a fresh
OCSP response message, which MUST also include the OCSP-Nonce AVP.
6.8 CA-Chain AVP
The CA-Chain AVP (AVP Code 353) is of type OctetString, and contains
a certificate chain, from one of the nominated locally trusted CAs
down to the (one and only) CA which has issued the end entity
certificates in the AAA-Node-Cert AVP. The OctetString contains a CMS
"certs-only" message.
To produce this AVP in an DSAA message, one (and only one) of the
Local-CA-info values from the corresponding DSAR message is selected
(call this the "top" CA for the purposes of this description). This
AVP then contains a certificate path (in order) from the "top" CA
down to the (one and only) CA which has issued the end entity
certificate in the AAA-Node-Cert AVP. The (typically self-signed),
certificate of the "top" CA MUST NOT be included.
Calhoun, Farrell, Bulley,expires September 2002 [Page 27]
Internet-Draft March 2002
6.9 OCSP-Request-Flags AVP
The OCSP-Request-Flags AVP (AVP Code 361) is of type Enumerated, and
specifies whether the sender wishes to receive an OCSP response. The
following values are defined:
NO_OCSP_RESPONSE 0
The sender does not wish to receive an OCSP Response.
OCSP_RESPONSE 1
The sender wishes to receive an OCSP Response, and is willing
to accept a stale response.
OCSP_FRESH_RESPONSE 2
The sender wishes to receive a fresh OCSP Response. When this
value is set, the OCSP-Nonce AVP MUST be present.
6.10 DSAR-Target-Realm AVP
The DSAR-Target-Realm AVP (AVP Code 360) is of type UTF8String, and
contains the Destination-Realm of the resulting DSAR sent by a non-
transparent proxy.
6.11 DSA-TTL AVP
The DSA-TTL AVP (AVP Code 362) is of type Unsigned32, and contains
the time to live (in seconds) of the Diameter Security Association.
The expiration time (now+TTL) MUST NOT be greater than the earliest
expiration time (NotAfter field) of all certificates included in this
message accompanying this AVP. The DSA-TTL AVP in the DSAA MUST NOT
be greater than the DSA-TTL AVP in the DSAR. A DSA-TTL AVP MUST also
be included in the PDSA in order to provide information about the
lenght of the DSA established by the proxy on behalf of the access
device. Implementations MUST be able to support a DSL-TTL of one day.
7.0 Result-Code AVP Values
This section defines new Result-Code [BASE] values that MUST be
supported by all Diameter implementations that conform to this
specification.
7.1 Transient Failures
Errors that fall within the transient failures category are used to
Calhoun, Farrell, Bulley,expires September 2002 [Page 28]
Internet-Draft March 2002
inform a peer that the request could not be satisfied at the time it
was received, but MAY be able to satisfy the request in the future.
DIAMETER_KEY_UNKNOWN 4008
This error code is returned when a CMS-Signed-Data or CMS-
Encrypted-Data AVP is received that was generated using a key
that is not locally recognized. This error could be caused if
one of the participants of a DSA lost a previously agreed upon
key, perhaps as a result of a reboot.
DIAMETER_NO_CMS_THROUGH_PROXY 4009
This error code is returned when a non-transparent proxy
receives an DSAR message to state that it doesn't allow a DSA
through it since it plans to modify AVPs.
DIAMETER_CAN_ACT_AS_CMS_PROXY 4010
This error code is returned when a non-transparent proxy
receives an DSAR message, and although it doesn't allow a DSA
through it, it is willing to initiate a DSA on behalf of the
access device.
DIAMETER_OCSP_NOT_SUPPORTED 4011
This error code is returned when a DSAR message is received
requesting OCSP validation, and the receiver does not support
OCSP.
DIAMETER_INVALID_AUTH 4012
The signature in the CMS-Signed-Data AVP is invalid.
DIAMETER_MISSING_SIGNED_AVPS 4013
Some AVPs within a Diameter message were expected to be signed.
7.2 Permanent Failures
Errors that fall within the permanent failures category are used to
inform the peer that the request failed, and should not be attempted
again.
DIAMETER_INVALID_CMS_DATA 5019
This error code is returned when a CMS-Data AVP is received
with an invalid ContentInfo object.
DIAMETER_NO_COMMON_TRUST 5020
This error code is returned when a receiver receives a DSAR for
which it has no common trust with the sender, which is required
to establish the DSA.
Calhoun, Farrell, Bulley,expires September 2002 [Page 29]
Internet-Draft March 2002
DIAMETER_NO_DSA_ESTABLISHED 5021
A Diameter message refers to a Diameter Security Association
which does not exist.
DIAMETER_DSA_EXPIRED 5022
A Diameter message refers to a Diameter Security Association
which has expired.
DIAMETER_NO_DSA_RECIPIENT 5023
A Diameter message was received with encrypted data, and the
local Diameter node is not a potential recipient of the
EnvelopedData.
8.0 AVP Occurrence Tables
The table in this section presents the AVPs defined in this document,
and specifies in which Diameter messages they MAY, or MAY NOT be
present. Note that AVPs that can only be present within a Grouped
AVP are not represented in this table.
The table uses the following symbols:
0 The AVP MUST NOT be present in the message.
0+ Zero or more instances of the AVP MAY be present in the
message.
0-1 Zero or one instance of the AVP MAY be present in the
message.
1 One instance of the AVP MUST be present in the message.
1+ At least one instance of the AVP MUST be present in the
message.
Calhoun, Farrell, Bulley,expires September 2002 [Page 30]
Internet-Draft March 2002
+-----------------------+
| Command-Code |
|-----+-----+-----+-----+
Attribute Name | DSAR| DSAA| PDSR| PDSA|
------------------------------|-----+-----+-----+-----+
Auth-Application-Id | 1 | 1 | 1 | 1 |
Destination-Host | 0-1 | 0 | 0 | 0 |
Destination-Realm | 1 | 0 | 1 | 0 |
Error-Message | 0 | 0-1 | 0 | 0-1 |
Error-Reporting-Host | 0 | 0-1 | 0 | 0-1 |
AAA-Node-Cert | 0-1 | 0-1 | 0 | 0 |
CA-Chain | 0-1 | 0-1 | 0 | 0 |
CA-Name | 0 | 0 | 0 | 0 |
CMS-Encrypted-Data | 0 | 0 | 0 | 0 |
CMS-Signed-Data | 0-1 | 0-1 | 0 | 0 |
DSA-TTL | 1 | 1 | 0 | 0 |
DSAR-Target-Realm | 0 | 0 | 0-1 | 0 |
Local-CA-Info | 0+ | 0+ | 0 | 0 |
OCSP-Nonce | 0-1 | 0 | 0 | 0 |
OCSP-Request-Flags | 1 | 0 | 0 | 0 |
OCSP-Responses | 0 | 1+ | 0 | 0 |
Origin-Host | 1 | 1 | 1 | 1 |
Origin-Realm | 1 | 1 | 1 | 1 |
Original-State-Id | 0-1 | 0-1 | 0-1 | 0-1 |
Proxy-Info | 0+ | 0+ | 0+ | 0+ |
Redirect-Host | 0 | 0+ | 0 | 0+ |
Redirect-Host-Usage | 0 | 0-1 | 0 | 0-1 |
Redirect-Max-Cache-Time | 0 | 0-1 | 0 | 0-1 |
Result-Code | 0 | 1 | 0 | 1 |
Route-Record | 0+ | 0 | 0+ | 0 |
------------------------------|-----+-----+-----+-----|
9.0 IANA Considerations
This section contains the namespaces that have either been created in
this specification, or the values assigned to existing namespaces
managed by IANA.
9.1 Command Codes
This specification assigns the value 304 and 305 from the Command
Code namespace defined in [BASE]. See section 4.0 for the assignment
of the namespace in this specification.
9.2 AVP Codes
Calhoun, Farrell, Bulley,expires September 2002 [Page 31]
Internet-Draft March 2002
This specification assigns the values 348-351, 353, 355, 358-362 from
the AVP Code namespace defined in [BASE]. See section 6.0 for the
assignment of the namespace in this specification.
9.3 Result-Code AVP Values
This specification assigns the values 4008-4011, 5019-5023 from the
Result-Code AVP (AVP Code 268) value namespace defined in [BASE]. See
section 7.0 for the assignment of the namespace in this
specification.
9.4 Application Identifier
This specification assigns the value two (2) to the Application
Identifier namespace defined in [BASE]. See section 1.6 for more
information.
9.5 OCSP-Request-Flags AVP Values
As defined in Section 6.9, the OCSP-Request-Flags AVP (AVP Code 361)
defines the values 0-2. All remaining values are available for
assignment via IETF Consensus [HUH???????].
10.0 Security Considerations
This document describes how CMS security can be achieved in the
Diameter protocol by allowing S/MIME Cryptographic Message Syntax
[CMS] objects to be carried as a Diameter AVP.
This specification does not mandate certificate revocation, however
not verifying whether a given certificate has been revoked has
serious implications, and MAY create a security hole.
The PDSR and PDSA messages (sections 4.3 and 4.4) allow a third party
proxy to establish a Diameter security association with a Diameter
server in a target realm. An access device MUST ensure that the
server establishing the SA on its behalf is a trusted entity, since
the proxy in question could modify Diameter messages, which would be
very difficult to trace.
11.0 References
Calhoun, Farrell, Bulley,expires September 2002 [Page 32]
Internet-Draft March 2002
Normative References
[BASE]
P. Calhoun, J. Arkko, E. Guttman, G. Zorn, J. Loughney, "Diameter
Base Protocol", draft-ietf-aaa-diameter-09.txt, IETF work in
progress, March, 2002.
[CERTLDAP]
Boyen, Howes, Richard, "Internet X.509 Public Key Infrastructure
Operational Protocols - LDAPv2", RFC 2559, April 1999.
[CERTPROF]
Housley, Ford, Polk, Solo, "Internet X.509 Public Key Infrastruc-
ture Certificate and CRL Profile", RFC 2459, January 1999.
[CMS]
R. Housley, "Cryptographic Message Syntax", RFC 2630, June 1999.
[LDAPSTR]
M. Wahl, S. Kille, T. Howes, "Lightweight Directory Access Protocol
(v3): UTF-8 String Representation of Distinguished Names", RFC
2253, December 1997.
[MSG]
B. Ramsdell, "S/MIME Version 3 Message Specification", RFC 2633,
June 1999.
[MUSTSHOULD]
S. Bradner, "Key words for use in RFCs to Indicate Requirement Lev-
els", BCP 14, RFC 2119, March 1997.
[OCSP]
Myers, Ankney, Malpani, Galperin, Adams, "X.509 Internet Public Key
Infrastructure Online Certificate Status Protocol (OCSP)", RFC
2560, June 1999.
[RCEK]
Farrell, Turner, "Reuse of CMS Content Encryption Keys", RFC 3185,
October 2001.
Informative References
[AAAREQS]
Aboba et al., "Criteria for Evaluating AAA Protocols for Network
Access", RFC 2989, November 2000.
Calhoun, Farrell, Bulley,expires September 2002 [Page 33]
Internet-Draft March 2002
[CDMAREQ]
T. Hiller et al., "Cdma2000 Wireless Data Requirements for AAA",
RFC 3141, June 2001.
[MIPREQ]
S. Glass, S. Jacobs, C. Perkins, "Mobile IP Authentication, Autho-
rization, and Accounting Requirements". RFC 2977. October 2000.
12.0 Acknowledgements
The authors would also like to acknowledge the following people for
their contribution in the development of this specification:
Bernard Aboba, Jari Arkko, Steven Bellovin and Miguel A. Monjas
Finally, Pat Calhoun would like to thank Sun Microsystems since most
of the effort put into this document was done while he was in their
employ.
13.0 Authors' Addresses
Questions about this memo can be directed to:
Pat R. Calhoun
Black Storm Networks
250 Cambridge Avenue, Suite 200
Palo Alto, California, 94306
USA
Phone: +1 650-617-2932
Fax: +1 650-786-6445
E-mail: pcalhoun@diameter.org
Stephen Farrell
Baltimore Technologies
39 Parkgate Street,
Dublin 8,
IRELAND
Phone: +353-1-881-6000
Fax: +353-1-881-7000
E-Mail: stephen.farrell@baltimore.ie
William Bulley
Calhoun, Farrell, Bulley,expires September 2002 [Page 34]
Internet-Draft March 2002
Merit Network, Inc.
Building One, Suite 2000
4251 Plymouth Road
Ann Arbor, Michigan, 48105-2785
USA
Phone: +1 734-764-9993
Fax: +1 734-647-5185
E-mail: web@merit.edu
14.0 Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished
to others, and derivative works that comment on or otherwise
explain it or assist in its implementation may be prepared, copied,
published and distributed, in whole or in part, without restric-
tion of any kind, provided that the above copyright notice and
this paragraph are included on all such copies and derivative
works. However, this docu- ment itself may not be modified in any
way, such as by removing the copyright notice or references to the
Internet Society or other Inter- net organizations, except as needed
for the purpose of developing Internet standards in which case
the procedures for copyrights defined in the Internet Standards pro-
cess must be followed, or as required to translate it into languages
other than English. The limited permis- sions granted above are
perpetual and will not be revoked by the Internet Society or
its successors or assigns. This document and the information con-
tained herein is provided on an "AS IS" basis and THE INTERNET
SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WAR-
RANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WAR-
RANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE."
15.0 Expiration Date
This memo is filed as <draft-ietf-aaa-diameter-cms-sec-04.txt> and
expires in September 2002.
Calhoun, Farrell, Bulley,expires September 2002 [Page 35]
| PAFTECH AB 2003-2026 | 2026-04-20 22:36:15 |