[Search] [pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04                                                
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]