One document matched: draft-ietf-aaa-diameter-cms-sec-00.txt
Individual Contribution Pat R. Calhoun
Internet-Draft Sun Microsystems, Inc.
Category: Standards Track Stephen Farrell
<draft-ietf-aaa-diameter-cms-sec-00.txt> Baltimore Technologies
William Bulley
Merit Network, Inc.
June 2001
Diameter CMS Security Application
Status of this Memo
This document is an Internet-Draft and is in full conformance with
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/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at:
http://www.ietf.org/shadow.html.
Distribution of this memo is unlimited.
Copyright (C) The Internet Society 2001. All Rights Reserved.
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.
Calhoun, Bulley, Farrell expires December 2001 [Page 1]
Internet-Draft June 2001
This Diameter application describes how a security association is
established by two peers through agents, and how authentication and
confidentiality is achieved using a mixture of symmetric and
asymmetric transforms, by encapsulating Cryptographic Message Syntax
(CMS) data within AVPs. CMS is also used to carry X.509 certificates.
Table of Contents
1.0 Introduction
1.1 Establishing Security Relationship through relay agents
1.2 Establishing Security Relationship through proxy agents
1.3 Using Redirector agents in lieu of DSA
1.4 When to use DSAs
1.5 Who can authorize users
1.6 Requirements language
1.7 Advertising application support
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 CMS-Cert AVP
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-Server-Certs AVP
6.7 OCSP-Responses AVP
6.8 CA-Chain AVP
6.9 Expected-Signed-AVP AVP
6.10 Expected-Encrypted-AVP AVP
6.11 AVP-Code AVP
6.12 OCSP-Request AVP
6.13 DSAR-Target-Domain AVP
7.0 Result-Code AVP Values
7.1 Transient Failures
7.2 Permanent Failures
Calhoun, Bulley, Farrell expires December 2001 [Page 2]
Internet-Draft June 2001
8.0 IANA Considerations
8.1 Command Codes
8.2 AVP Codes
8.3 Result-Code AVP Values
8.4 Application Identifier
8.5 OCSP-Request AVP Values
9.0 Security Considerations
10.0 References
11.0 Acknowledgements
12.0 Authors' Addresses
13.0 Full Copyright Statement
14.0 Expiration Date
Calhoun, Bulley, Farrell expires December 2001 [Page 3]
Internet-Draft June 2001
1.0 Introduction
The Diameter base protocol [1] 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 [1] for a more comprehensive definition of the role of relay and
proxy agents.
1.1 Establishing Security Relationship through relay agents
The ROAMOPS Working Group has defined a set of requirements in [10]
to allow for Diameter peers to communicate securely through Relay
agents. This requirement calls for AVP integrity and confidentiality
between two peers communicating through Relay agents. 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 |Relay | IPSec |Relay | 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
Calhoun, Bulley, Farrell expires December 2001 [Page 4]
Internet-Draft June 2001
from intermediate agents. Furthermore, the Mobile IP and NASREQ
Working Groups have stated in [6, 7, 8] that non-repudiation 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, Relay 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.
(Request) (Request) (Request)
[AVP(foo)=x] [AVP(foo)=x] [AVP(foo)=y]
+------+ -----> +------+ -----> +------+ -----> +------+
| | |Relay | |Relay | | 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 [3] in Diameter AVPs can provide
authentication, integrity and confidentiality. The CMS object MAY
also be used to transport X.509 certificates and revocation lists.
Establishing a DSA through relay agents requires that the initiator
issue 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, the participants MAY apply digital
signatures to protect one or more AVP 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 when the signature validation algorithm
would fail by either participant.
1.2 Establishing Security Relationship through proxy agents
Calhoun, Bulley, Farrell expires December 2001 [Page 5]
Internet-Draft June 2001
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.
Diameter messages between two participants of a DSA would fail
authentication if a proxy agent were to modify any protected AVPs.
Therefore proxy agents MUST NOT permit DSAs to be established through
it.
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) ESSR-Target-Domain = abc.com
---------------------------->
(DSAR) Destination-Realm = abc.com
<----------------------------
(DSAA) Result-Code = DIAMETER_SUCCESS
<-------------
(PDSA) Result-Code = DIAMETER_SUCCESS
Figure 3: Establishing Security through Proxy Agent
When an DSAR is received by a proxy agent, it has two options. First,
if MAY simply deny all DSA Setup Requests (DSAR) through it by
responding with the DSAA Result-Code AVP set to
DIAMETER_NO_CMS_THROUGH_PROXY. The access device can then determine
whether it is willing to provide service, based on its local policy.
Calhoun, Bulley, Farrell expires December 2001 [Page 6]
Internet-Draft June 2001
Alternatively, it MAY reject the DSAR, but set the Result-Code AVP to
DIAMETER_CAN_ACT_AS_CMS_PROXY, informing the initiator of the DSAR
that it is a proxy agent, but is willing to establish the DSA on its
behalf. The DSAA MUST be signed by the proxy agent, and include its
certificate, to allow the access device to validate the originator of
the DSAA. At this point, the access device MUST determine whether the
proxy agent is a trusted agent, and it is willing to allow the agent
to provide such service. For instance, the access device MAY be
configured to ONLY accept DSAA with this result code from proxy
agents within its own domain.
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.
Allowing the first hop agent to use 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.3 Using Redirector agents in lieu of DSA
When a redirect agent is used, allowing the access device, or first
hop relay or proxy agent, to communicate directly with the home
server. In such configurations, the hop-by-hop security mechanisms
specified in the base protocol MAY be sufficient.
However, there are certain business models where signing of select
Diameter AVPS (e.g. accounting) MAY be desired. 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. The response from the redirect agent MAY include the
certificates of the home servers, encoded within the CMS-Cert AVP.
Calhoun, Bulley, Farrell expires December 2001 [Page 7]
Internet-Draft June 2001
+------+
| |
| 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 countersigned,
which MAY prove useful in business models that require both parties
to sign accounting data. This scheme provides some assurance that
both parties agreed to the accounting data, which MAY be used for
settlement purposes.
1.4 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.5 Who can authorize users
In this specification, we define how a Diameter Security Association
is established at the application layer to secure AVPs within a
message. However, it is important to note that one of participants
of a DSA (specifically the one in the home network) MUST belong to
the same realm as the user being authorized. This limitation will
prevent bigco.com from authorizing (or rather declining
authorization) for users at smallco.com. The realm of the
participants is found in the subjectAltName field of the Diameter
server's X.509 certificate.
1.6 Requirements language
Calhoun, Bulley, Farrell expires December 2001 [Page 8]
Internet-Draft June 2001
In this document, the key words "MAY", "MUST", "MUST NOT",
"optional", "recommended", "SHOULD", and "SHOULD NOT", are to be
interpreted as described in [5].
1.7 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 [1].
2.0 AVP Format
The Diameter base protocol [1] 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.5 of [1] and section 6 below.
AVPs that are designed to be changed at each hop (such as the Proxy-
Info AVP) MUST NOT allow the 'P' bit to be set.
3.0 Key Management
For DSA 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.
Calhoun, Bulley, Farrell expires December 2001 [Page 9]
Internet-Draft June 2001
However, for encryption of AVPs more work is needed. In order to be
able 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. using LDAP [16]), however, in order
to simplify Diameter implementations a specific Diameter key
distribution mechanism is defined here.
Another issue that must be addressed is how a Diameter node is to
"know" that certain AVPs are required to be secured within CMS
objects. This is communicated in the Diameter Security Association
Request/Answer messages, listed in section 4.0.
Finally, this section addresses the certificate profile to be used
for this Diameter application, which is a simplified profile of [4].
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.
In the present discussion we assume that the Diameter node has not
cached any information. Where information can be cached this is
noted.
We use Diameter Security Association Request (DSAR) and Diameter
Security Association Answer (DSAA) messages to establish a DSA, which
specifies which AVPs should be authenticated and/or encrypted, 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:
- 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 list of AVPs that expected to be protected (and how) for this
realm
- (optionally) a flag indicating that the originating Diameter
node wishes to receive certificate status information (using
OCSP messages) in which case a nonce to be used by the
destination Diameter node in OCSP requests MAY also be
supplied. See [9] for details of the certificate status
protocol and messages.
Calhoun, Bulley, Farrell expires December 2001 [Page 10]
Internet-Draft June 2001
The destination node returns the DSAA message which contains:
- TTL for this SA (seconds)
- a chain of CA certificates (possibly empty)
- public key certificates for the AAA servers in the realm, all
of which MUST validate up to one of the CA's contained in the
ESSR message, via the chain of CA certificates above;
- a list of AVPs that expected to be protected (and how) for this
realm
- (optionally, if nonce received and OCSP supported) a list of
OCSP responses for the certificates in question, each of which
uses the nonce from the ESSR message
[Issue: If one OCSP responder is used, do we need to append to the
nonce for each request?]
The originating Diameter node now has to check the response. Any
failure results in error messages and auditing and not sending the
Diameter message.
Checks:
- the certificate chain selected is cryptographically correct,
passes the (relevant parts of the) rfc2459 path validation
algorithm and terminates at a CA mentioned in the DSAR message
- the realm part of the user's NAI must occur as a subjectAltName
(with the dNSName option) in the AAA server's certificate. This
dNSName MUST be of the form "Diameter-<XXX>.<domain>" where
<domain> is the FQDN's domain component and <XXX> can be
anything (e.g. "Diameter-1.baltimore.com", "Diameter-
west.sun.com") chosen by the AAA server administrator.
- the DSAA message MUST be digitally signed and the signature
MUST be validated and the signer's certificate chain MUST
terminate as a CA mentioned in the DSAR message
If certificate status (revocation) is an issue for the Diameter
node, then the DSAR message MAY contain a nonce value. The idea
is that the sender of the DSAA makes OCSP requests on behalf of
the Diameter node and returns the OCSP responses to the
Diameter node as part of the DSAR message. The use of the nonce
value ensures that the sender of the DSAA cannot return cached
or otherwise fake OCSP responses to the Diameter node.
The nonce value is to be (the beginning of) the nonce in the
OCSP response.
[Issue The reason for "beginning" above is that an OCSP
responder might produce an error if presented with the same
Calhoun, Bulley, Farrell expires December 2001 [Page 11]
Internet-Draft June 2001
nonce more than once.]
The DSAR MAY be signed. If the originating node has a private
key and protection expectations for AVPs are specified, then
the DSAR SHOULD be signed.
The DSAA MUST be signed by a Diameter agent or server within
the user's realm, to prevent an intermediate node from
modifying the protection expectations for AVPs.
If confidentiality or digital signature is required, then the
originating node prepares the CMS related AVPs as required.
3.2 Certificate Requirements
Certificates used for the purposes of Diameter MUST conform to the
PKIX profile [4], and MUST also include a Diameter node's FQDN, which
is typically added in the Host-Name AVP [1], as one of the values of
the subjectAltName extension of the Certificate. The FQDN is to be
encoded as an 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, and in no way
restricts a Diameter's host name.
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 Host-Name 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 an 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.
Calhoun, Bulley, Farrell expires December 2001 [Page 12]
Internet-Draft June 2001
Note also that the PKIX profile [4], section 4.1.2.6, specifies the
rules for the relationship between the subjectAltName extension and
the subject field of public key certificates.
[Issue: Future versions of this draft may specify a restricted
profile of [4] in order to simplify implementation.]
3.3 Algorithms
For all uses of CMS in this specification the mandatory to implement
algorithms are as follows:
- Asymmetric: RSA
- Hashing: SHA-1
- Signature: RSAwithSHA1
- Symmetric Encryption: 3DES
At some point in future, AES will replace 3DES.
3.4 Reuse of CMS Content Encryption Keys
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 [15]. The peers
MUST first take part in an DSAR/DSAA exchange in order to distribute
the required asymmetric keys.
Note that the use of symmetric keys does not provide "non-
repudiation".
[15] 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.
[ed: removed the text on using a cached asymmetric key to re-
establish the SA, since it really wasn't clear how that would work]
In [15], the default value for the maximum number of decryptions
allowed (CEKMaxDecrypts) when re-using a content encryption key is
100. In general this default SHOULD be used, but if a Diameter node
"knows" that more than one CMS-Encrypted-Data AVP will be exchanged
Calhoun, Bulley, Farrell expires December 2001 [Page 13]
Internet-Draft June 2001
between the nodes (based on the Expected-Encrypted-AVP settings
exchanged during the DSAR/DSAA exchange) then the CEKMaxDecrypts
setting MAY be set higher. Diameter nodes MUST be able to support a
maxDecrypts setting of 1000.
[Issue: Are there reasonable expectations for the highest MUST
support for maxDecrypts? Does the CMS protocol allow for time based
expiration as opposed to number of encryptions?]
4.0 Command-Codes Values
This section defines new Command-Code [1] 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.
Message Format
Calhoun, Bulley, Farrell expires December 2001 [Page 14]
Internet-Draft June 2001
<DSAR> ::= < Diameter-Header: 304, REQUEST >
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
+ { Local-CA-info }
{ Auth-Application-Id }
* { OCSP-Request }
[ Destination-Host ]
* [ Expected-Signed-AVP ]
* [ Expected-Encrypted-AVP ]
* [ OCSP-Nonce ]
0*1[ CMS-Signed-Data ]
[ Origin-State-Id ]
* [ 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.
Message Format
<DSAA> ::= < Diameter-Header: 304 >
{ Origin-Host }
{ Origin-Realm }
0*1{ CA-Chain }
+ { AAA-Server-Certs }
* { OCSP-Responses }
{ Destination-Host }
{ Auth-Application-Id }
* [ Expected-Signed-AVP ]
* [ Expected-Encrypted-AVP ]
[ CMS-Signed-Data ]
[ Origin-State-Id ]
* [ AVP ]
* [ Proxy-Info ]
* [ Route-Record ]
4.3 Proxy-Diameter-Security-Assocation-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
Calhoun, Bulley, Farrell expires December 2001 [Page 15]
Internet-Draft June 2001
proxy establishes an Security Association with a server in a given
domain on its behalf.
Message Format
<PDSR> ::= < Diameter-Header: 304, REQUEST >
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Auth-Application-Id }
{ DSAR-Target-Domain }
0*1[ CMS-Signed-Data ]
[ Origin-State-Id ]
* [ 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: 304 >
{ Origin-Host }
{ Origin-Realm }
{ Destination-Host }
{ Auth-Application-Id }
* [ Expected-Signed-AVP ]
* [ Expected-Encrypted-AVP ]
0*1[ CMS-Signed-Data ]
[ Origin-State-Id ]
* [ AVP ]
* [ Proxy-Info ]
* [ Route-Record ]
5.0 Diameter Security Association Message Flow
This section contains an example of a NAS in domain 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
Calhoun, Bulley, Farrell expires December 2001 [Page 16]
Internet-Draft June 2001
be initiated, followed by the application-specific authentication
request.
Although the example doesn't specifically use bi-directional CMS
authentication 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 | |
| CMS-Cert | |
(f) |--------------------+------------------->|
| | DSAA |
| | Origin-Host=foo |
| | CMS-Cert |
(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 proxy server sends a CEA message to the NAS indicating
that it is a relay supporting all Diameter applications.
(c) ABC.COM's Home Server sends a CER message to a proxy server
indicating that it supports applications 1 (NASREQ) and 2 (CMS
Security).
Calhoun, Bulley, Farrell expires December 2001 [Page 17]
Internet-Draft June 2001
(d) The proxy server 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, and its certificate in the CMS-Cert AVP. The
DSAR includes the set of AVPs that the NAS expects to be
encrypted, in the event that the home server returns messages
that contain these AVPs.
(g) ABC.COM's Home Server processes the DSAR message, and replies
with the DSAA message. The DSAA also includes the set of AVPs
that the home server is expecting to be authenticated, as well
as its certificate in the CMS-Cert AVP.
(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 were specified by the NAS
in the DSAR.
6.0 CMS Security AVPs
This section contains AVPs that are used to establish a Diameter
Security Association, and to transport CMS objects.
Calhoun, Bulley, Farrell expires December 2001 [Page 18]
Internet-Draft June 2001
+---------------------+
| AVP Flag rules |
|----+-----+----+-----|----+
AVP Section | | |SHLD| MUST|MAY |
Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr|
-----------------------------------------|----+-----+----+-----|----|
AAA-Server-Certs 351 6.6 OctetString| M | P | | V | N |
AVP-Code 352 6.11 Unsigned32 | M | P | | V | N |
CA-Chain 353 6.8 OctetString| M | P | | V | N |
CA-Name 349 6.4.1 OctetString| M | P | | V | N |
CMS-Cert 354 6.3 OctetString| 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 |
Key-Hash 350 6.4.2 OctetString| M | P | | V | N |
DSAR-Target- 360 6.13 OctetString| M | P | | V | N |
Domain | | | | | |
Expected-Signed- 356 6.9 Grouped |M,P | | | V | N |
AVP | | | | | |
Expected- 357 6.10 Grouped |M,P | | | V | N |
Encrypted-AVP | | | | | |
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.12 Unsigned32 | M | P | | V | N |
OCSP-Responses 359 6.7 OctetString| M | P | | V | N |
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 [3]
of type ContentInfo. The profile of CMS algorithm and structure usage
is as specified in the S/MIME v3 message specification [11]. This
means that where a set of AVPs is protected using CMS, the set MUST
first be encoded according to MIME encoding rules specified below.
This method of encapsulating AVPs allows existing S/MIME toolkits to
be used without changes in order to provide authentication within the
Diameter application layer.
To package a set of AVPs as a MIME type, AVPs with the 'P' bit are
first concatenated in the order in which they occur in the Diameter
message, including padding. The result 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 within the
SignedData structure contains the digest produced in the signature
process.
Multiple Diameter entities MAY add their signatures to an existing
Calhoun, Bulley, Farrell expires December 2001 [Page 19]
Internet-Draft June 2001
CMS-Signed-Data AVP using the countersignature attribute, defined in
section 11.4 of [3]. The countersignature attribute requires that the
signatures occur sequentially, meaning that each signature covers the
existing signatures in the CMS object.
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 MUST NOT be used in the generation
of the signature, and therefore MUST NOT have its 'P' bit set.
If a receiver detects that the contents of the CMS-Signed-Data AVP
are invalid, it SHOULD return the new Result-Code AVP value defined
in section 7.0.
When AVPs are to be both encrypted and signed, the CMS-Encrypted-Data
AVP MUST be created first. The resulting CMS object MUST then be MIME
encoded producing an application/pkcs7-mime MIME type which is then
used as the content of the EnvelopedData. This means that signing is
"outside" encryption.
The eContent field of the EncapsulatedContentInfo structure MUST be
absent since the authentication covers data outside of the object.
The signature is computed over all AVPs with the 'P' bit enabled. The
order of the AVPs MUST be preserved and the computation begins with
the first AVP immediately following the Diameter header. If the
signature cannot be verified correctly, a response with the Result-
Code AVP set to DIAMETER_INVALID_AUTH [1] MUST be returned.
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 and
contains the Basic Encoding Rules (BER) encoding of a CMS object [3]
of type ContentInfo.
The entire AVP MUST be input to the encryption process, in network
byte order, including any padding. All AVPs to be encrypted are
concatenated, and the encryptor is free to order AVPs in whatever way
it chooses. The value is then encrypted and used as the value of the
EncryptedContent field within CMSEnvelopedData.
If a receiver detects that the contents of the CMS-Data AVP is
invalid, it SHOULD return the new Result-Code AVP value defined in
Calhoun, Bulley, Farrell expires December 2001 [Page 20]
Internet-Draft June 2001
section 7.0.
When AVPs are to be both encrypted and authenticated, the CMS-
Encrypted-Data AVP MUST be created first.
Where AVPs are encapsulated within a CMS-Encrypted-Data AVP, the
eContentType of the EncapsulatedContentInfo MUST be id-data [11].
CMS-Encrypted-Data MAY contain more than one CMS object, that is,
implementations MUST be able to add a new CMS-Encrypted-Data AVP
value and also MUST be able to decrypt all CMS-Encrypted-Data AVP
values which are encrypted for them.
When a conforming implementation receives a Diameter message which
contains encrypted AVPs within a CMS EnvelopedData, the recipient
MUST check to see if it is on the list of recipients specified in the
RecipientInfos of the EnvelopedData. If not, the recipient MAY choose
to process the message or indicate an error. If the recipient is in
the RecipientInfos and an error occurs during decryption, then the
recipient MUST indicate an error.
Diameter nodes SHOULD implement content encryption key re-use (see
section 3.4 above).
Zero or more CMS-Encrypted-Data AVP MAY be present in any Diameter
message.
6.3 CMS-Cert AVP
The CMS-Cert AVP (AVP Code 354) is of type OctetString and contains a
"certs-only" CMS structure which is a degenerate form of CMS
structure containing only PKI related information (see section 3.6 of
[11] for details of the CMS certs-only structure).
The CMS-Cert AVP contains one or more public key certificates
(Certificate) and MAY optionally contains attribute certificates
(AttributeCertificate) as allowed by CMS. Other legacy formats
supported by CMS MUST NOT be used.
Support for use of the Certificate structure is REQUIRED, while
implementations MAY support use of the AttributeCertificate structure
as defined in the PKIX attribute certificate profile [12]. The latter
allows Diameter implementations to include a certificate from a
trusted party that they are authorized to emit the AVPs contained in
the message.
This use of the CMS-Cert AVP can be used to "push" public key and
Calhoun, Bulley, Farrell expires December 2001 [Page 21]
Internet-Draft June 2001
attribute certificates and CRLs using Diameter, which MAY be useful
in environments where repositories (e.g. LDAP servers) are either
not used or not available (e.g. due to crossing a domain boundary).
Conforming implementations MUST be able to emit a certs-only CMS
structure which contains relevant PKI related information and MUST be
able to process a CMS-Cert AVP which contains a certs-only CMS
structure. Of course, the recipient of such a certs-only CMS
structure SHOULD NOT use the PKI related information without first
verifying it, e.g. by checking that issuer's are trusted, signatures
verify etc.
A CRL [4] MAY also be provided in the crls field of the SignedData,
which MAY be used to assist in determining whether a certificate has
been revoked. Optionally, the Diameter node MAY check the status of
certificates using another mechanism, such as Online Certificate
Status Protocol (OCSP) [9].
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 OctetString, encoded in the
UTF-8 [24] format. The AVP contains the DN (in LDAP string syntax) 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
a SHA-1 hash of the 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
rules given in [4] for encoding keys MUST be followed.
Since this AVP is used for indexing and not for security (since
Calhoun, Bulley, Farrell expires December 2001 [Page 22]
Internet-Draft June 2001
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 128 bits) generated by the
Diameter node.
6.6 AAA-Server-Certs AVP
The AAA-Server-Certs AVP (AVP Code 351) is of type OctetString and
contains the certificates of the AAA Servers in the home domain.
Note: this AVP contains no CA certificates, just those for AAA
servers.
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 AVP indicating a response was required in the
corresponding request message, the OCSP-Response AVP MUST be present.
Furthermore, the OCSP-Request 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-Server-Certs AVP.
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 all the end entity
certificates in the AAA-Servers-AVP. The (typically self-signed),
certificate of the "top" CA MAY be included, or MAY be omitted.
[Issue: Whether the "top" CA cert should be included or not can be
determined later.]
Calhoun, Bulley, Farrell expires December 2001 [Page 23]
Internet-Draft June 2001
6.9 Expected-Signed-AVP AVP
The Expected-Signed-AVP AVP (AVP Code 356) is of type Grouped. The
Grouped Data field has the following ABNF grammar:
Expected-Signed-AVP ::= < AVP Header: 356 >
{ AVP-Code }
[ Vendor-Id ]
The Expected-Signed-AVP AVP contains an AVP code, which if sent by
the peer, MUST be authenticated via the CMS-Signed-Data AVP.
Vendor-Specific AVPs are represented by including the optional
Vendor-Id AVP.
If this AVP is present in the DSAR or DSAA, it MUST be authenticated
using the CMS-Signed-Data AVP.
6.10 Expected-Encrypted-AVP AVP
The Expected-Encrypted-AVP AVP (AVP Code 357) is of type Grouped.
The Grouped Data field has the following ABNF grammar:
Expected-Encrypted-AVP ::= < AVP Header: 357 >
{ AVP-Code }
[ Vendor-Id ]
The Expected-Encrypted-AVP AVP contains an AVP code, which if sent by
the peer, MUST be encrypted in the CMS-Encrypted-Data AVP. Vendor-
Specific AVPs are represented by including the optional Vendor-Id
AVP.
If this AVP is present in the DSAR or DSAA, it MUST be authenticated
using the CMS-Signed-Data AVP.
6.11 AVP-Code AVP
The AVP-Code AVP (AVP Code 352) is of type Unsigned32, and contains
the AVP Code of the AVP that is to be authenticated or encrypted.
6.12 OCSP-Request AVP
The OCSP-Request AVP (AVP Code 361) is of type Unsigned32, and
specifies whether the sender wishes to receive an OCSP response. The
following values are defined:
Calhoun, Bulley, Farrell expires December 2001 [Page 24]
Internet-Draft June 2001
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.13 DSAR-Target-Domain AVP
The DSAR-Target-Domain AVP (AVP Code 360) is of type OctetString, and
contains the Destination-Realm of the resulting DSAR sent by a non-
transparent proxy.
7.0 Result-Code AVP Values
This section defines new Result-Code [1] 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
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 4007
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.
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 5018
This error code is returned when a CMS-Data AVP is received
Calhoun, Bulley, Farrell expires December 2001 [Page 25]
Internet-Draft June 2001
with an invalid ContentInfo object.
DIAMETER_NO_CMS_THROUGH_PROXY 5019
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 5020
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.
8.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.
8.1 Command Codes
This specification assigns the value 304 from the Command Code
namespace defined in [1]. See section 4.0 for the assignment of the
namespace in this specification.
8.2 AVP Codes
This specification assigns the values 348-361 from the AVP Code
namespace defined in [1]. See section 6.0 for the assignment of the
namespace in this specification.
8.3 Result-Code AVP Values
This specification assigns the values 4007, 5018-5020 from the
Result-Code AVP (AVP Code 268) value namespace defined in [1]. See
section 7.0 for the assignment of the namespace in this
specification.
8.4 Application Identifier
This specification assigns the value two (2) to the Application
Identifier namespace defined in [1]. See section 1.6 for more
information.
Calhoun, Bulley, Farrell expires December 2001 [Page 26]
Internet-Draft June 2001
8.5 OCSP-Request AVP Values
As defined in Section 6.12, the OCSP-Request AVP (AVP Code 361)
defines the values 0-2. All remaining values are available for
assignment via IETF Consensus [12].
9.0 Security Considerations
This document describes how CMS security can be achieved in the
Diameter protocol by allowing S/MIME Cryptographic Message Syntax [3]
objects to be carried as a Diameter AVP.
Section 6.3 states that a certificate received in a CMS-Cert AVP
SHOULD NOT be used prior to cert verification. In most cases, the
verification will be according to the rules specified in [4],
however, some communities have indicated that they wish to be allowed
to specify alternative certificate verification mechanisms, hence the
"SHOULD NOT" rather than the more typical "MUST NOT". The authors do
however strongly RECOMMEND that the verification procedures specified
in [4] are always applied, regardless of whatever other verification
mechanisms are in use.
10.0 References
[1] P. Calhoun, H. Akhtar, J. Arkko, E. Guttman, A. Rubens, "Diame-
ter Base Protocol", draft-ietf-aaa-diameter-05.txt, IETF work in
progress, June 2001.
[2] Kaufman, Perlman, Speciner, "Network Security: Private Communi-
cations in a Public World", Prentice Hall, March 1995, ISBN 0-
13-061466-1.
[3] R. Housley, "Cryptographic Message Syntax", RFC 2630, June 1999.
[4] Housley, Ford, Polk, Solo, "Internet X.509 Public Key Infras-
tructure Certificate and CRL Profile", RFC 2459, January 1999.
[5] S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[6] M. Beadles, D. Mitton, "Criteria for Evaluating Network Access
Server Protocols", draft-ietf-nasreq-criteria-05.txt, IETF work
in progress, June 2000.
[7] T. Hiller et al., "Cdma2000 Wireless Data Requirements for AAA",
Calhoun, Bulley, Farrell expires December 2001 [Page 27]
Internet-Draft June 2001
draft-hiller-cdma2000-AAA-02.txt, IETF work in progress, Sep-
tember 2000.
[8] S. Glass, S. Jacobs, C. Perkins, "Mobile IP Authentication,
Authorization, and Accounting Requirements". RFC 2977. October
2000.
[9] Myers, Ankney, Malpani, Galperin, Adams, "X.509 Internet Public
Key Infrastructure Online Certificate Status Protocol (OCSP)",
RFC 2560, June 1999.
[10] Aboba, Zorn, "Criteria for Evaluating Roaming Protocols", RFC
2477, January 1999.
[11] B. Ramsdell, "S/MIME v2 Message Specification", RFC2633, June
1999.
[12] S. Farrell, R. Housley, "An Internet Attribute Certificate Pro-
file for Authorization", draft-ietf-pkix-ac509prof-06.txt, IETF
work in progress, January 2001.
[13] P. Calhoun, W. Bulley, G. Zorn, "Diameter NASREQ Application",
draft-ietf-aaa-Diameter-nasreq-05.txt, IETF work in progress,
June 2001.
[14] P. Calhoun, C. Perkins, "Diameter Mobile IP Application",
draft-ietf-aaa-Diameter-mobileip-05.txt, IETF work in progress,
June 2001.
[15] Farrell, Turner, "Reuse of CMS Content Encryption Keys", draft-
ietf-smime-rcek-02.txt, IETF work in progress, May 2001.
[16] Boyen, Howes, Richard, "Internet X.509 Public Key Infrastructure
Operational Protocols - LDAPv2", RFC 2559, April 1999.
11.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 and Steven Bellovin
12.0 Authors' Addresses
Questions about this memo can be directed to:
Calhoun, Bulley, Farrell expires December 2001 [Page 28]
Internet-Draft June 2001
Pat R. Calhoun
Network and Security Research Center, Sun Labs
Sun Microsystems, Inc.
15 Network Circle
Menlo Park, California, 94025
USA
Phone: +1 650-786-7733
Fax: +1 650-786-6445
E-mail: pcalhoun@eng.sun.com
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
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
13.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
Calhoun, Bulley, Farrell expires December 2001 [Page 29]
Internet-Draft June 2001
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 WARRAN-
TIES, 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."
14.0 Expiration Date
This memo is filed as <draft-ietf-aaa-diameter-cms-sec-00.txt> and
expires in December 2001.
Calhoun, Bulley, Farrell expires December 2001 [Page 30]
| PAFTECH AB 2003-2026 | 2026-04-21 18:26:29 |