[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04

AAA Working Group                                         Pat R. Calhoun
Internet-Draft                                      Black Storm Networks
Category: Standards Track                                Stephen Farrell
<draft-ietf-aaa-diameter-cms-sec-04.txt>          Baltimore Technologies
                                                          William Bulley
                                                     Merit Network, Inc.
                                                              March 2002



                   Diameter CMS Security Application



Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet- Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

Abstract

   The Diameter base protocol leverages either IPsec or TLS for
   integrity and confidentiality between two Diameter peers, and allows
   the peers to communicate through relay and proxy agents. Relay agents
   perform message routing, and other than routing AVPs, do not modify
   Diameter messages. Proxy agents, on the other hand, implement policy
   enforcement, and actively modify Diameter messages.

   This Diameter application describes how a security association is
   established by two peers through agents, and how authentication,
   integrity, confidentiality and data origin authentication are
   achieved using a mixture of symmetric and asymmetric transforms, by



Calhoun, Farrell, Bulley,expires September 2002                 [Page 1]


Internet-Draft                                                March 2002


   encapsulating Cryptographic Message Syntax (CMS) data within AVPs.
   CMS is also used to carry X.509 certificates.


Table of Contents

      1.0  Introduction
            1.1  Requirements language
            1.2  Establishing Security Relationship through relay agents
            1.3  Establishing Security Relationship through proxy agents
            1.4  Using Redirect agents in lieu of DSA
            1.5  When to use DSAs
            1.6  Advertising application support
            1.7  CMS Processing of Grouped AVPs.
      2.0  AVP Format
      3.0  Key Management
            3.1  Usage Scenario
            3.2  Certificate Requirements
            3.3  Algorithms
            3.4  Reuse of CMS Content Encryption Keys
      4.0  Command-Codes Values
            4.1  Diameter-Security-Association-Request
            4.2  Diameter-Security-Association-Answer
            4.3  Proxy-Diameter-Security-Association-Request
            4.4  Proxy-Diameter-Security-Association-Answer
      5.0  Diameter Security Association Message Flow
      6.0  Diameter Security AVPs
            6.1  CMS-Signed-Data AVP
            6.2  CMS-Encrypted-Data AVP
            6.3  Example Encodings
            6.4  Local-CA-Info AVP
                  6.4.1  CA-Name AVP
                  6.4.2  Key-Hash AVP
            6.5  OCSP-Nonce AVP
            6.6  AAA-Node-Cert AVP
            6.7  OCSP-Responses AVP
            6.8  CA-Chain AVP
            6.9  OCSP-Request-Flags AVP
            6.10 DSAR-Target-Realm AVP
            6.11 DSA-TTL AVP
      7.0  Result-Code AVP Values
            7.1  Transient Failures
            7.2  Permanent Failures
      8.0  AVP Occurrence Tables
      9.0  IANA Considerations
            9.1  Command Codes
            9.2  AVP Codes
            9.3  Result-Code AVP Values



Calhoun, Farrell, Bulley,expires September 2002                 [Page 2]


Internet-Draft                                                March 2002


            9.4  Application Identifier
            9.5  OCSP-Request-Flags AVP Values
      10.0 Security Considerations
      11.0 References
      12.0 Acknowledgements
      13.0 Authors' Addresses
      14.0 Full Copyright Statement
      15.0 Expiration Date











































Calhoun, Farrell, Bulley,expires September 2002                 [Page 3]


Internet-Draft                                                March 2002


1.0  Introduction

   The Diameter base protocol [BASE] leverages either IPsec or TLS for
   integrity and confidentiality between two Diameter peers. However,
   the Diameter protocol also allows peers to communicate through relay
   and proxy agents, and in such environments security information is
   lost at each agent.

   Relay agents perform message routing, and other than routing AVPs, do
   not modify Diameter messages. Proxy agents, on the other hand,
   implement policy enforcement, and actively modify Diameter messages.
   See [BASE] for a more comprehensive definition of the role of relay
   and proxy agents.

   There are two main techniques used in this specification.  Digital
   signatures (along with digital certificates) provide authentication,
   integrity and data origin authentication. Encryption provides
   confidentiality (using asymmetric techniques to encrypt a content
   encryption key, which is then used for bulk encryption). Both
   techniques can be used simultaneously to provide all the specified
   security services.

   This Diameter application makes use of Cryptographic Message Syntax
   (CMS), which is the method used to secure MIME (S/MIME) messages.
   This application was designed to allow Diameter implementations to
   use existing S/MIME toolkits in order to comply with this
   specification.

   This specification contains two different set of messages. The
   Diameter Security Association (DSA) messages are used to establish a
   security assocation, while the Proxy Diameter Security (PDS) messages
   are used to request that a security association be established by a
   third party.

   The following details the necessary support for both types of
   messages based on the type of Diameter node:
 - Diameter servers: MUST support DSA messages; MAY support PDS messages
 - Proxy agents: MUST support DSA messages; MUST support PDS messages
 - Diameter clients: SHOULD support DSA messages; MUST support PDS
   messages
 - Relay agents: MAY support DSA messages; MAY support PDS messages
 - Redirector agents: MAY support DSA messages; MAY support PDS messages


1.1  Requirements language

   In this document, the key words "MAY", "MUST", "MUST NOT",
   "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be



Calhoun, Farrell, Bulley,expires September 2002                 [Page 4]


Internet-Draft                                                March 2002


   interpreted as described in [MUSTSHOULD].


1.2  Establishing a Security Relationship through relay agents

   The AAA Working Group has defined a set of requirements in [AAAREQS]
   to allow for Diameter peers to communicate securely through Relay
   agents. This requirement calls for AVP integrity and confidentiality
   between two peers communicating through agents. The term agent is
   used in this specification for either a relay or a proxy agent.
   Figure 1 provides an example of two Diameter peers establishing a
   Diameter Security Association (DSA) through Relay agents. The
   participants of a DSA are the peers where the DSA setup messages
   terminate. In this example, the participants of the DSA would the NAS
   (access device), and the Home Server.

       mno.net           mno.net           xyz.net           abc.com
      +------+  <---->  +------+  <---->  +------+  <---->  +------+
      |      |   TLS    |Agent |  IPSec   |Agent |  IPSec   | Home |
      | NAS  |          |      |          |      |          |      |
      |      |          |  1   |          |  2   |          |Server|
      +------+          +------+          +------+          +------+
              <-------------------------------------------->
                      Diameter Security Association

                  Figure 1: Diameter Security Association

   When one or more agents are used between two communicating Diameter
   peers, the use of hop-by-hop security mechanisms (e.g.  TLS, IPSec)
   is unsuitable, since Diameter messages are processed at the
   application layer at each agent. Therefore, an alternative mechanism
   is required to protect portions of the message at the application
   layer.

   Allowing for a security association to be established through
   Diameter relays allows the participants of the DSA to detect whether
   protected AVPs have been modified en-route, and hides sensitive data
   from intermediate agents. Furthermore, the Mobile IP and NASREQ
   Working Groups have stated in [CDMAREQ, MIPREQ] that data origin
   authentication of Diameter data, such as Accounting related AVPs, is
   necessary.

   Figure 2 provides an example of a message sent by an access device
   (NAS), through Diameter relay agents, to its intended destination,
   the home server. In this example, Proxy 2 modifies the contents of
   the foo AVP, perhaps due to mis-configuration, or maliciously. This
   specification would allow the participants of the DSA to detect such
   a problem, as long as the AVP being modified was protected.



Calhoun, Farrell, Bulley,expires September 2002                 [Page 5]


Internet-Draft                                                March 2002


              (Request)         (Request)         (Request)
             [AVP(foo)=x]      [AVP(foo)=x]      [AVP(foo)=y]
      +------+  ----->  +------+  ----->  +------+  ----->  +------+
      |      |          |Relay |          |Proxy |          | Home |
      | NAS  |          |      |          |      |          |      |
      |      |          |  1   |          |  2   |          |Server|
      +------+  <-----  +------+  <-----  +------+  <-----  +------+
               (Answer)          (Answer)          (Answer)
             [AVP(foo)=b]      [AVP(foo)=b]      [AVP(foo)=a]

                  Figure 2: Diameter agent modifying AVP

   This document defines the Diameter commands that are used to
   establish a DSA through Diameter agents, and specifies how
   encapsulating CMS objects [CMS] in Diameter AVPs can provide
   authentication, integrity, confidentiality and data origin
   authentication. CMS objects MAY also be used to transport X.509
   certificates and revocation lists.

   Establishing a DSA through relay agents requires that the initiator
   issues a Diameter Security Association Request (DSAR) message. In the
   example provided in figure 1, NAS would issue the DSAR with the
   Destination-Realm AVP set to abc.com. The Home Server would process
   the request, and respond by issuing a Diameter Security Association
   Answer (DSAA) message. If the DSAA message contains a Result-Code
   indicating success, the DSA is established between the NAS and the
   home server.

   Once the DSA is established, participants with private keys MAY apply
   digital signatures to protect one or more AVPs within a message.  In
   the example provided in Figure 2, the Foo AVP would be protected by
   the digital signature, and any modification of the AVP by the relay
   agents, would be detected since the signature validation algorithm
   would fail.


1.3  Establishing Security Relationship through proxy agents

   As previously discussed, proxy agents typically modify Diameter
   messages to implement policy enforcement. An example of a proxy
   server would be an aggregating server, which typically sits one
   Diameter hop away from the access device, and enforces policy in
   order to protect the access device from receiving AVPs that could
   cause harm (e.g. excessive number of filters, unsupported tunneling
   protocol). Although in theory such checks could be performed on the
   access device, these devices are typically embedded systems, and not
   easily configurable. The proxy agent's behavior, on the other hand,
   is typically under control of the network operator.



Calhoun, Farrell, Bulley,expires September 2002                 [Page 6]


Internet-Draft                                                March 2002


   Diameter messages between two participants of a DSA would fail
   verification if a proxy agent were to modify any protected AVPs.

   Therefore proxy agents that modify AVPs MAY prevent the establishment
   of DSAs based on local configuration.

   In this section, we discuss the capabilities provided by this
   Diameter application which allow proxy agents to secure AVPs on
   behalf of an access device. The following scenarios are envisioned:

      - The access device does not have the cryptographic ability to
        handle CMS functions locally, and therefore requests such
        services from the local agent, such an an aggregating relay or
        proxy agent. The NAS may have been configured to always issue a
        PDSR to its local agent for CMS services. In such cases, the
        agent MUST select the values for the DSA-TTL.
      - The access device has the cryptographic ability to perform CMS
        functions, but a proxy agent is in the route towards the home
        server, and it returned a failure to the DSAR messages stating
        that it was not willing to allow the DSA to traverse through it.
        Such agents MAY attempt to re-use the values from the initial
        DSAR sent by the access device. In such cases,the PDSR initiator
        SHOULD include the Destination-Host AVP to ensure that the PDSR
        is received by the same proxy agent.
      - The access device may have the cryptographic ability to perform
        CMS functions locally, but does not request a DSAR to request a
        DSA.  The local agent, however, has been configured to establish
        DSAs with certain realms automatically, hiding the existence of
        the DSAs from the access device.

   In the above scenarios, the first two occur at the explicit request
   of the access device, while the last one occurs without any messaging
   from the access device. In the latter case, the proxy agent acts as
   an access device of sorts and the rules in section 1.2 should be used
   instead.

   When a local agent receives a DSAR, it has the following options:

      - The local agent rejects the DSAR by sending a DSAA message whose
        Result-Code AVP is set to DIAMETER_NO_CMS_THROUGH_PROXY. The
        DSAA SHOULD include the CMS-Signed-Data AVP, signed by the proxy
        agent, and include its certificate to allow the access device to
        validate the originator of the DSAA. The access device can then
        determine whether it is willing to provide service, based on its
        local policy.
      - The local agent rejects the DSAR by sending a DSAA message whose
        Result-Code AVP is set to DIAMETER_CAN_ACT_AS_CMS_PROXY,
        informing the access device that the agent is willing to



Calhoun, Farrell, Bulley,expires September 2002                 [Page 7]


Internet-Draft                                                March 2002


        establish the DSA on its behalf. The DSAA MUST include the CMS-
        Signed-Data AVP, signed by the proxy agent, and include its
        certificate to allow the access device to validate the
        originator of the DSAA. If the access device is willing to use
        the agent's services, it issues a Proxy-Diameter-Security-
        Association-Request (PDSR) which MUST contain the target realm.
        The local agent MAY use any of the parameters provided by the
        access device in the previous DSAR attempt when establishing the
        DSA.  Once the DSA is established, the agent MUST issue a Proxy-
        Diameter-Security-Association-Answer (PDSA). The PDSA MUST
        contain the TTL setting agreed by the proxy agent for its DSA.
        This information will allow the access device to re-issue a PDSR
        prior to the proxy's DSA expiry if it needs the DSA to remain
        active.

   Note that an access device MAY be configured to always issue a PDSR
   to its aggregating proxy, reducing the number of round trips.
   Similarly, an aggregating proxy MAY be configured to initiate an DSAR
   regardless of whether a PDSR was sent by the access device.


       mno.net           mno.net           xyz.net           abc.com
      +------+          +------+          +------+          +------+
      |      |          |Proxy |          |Relay |          | Home |
      | NAS  |          |      |          |      |          |      |
      |      |          |Agent |          |Agent |          |Server|
      +------+          +------+          +------+          +------+
            ------------->
            (DSAR) Destination-Realm = abc.com

            <-------------
            (DSAA) Result-Code = DIAMETER_CAN_ACT_AS_CMS_PROXY

            ------------->
            (PDSR) DSAR-Target-Realm = abc.com

                              ---------------------------->
                              (DSAR) Destination-Realm = abc.com

                              <----------------------------
                              (DSAA) Result-Code = DIAMETER_SUCCESS

            <-------------
            (PDSA) Result-Code = DIAMETER_SUCCESS

            Figure 3: Establishing Security through Proxy Agent

   An optimized approach also allows the PDSR to be sent by the access



Calhoun, Farrell, Bulley,expires September 2002                 [Page 8]


Internet-Draft                                                March 2002


   device without the DSAR-Target-Realm AVP. This message is used to
   inform the proxy that it MUST establish a DSA for all realms it will
   be communicating with on behalf of the access device. DSAs are
   typically established once the first request for a given realm has
   been recelived by the proxy agent, but it MAY establish certain DSAs
   with known realms in advance.

   If a DSA for a given realm cannot be established, the proxy agent
   MUST reject the access device's request, and set the Result-Code AVP
   to DIAMETER_NO_DSA_ESTABLISHED. Although the proxy agent MAY receive
   many PDSRs from access devices, only one DSA per realm need be
   established. Furthermore, the proxy is responsible for re-
   establishing the DSA prior to expiration without any involvement by
   the access device.

   It is important to note that proxy agents establishing DSA's on
   behalf of a client will most likely need to reorder AVPs during the
   encryption process, in order to fit the encrypted AVPs within a CMS-
   Encrypted-Data AVP. This is contrary to the rule established in the
   Diameter base protocol [BASE], which states that proxy agents SHOULD
   NOT reorder AVPs.

   Allowing the first hop agent to be used to establish the DSA with the
   home server may reduce the current concerns that the cryptographic
   operations resulting from this specification MAY overburden embedded
   access devices.


1.4  Using Redirect agents in lieu of DSA

   When a redirect agent is used, allowing an access device, relay or
   proxy agent to communicate directly with the home server, the hop-by-
   hop security mechanisms specified in the base protocol may be
   sufficient.

   However, there are certain business models where signing of selected
   Diameter AVPs (e.g. accounting) MAY be desired, even when redirect
   agents are used. Figure 4 shows an example where the relay agent
   contacts the redirect agent to retrieve the necessary information for
   it to communicate directly with the home server, which MAY include
   the home server's certificates.

   The relay agent MAY then initiate a DSA with the home server, using
   the certificates provided by the redirect agents.







Calhoun, Farrell, Bulley,expires September 2002                 [Page 9]


Internet-Draft                                                March 2002


                                 +------+
                                 |      |
                                 | DRD  |
                                 |      |
                                 +------+
                                  ^    |
                      2. Request  |    | 3. Redirection
                                  |    |    Notification
                                  |    v
      +------+    --------->     +------+     <-------->    +------+
      |      |    1. Request     |      |    4. DSAR/DSAA   |      |
      | NAS  |                   | DRL  |                   | HMS  |
      |      |    6. Answer      |      | 5. Request/Answer |      |
      +------+    <---------     +------+     <-------->    +------+
      mno.net                     mno.net                    abc.com

                  Figure 4: DSA Setup following redirect

   The CMS specification allows for Diameter AVPs to be multiply-signed
   (see section 6.1), which may prove useful in business models that
   require both parties to sign accounting data in parallel. This scheme
   provides some assurance that both parties agreed to the accounting
   data, which MAY be used for settlement purposes.


1.5  When to use DSAs

   Given that asymmetric transform operations are expensive, access
   devices and/or Diameter agents MAY wish to restrict establishment of
   a DSA to cases where the participants belong to a different
   administrative domain.


1.6  Advertising application support

   Diameter nodes conforming to this specification MAY advertise support
   by including the value of two (2) in the Auth-Application-Id or the
   Acct-Application-Id AVP of the Capabilities-Exchange-Request and
   Capabilities-Exchange-Answer command [BASE].

1.7 CMS Processing of Grouped AVPs.

   Grouped AVPs are processed as a whole, there is no partial signing or
   encryption mechanism defined.

   Only the P flag (resp. MAY Encr) setting for a Grouped AVP need be
   set to Y to allow the Grouped AVP to be signed (resp. encrypted).
   That is, the AVPs within the Grouped AVP need not have their "P" bit



Calhoun, Farrell, Bulley,expires September 2002                [Page 10]


Internet-Draft                                                March 2002


   set (resp. MAY Encr) in order to be part of a signed (resp.
   encrypted) Grouped AVP.

   Where a Grouped AVP is to be signed, implementations MAY set the "P"
   bit for each of the AVPs within the Grouped AVP. When verifying
   signatures over a Grouped AVP, implementations MUST NOT insist that
   the "P" bit has been set for AVPs within the group.

   Where a Grouped AVP is to be encrypted, implementations MUST NOT fail
   encryption due to one of the members of the group being defined so as
   to prevent encryption ("MAY Encr" set to "N").  Similarly following
   decryption, implementations MUST NOT produce an error if one of the
   group members is defined so as to prevent encryption. The Grouped AVP
   itself, of course, MUST be defined to allow encryption.

   Where a Grouped AVP is defined to disallow encryption then that
   Grouped AVP MUST NOT include any AVPs which are defined so as to
   allow encryption (since the member of the group might be erroneously
   sent in clear, if included in such a Grouped AVP).

2.0  AVP Format

   The Diameter base protocol [BASE] details the AVP header, which
   includes the 'P' bit, but does not specify how the 'P' bit is used.
   The 'P' bit, known as the protected AVP bit, is used to indicate
   whether the AVP is protected by a digital signature. When set, the
   AVP is protected and the contents cannot be changed by agents without
   detection.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           AVP Code                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |V M P r r r r r|                  AVP Length                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Vendor-ID (opt)                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Data ...
      +-+-+-+-+-+-+-+-+
                       Figure 5: Diameter AVP Header

   All Diameter specifications MUST specify whether the 'P' bit can be
   set or not, as is done in section 4.6 of [BASE] and section 6 below.
   For AVPs that are designed to be changed at each hop (such as the
   Proxy-Info AVP) Diameter nodes MUST NOT allow the 'P' bit to be set.

   Diameter implementations MUST check whether AVPs with their 'P' bit



Calhoun, Farrell, Bulley,expires September 2002                [Page 11]


Internet-Draft                                                March 2002


   set are allowed to have that setting. If not, an appropriate error
   message MUST be issued containing DIAMETER_INVALID_AVP_BIT_COMBO
   result code.


3.0 Key Management

   For origin authentication, CMS itself already provides sufficient key
   management without the need for additional specification. Basically,
   the originating Diameter node signs and includes whatever
   certificates are necessary for validation of the digital signature.
   Section 3.1 provides an example of how the Diameter CMS Security
   application is used.

   In order to encrypt AVPs for a recipient, the originating Diameter
   node must have a copy of the recipient's public key. There are many
   well-known key retrieval schemes (e.g. LDAP [CERTLDAP]), but this
   specification also allows for the transportation of certificates
   within Diameter AVPs, which is expected to simplify implementations.
   Section 3.2 describes how Diameter node names are encoded within such
   certificates.

   Finally, it is anticipated that the overhead of asymmetric encryption
   for each Diameter message sent to a given peer could be significant.
   Section 3.4 specifies how CMS encryption keys MAY be reused for
   multiple Diameter messages.


3.1  Usage Scenario

   When a Diameter node is about to send a message, it must determine
   whether a DSA should be established or not. We assume the Diameter
   node knows the user's realm, perhaps through the User-Name AVP.

   Implementations MAY cache the information required to establish a
   DSA. However, they MUST honor time-to-live settings so that
   certificates MUST re-validated (possibly including revocation checks)
   once the DSA has expired.

   Revalidations SHOULD also occur before the DSA expires according to
   PKI policies. During the process of certificate path validation some
   implementations will calculate a duration for which the certificate
   path may be considered "safe". For example, if an implementation did
   not support certificate revocation checks, then the "safe" period
   would be from the time of initial validation until the earliest
   notAfter time in the set of certificates in the path. An
   implementation which does support certificate revocation checks will
   typically be able to calculate a "safe" period based additionally on



Calhoun, Farrell, Bulley,expires September 2002                [Page 12]


Internet-Draft                                                March 2002


   the earliest nextUpdate field in a CRL or OCSP response. Basically,
   the safe period is from the time of certificate validation to the
   earliest value from the set of notAfter and nextUpdate fields
   encountered during certificate validation.

   However, implemetors should note that CAs MAY issue additional CRLs
   before the nextUpdate period. Generally it is a matter of local PKI
   policy as to whether an implementation will make additional checks
   even during the calculated "safe" period. For the purposes of this
   specification implementations are not required to make such checks
   and MAY assume that no re-validation of certificates is required
   during the "safe" period defined above.

   We use Diameter Security Association Request (DSAR) and Diameter
   Security Association Answer (DSAA) messages to establish a DSA, which
   specifies which AVPs should be encrypted, signed or both, as well as
   which public key(s) to use.

   The originating node sends the DSAR message to a server in the
   destination realm. The DSAR message contains:

       - TTL for this DSA (seconds)
       - the realm part of the user's NAI
       - the list of direct trust CA's that the originating Diameter
         node has configured into it for certificate validation.  A
         "direct trust" CA is one that the node is willing to use as the
         "top" of a certificate chain, sometimes confusingly known as a
         "root CA."
       - a flag indicating whether the originating Diameter node wishes
         to receive certificate status information using OCSP messages.
         If this flag requires a fresh OCSP response, a nonce to be used
         by the destination Diameter node in OCSP requests MUST also be
         supplied. See [OCSP] for more details on the certificate status
         protocol and messages.

   The destination node MUST check that the provided elements of the
   DSAR are valid. It MUST check, at least, that:

      - Its local policy allows the given TTL, realm, AVP protection
        expectations, certification status, and other parameters.
      - A common "top" of the certificate chain can be found between the
        home and foreign domains.

   If these conditions can not be verified, the destination node MUST
   return a DSAA with the Result-Code AVP set to
   DIAMETER_NO_DSA_ESTABLISHED.

   In the event the DSAR requested OCSP validation, via the OCSP-



Calhoun, Farrell, Bulley,expires September 2002                [Page 13]


Internet-Draft                                                March 2002


   Request-Flags AVP, and OCSP is not locally supported, the DSAA MUST
   be returned with the Result-Code AVP set to
   DIAMETER_OCSP_NOT_SUPPORTED. Otherwise, the destination node returns
   the DSAA message which contains:

       - TTL for this DSA (seconds)
       - a chain of CA certificates (possibly empty)
       - public key certificates for the Diameter servers in the realm,
         all of which MUST validate up to one of the CA's contained in
         the DSAR message, via the chain of CA certificates above;
       - (optionally, if OCSP an response was requested in the DSAR and
         OCSP is supported) a list of OCSP responses for the
         certificates in question. If a fresh response was required and
         a nonce value was included, each response will contain the
         nonce from the DSAR message

   The originating Diameter node now has to check the response. Any
   failure results in error messages, auditing and not sending the
   Diameter message.

   DSAA Checks:

       - the certificate chain provided in the DSAA is cryptographically
         correct, passes the (relevant parts of the) path validation
         algorithm specified in [CERTPROF] and terminates at a CA
         mentioned in the DSAR message
       - the name in the certificate is consistent with the rules
         detailed in section 3.2.
       - the DSAA message MUST include the CMS-Signed-Data AVP, the
         signature MUST be validated and the signer's certificate chain
         MUST terminate as a CA mentioned in the DSAR message
       - the expiration of the TTL MUST be less or equal to the earliest
         expiration of all certificates in the message, encoded in the
         notAfter field.

   If the initiator's policy is such that certificate status is
   required, it MAY indicate that it requires an OCSP response from the
   DSA peer in the DSAA message, via the OCSP-Request-Flags AVP.
   Further, the initiator MAY request that the OCSP response be fresh
   (non-cached) via the OCSP-Request-Flags and OCSP-Nonce AVPs. Upon
   receipt of a DSAR message requesting an OCSP response, the receiver
   issues an OCSP request and returns the response within the DSAA
   message's OCSP-Responses AVP. The sender of the DSAA MAY included a
   cached OCSP response, unless the requestor specifically requested a
   fresh response.

   The nonce value is to be (the beginning of) the nonce in the OCSP
   response. The reason for this is that the responder MAY add



Calhoun, Farrell, Bulley,expires September 2002                [Page 14]


Internet-Draft                                                March 2002


   additional bits to the nonce, but the nonce provided in the OSCP-
   Nonce MUST be present at the beginning of the nonce of the OSCP
   response.

   The DSAR message MAY include the CMS-Signed-Data AVP. If the
   originating node has a private key, and it includes AVPs whose 'P'
   bit are set, the CMS-Signed-Data AVP MUST be present.

   The DSAA MUST include the CMS-Signed-Data, signed by a Diameter agent
   or server within the user's realm, to prevent an intermediate node
   from modifying the protection expectations for AVPs.

   Depending upon the security technique required (digital signature,
   encryption or both), then the originating node prepares the CMS
   related AVPs as required.

   If certificate revocation is enabled, anytime a certificate is used
   from the local certificate cache, a revocation check MUST be
   performed.

   Once the DSA is in place, any Diameter messages created by a DSA peer
   that has a private key MUST contain a signature over all AVPs whose
   definition states that their 'P' bit MAY be set.

   Furthermore, these peers MUST encrypt any AVPs whose definition
   states that they MAY be encrypted.

   Note: [BASE] includes the "MAY encr" column when describing AVPs. For
   the originator "MAY encr" as used in [BASE] means that if a message
   containing that AVP is to be sent via a proxy/agent (as opposed to
   directly) then the message MUST NOT be sent unless there is a DSA
   between the originator and the recipient OR the originator has
   locally trusted configuration that indicates that CMS need not be
   used.


3.2  Certificate Requirements

   Certificates used for the purposes of Diameter MUST conform to the
   PKIX profile [CERTPROF], and MUST also include a Diameter node's
   FQDN, which is typically added in the Origin-Host AVP [BASE], as one
   of the values of the subjectAltName extension of the Certificate.
   The FQDN is to be encoded as a dNSName within the subjectAltName.

   For Diameter nodes (capable of acting as recipients for
   confidentiality), the FQDN MUST be of the form
   "Diameter-<xxx>.<realm>". Other Diameter nodes MAY use this naming
   scheme. Note that this naming constraint is for PKI purposes only,



Calhoun, Farrell, Bulley,expires September 2002                [Page 15]


Internet-Draft                                                March 2002


   and in no way restricts a Diameter's host name.

   The naming scheme presented here is intended to:
      - make it simple to use existing certification authorities (CAs)
        for Diameter CMS
      - allow CAs to ensure that only "proper" Diameter certificates are
        accepted by Diameter nodes
      - allow Diameter certificates to be used for other purposes where
        that meets a CA's practices.

   These names are used for two purposes:

      1. Where a Diameter node is verifying a signature it needs to be
         able to compare the identity of the signer against the identity
         in the Origin-Host AVP.

      2. Where a Diameter node is encrypting AVPs, it needs to be able
         to ensure that it uses a public key for the intended recipient.
         This requires comparing the identity in a Certificate against
         the FQDN of the intended recipient (which is assumed to be
         known).

   In either case, the presence of the required FQDN as a dNSName value
   in the subjectAltName extension of a verified public key certificate
   satisfies the matching requirement.

   Note that there MAY also be other values in the subjectAltName
   extension, (either using dNSName or other elements of the CHOICE),
   these can be safely ignored, but implementations MUST be able to
   handle their presence.

   Note also that the PKIX profile [CERTPROF], section 4.1.2.6,
   specifies the rules for the relationship between the subjectAltName
   extension and the subject field of public key certificates.

   For multiple Diameter servers within a realm that share a public key,
   each server's identity is encoded in the subjectAltName extension.
   This allows any server within a realm to decrypt AVPs intended for
   that realm.

   Note that once operational experience has been gained, a future
   document may specify a restricted profile of [CERTPROF] in order to
   simplify implementation.


3.3  Algorithms

   For all uses of CMS in this specification the mandatory to implement



Calhoun, Farrell, Bulley,expires September 2002                [Page 16]


Internet-Draft                                                March 2002


   algorithms are as follows:

      - Hashing:
            sha-1 (see [CMS] section 12.1.1)
      - Signature (the hash algorithm is specified separately):
            rsaEncryption (see [CMS] section 12.2.2)
      - Content Encryption:
            des-ede3-cbc (see [CMS] section 12.4.1)
      - Asymmetric key transport:
            rsaEncryption (see [CMS] 12.3.2.1)
      - Symmetric key encryption (only needed in conjunction with
      [RCEK]):
            id-alg-CMS3DESwrap (see [CMS] section 12.3.3.1)

   At some point in future, AES will replace 3DES.


3.4 Reuse of CMS Content Encryption Keys

   This section describes an efficiency improvement which MAY be
   supported by Diameter nodes. If a node doesn't support this feature,
   then it MUST (and naturally will), treat all packets with re-used
   content encryption keys as a cryptographic failure. The originating
   node MAY then attempt to re-send the packets using asymmetric key
   transport. If a node does support this feature, then the MUST/SHOULD
   statements in this section apply, otherwise not.

   Once a CMS-Encrypted-Data AVP has been exchanged between two Diameter
   peers, then they share a symmetric cryptographic key (the content
   encryption key) which can be used to encrypt further Diameter AVPs
   between the peers by using the scheme specified in [RCEK]. The peers
   MUST first take part in an DSAR/DSAA exchange in order to distribute
   the required asymmetric keys.

   Although the use of symmetric encryption might be used to provide
   integrity or confidentiality, it does not provide data origin
   authentication with proof of origin.

   [RCEK] leaves open some issues, namely how to handle loss of a shared
   secret (say following a peer re-boot) and for how long to continue to
   use a shared secret (the maximum number of decryptions required).

   Where a Diameter node receives a CMS-Encrypted-Data AVP, but doesn't
   have the required shared secret, that node SHOULD return the
   DIAMETER_KEY_UNKNOWN error message. The peer MAY then use the
   DSAR/DSAA exchange to rebuild their Diameter security association.

   In [RCEK], the default value for the maximum number of decryptions



Calhoun, Farrell, Bulley,expires September 2002                [Page 17]


Internet-Draft                                                March 2002


   allowed (CEKMaxDecrypts) when re-using a content encryption key is 1.
   In general this default SHOULD be used, but if a Diameter node
   "knows" that more than one CMS-Encrypted-Data AVP will be exchanged
   between the nodes, then the CEKMaxDecrypts setting MAY be set higher.
   Diameter nodes MUST be able to support a maxDecrypts setting of 1000.

   Note that the CEKMaxDecrypts value used does not affect that DSA-TTL.
   The DSA-TTL dictates the lifetime of the DSA, while the
   CEKMaxDecrypts dictates how often rekeying will occur within the CMS
   protocol. A content encryption key MUST NOT be reused once the DSA
   has expired.

   Implementations MUST be able to support a DSA-TTL of one day, and
   nodes which support certificate checking (e.g. CRLs, OCSP) that are
   re-establishing a DSA due to expiration of the TTL MUST re-validate
   the certificate.

4.0  Command-Codes Values

   This section defines new Command-Code [BASE] values that MUST be
   supported by all Diameter implementations that conform to this
   specification. The following Command Codes are currently defined in
   this document:

      Command-Name             Abbrev.    Code       Reference
      --------------------------------------------------------
      Diameter-Security-        DSAR      304           4.1
         Association-Request
      Diameter-Security-        DSAA      304           4.2
         Association-Answer
      Proxy-Diameter-Security-  PDSR      305           4.3
         Association-Request
      Proxy-Diameter-Security-  PDSA      305           4.4
         Association-Answer


4.1  Diameter-Security-Association-Request

   The Diameter-Security-Association-Request command, indicated by the
   Command-Code field set to 304 and the 'R' bit set in the message
   flags field, is sent by a Diameter node to establish a Diameter
   Security Association. The DSAR message MUST NOT be used simply as a
   convenient certificate distribution protocol without establishing a
   DSA. The CMS-Signed-Data AVP MUST be present if any AVP in the
   message has the 'P' bit set.

   Message Format




Calhoun, Farrell, Bulley,expires September 2002                [Page 18]


Internet-Draft                                                March 2002


      <DSAR> ::= < Diameter-Header: 304, REQ, PXY >
                 { Origin-Host }
                 { Origin-Realm }
                 { Destination-Realm }
                 { Auth-Application-Id }
                 { OCSP-Request-Flags }
                 { DSA-TTL }
               * { Local-CA-info }
              0*1[ CA-Chain ]
               * [ AAA-Node-Cert ]
              0*1[ OCSP-Nonce ]
              0*1[ Origin-State-Id ]
              0*1[ Destination-Host ]
              0*1[ CMS-Signed-Data ]
               * [ AVP ]
               * [ Proxy-Info ]
               * [ Route-Record ]


4.2  Diameter-Security-Association-Answer

   The Diameter-Security-Association-Answer command, indicated by the
   Command-Code field set to 304, with the 'R' bit in the Command Flags
   cleared, in response to a DSAR. The CMS-Signed-Data AVP MUST be
   present if any AVP in the message has the 'P' bit set. If the Result-
   Code AVP indicates success, the CA-Chain, AAA-Node-Cert, DSA-TTL and
   CMS-Signed-Data AVPs MUST be present.

   Message Format

      <DSAA> ::= < Diameter-Header: 304, PXY >
                 { Result-Code }
                 { Origin-Host }
                 { Auth-Application-Id }
                 { DSA-TTL }
               * { Local-CA-info }
              0*1[ CA-Chain ]
               * [ AAA-Node-Cert ]
              0*1[ Origin-Realm ]
              0*1[ Error-Message ]
              0*1[ Error-Reporting-Host ]
               * [ OCSP-Responses ]
              0*1[ CMS-Signed-Data ]
              0*1[ Origin-State-Id ]
               * [ AVP ]
               * [ Proxy-Info ]





Calhoun, Farrell, Bulley,expires September 2002                [Page 19]


Internet-Draft                                                March 2002


4.3  Proxy-Diameter-Security-Association-Request

   The Proxy-Diameter-Security-Association-Request command, indicated by
   the Command-Code field set to 305 and the 'R' bit set in the Command
   Flags field, is sent by a Diameter node to request that a downstream
   proxy establishes a Diameter Security Association with a server in a
   given realm on its behalf.

   Message Format

      <PDSR> ::= < Diameter-Header: 305, REQ, PXY >
                 { Origin-Host }
                 { Origin-Realm }
                 { Destination-Realm }
                 { Auth-Application-Id }
              0*1[ DSAR-Target-Realm ]
              0*1[ Origin-State-Id ]
              0*1[ Destination-Host ]
               * [ AVP ]
               * [ Proxy-Info ]
               * [ Route-Record ]


4.4  Proxy-Diameter-Security-Association-Answer

   The Proxy-Diameter-Security-Association-Answer command, indicated by
   the Command-Code field set to 305 and the 'R' bit cleared in the
   Command Flags field, is sent by a Diameter node in response to an
   PDSR message.

   Message Format

      <PDSA> ::= < Diameter-Header: 305, PXY >
                 { Result-Code }
                 { Origin-Host }
                 { Origin-Realm }
                 { Auth-Application-Id }
                 { DSA-TTL }
              0*1[ Error-Message ]
              0*1[ Error-Reporting-Host ]
              0*1[ Origin-State-Id ]
               * [ Redirect-Host ]
              0*1[ Redirect-Host-Usage ]
              0*1[ Redirect-Max-Cache-Time ]
               * [ AVP ]
               * [ Proxy-Info ]





Calhoun, Farrell, Bulley,expires September 2002                [Page 20]


Internet-Draft                                                March 2002


5.0 Diameter Security Association Message Flow

   This section contains an example of a NAS in realm xyz.com,
   communicating with its local relay agent, which in turn communicates
   with a server in ABC.COM's network. In the following example, once
   the initial capabilities exchange is complete, the NAS receives a
   request for access from alice@abc.com, which causes the DSA setup to
   be initiated, followed by the application-specific authentication
   request.

   Although the example doesn't specifically use bi-directional digital
   signature and encryption, this feature is supported.

           +-------+            +-------+            +---------+
           |  NAS  |            | Relay |            | abc.com |
           |       |            | Agent |            |Home Srv |
           +-------+            +-------+            +---------+
               |                    |                    |
               |CER apps 1, 2       |                    |
          (a)  |------------------->|                    |
               |CAA apps -1         |                    |
          (b)  |<-------------------|                    |
               |         .          |CER apps 1, 2       |
          (c)  |                    |<-------------------|
               |                    |CEA apps -1         |
          (d)  |                    |------------------->|
             ->| User alice@abc.com |                    |
          (e)  | Requests Access    |                    |
               |                    |                    |
               |       DSAR         |                    |
               | Dest-Realm=abc.com |                    |
          (f)  |--------------------+------------------->|
               |                    |      DSAA          |
               |                    | Origin-Host=foo    |
          (g)  |<-------------------+--------------------|
               | Auth-Request +     |                    |
               | CMS-Signed-Data    |                    |
               | Dest-Host=foo      |                    |
          (h)  |--------------------+------------------->|
               |                    | Auth-Answer +      |
               |                    | CMS-Encrypted-Data |
          (i)  |<-------------------+--------------------|
                     Figure 6: Example of a DSA Setup

      (a) NAS sends a CER message to its relay agent indicating that it
          supports applications 1 (NASREQ) and 2 (CMS Security).

      (b) The relay agent sends a CEA message to the NAS indicating that



Calhoun, Farrell, Bulley,expires September 2002                [Page 21]


Internet-Draft                                                March 2002


          it is a relay supporting all Diameter applications.

      (c) ABC.COM's Home Server sends a CER message to a relay agent
           indicating that it supports applications 1 (NASREQ) and 2
          (CMS Security).

      (d) The relay agent sends a CEA message to ABC.COM's Home Server
          indicating that it is a relay supporting all Diameter
          applications.

      (e) The NAS receives a request for access from a user
          (alice@abc.com).

      (f) The NAS issues an DSAR message, with the Destination-Realm AVP
          set to abc.com.

      (g) ABC.COM's Home Server processes the DSAR message, and replies
          with the DSAA message.

      (h) The NAS issues an authentication request with the Destination-
          Host AVP set to the value of the Origin-Host AVP in the DSAA.
          The message includes the CMS-Signed-AVP, which authenticates
          the AVPs that were requested by the Home Server in the DSAA.

      (i) The Home Server successfully authenticates the user, and
          returns a reply, which includes the CMS-Encrypted-Data AVP,
          whose contents include the AVPs that require encryption.


6.0  CMS Security AVPs

   This section contains AVPs that are used to establish a Diameter
   Security Association, and to transport CMS objects. Except as
   specifically constrained, the profile of CMS algorithm and structure
   usage is as specified in the S/MIME v3 message specification [MSG].
















Calhoun, Farrell, Bulley,expires September 2002                [Page 22]


Internet-Draft                                                March 2002


                                            +---------------------+
                                            |    AVP Flag rules   |
                                            |----+-----+----+-----|----+
                   AVP  Section             |    |     |SHLD| MUST|MAY |
   Attribute Name  Code Defined  Value Type |MUST| MAY | NOT|  NOT|Encr|
   -----------------------------------------|----+-----+----+-----|----|
   AAA-Node-Cert    351  6.6     OctetString|M,P |     |    |  V  | N  |
   CA-Chain         353  6.8     OctetString| M  |  P  |    |  V  | N  |
   CA-Name          349  6.4.1   UTF8String | M  |  P  |    |  V  | N  |
   CMS-Encrypted-   355  6.2     OctetString| M  |  P  |    |  V  | N  |
     Data                                   |    |     |    |     |    |
   CMS-Signed-Data  310  6.1     OctetString| M  |     |    | P,V | N  |
   DSA-TTL          362  6.11    Unsigned32 | M  |  P  |    |  V  | N  |
   DSAR-Target-     360  6.10    UTF8String | M  |  P  |    |  V  | N  |
     Realm                                  |    |     |    |     |    |
   Key-Hash         350  6.4.2   OctetString| M  |  P  |    |  V  | N  |
   Local-CA-Info    348  6.4     Grouped    | M  |  P  |    |  V  | N  |
   OCSP-Nonce       358  6.5     OctetString| M  |  P  |    |  V  | N  |
   OCSP-Request-    361  6.9     Enumerated | M  |  P  |    |  V  | N  |
     Flags                                  |    |     |    |     |    |
   OCSP-Responses   359  6.7     OctetString| M  |  P  |    |  V  | N  |

   The profile of CMS algorithm and structure usage is conformant to
   that specified in the S/MIME v3 message specification [MSG]. This
   makes is simpler to base an implementation of this specification upon
   an existing S/MIME toolkit.

   No MIME encoding of binary data is required for this specification.
   This is different from the use of CMS in S/MIME, but is acceptable
   since Diameter is a binary protocol and investigation has not shown
   this to cause problems when using existing CMS & S/MIME toolkits.


6.1  CMS-Signed-Data AVP


   The CMS-Signed-Data AVP (AVP Code 310) is of type OctetString and
   contains the Basic Encoding Rules (BER) encoding of a CMS object
   [CMS] of type ContentInfo.  This means that where a set of AVPs is to
   be signed, the set of AVPs with the 'P' bit set MUST first be
   catenated together in the order in which they occur in the Diameter
   message.  The result of this encoding is used as input into the
   signing process.

   Note that the AVPs themselves are not encapsulated within the CMS-
   Signed-Data AVP. Instead, the digest value of the AVPs produced in
   the signature process MUST be included in the CMS-Signed-Data AVP, as
   a message-digest attribute (defined in section 11.2 of [CMS]) in the



Calhoun, Farrell, Bulley,expires September 2002                [Page 23]


Internet-Draft                                                March 2002


   SignerInfo value.

   Multiple Diameter entities MAY add their signatures to an existing
   CMS-Signed-Data AVP. Multiple signatures are added within the
   countersignature attribute (defined in section 11.4 of [CMS]) and not
   as additional SignerInfo values. The countersignature attribute
   requires that the signatures occur sequentially, meaning that each
   signature covers the existing signatures in the CMS object.

   The initial signature, and any additional countersignatures, MUST
   cover the exact same set of AVPs, in the order they are present in
   the message.

   Note that the CMS-Signed-Data AVP itself MUST NOT be used in the
   generation of the signature, and therefore MUST NOT have its 'P' bit
   set.

   The eContent field of the EncapsulatedContentInfo structure MUST be
   absent since the digital signature covers data outside of the object.

   If a receiver cannot verify correctly the signature carried by the
   CMS-Signed-Data AVP, it SHOULD return the DIAMETER_INVALID_AUTH
   Result-Code AVP value defined in section 7.1.

   When AVPs are to be both encrypted and signed, the CMS-Encrypted-Data
   AVP MUST be created first. This AVP MUST then have the 'P' bit set
   and be one of the inputs to the signing process as described above.
   (Any other processing resulting in the same output can be used.) This
   means that signing is "outside" encryption.

   No more than one CMS-Signed-Data AVP MUST be present in any given
   Diameter message.


6.2  CMS-Encrypted-Data AVP

   The CMS-Encrypted-Data AVP (AVP Code 355) is of type OctetString with
   the OctetString containing the Basic Encoding Rules (BER) encoding of
   a CMS object [CMS] of type ContentInfo.

   All AVPs to be encrypted are concatenated. This value is then:

      - encrypted according to normal CMS rules,
      - used as the value of the  EncryptedContent field within
        EnvelopedData.

        The contentType of the EncryptedContentInfo value MUST be id-
        data [MSG].



Calhoun, Farrell, Bulley,expires September 2002                [Page 24]


Internet-Draft                                                March 2002


        A CMS-Encrypted-Data AVP contains exactly one EnvelopedData.
        Where one or more AVP would be encrypted within separate
        EnvelopedData structures, then separate CMS-Encrypted-Data AVPs
        MUST be used.

        Thus, implementations MUST be able to support the presence of
        multiple CMS-Encrypted-Data AVPs and MUST be able to decrypt any
        EnvelopedData for which it is a recipient, as indicated in the
        EnvelopedData's RecipientInfos field [CMS].

        If the recipient is not specified in a RecipientInfo, it MAY
        choose to process the message or return an answer with the
        Result-Code AVP set to DIAMETER_NO_DSA_RECIPIENT. If the
        recipient is in the RecipientInfos and an error occurs during
        decryption, then the recipient MUST answer with the Result-Code
        set to DIAMETER_INVALID_AVP_VALUE.

        Diameter nodes SHOULD implement content encryption key reuse
        (see section 3.4 above).

        If a receiver detects that the contents of the CMS-Encrypted-
        Data AVP are invalid, it SHOULD answer with the Result-Code set
        to DIAMETER_INVALID_CMS_DATA.

        Zero or more CMS-Encrypted-Data AVP MAY be present in any
        Diameter message.


6.3  Example Encodings

   In order to clarify the contents of and the relationships between
   CMS-Signed-Data and CMS-Encrypted-Data AVPs we present the following
   example of how these AVPs are calculated.

   First, some short-hand:

      - The "|" character represents concatenation
      - EnvelopedData-fnc(x,y) represents the EnvelopedData produced as
        output of a function with x as the to-be-encrypted-data and y as
        the parameters (e.g. recipient information).
      - SignedData (y) represents the SignedData produced as output of a
        function with the catenation of the 'P is set' AVPs as the
        to-be-digested-data    (which is not part of the output!) and y
        as the parameters (e.g. signer information).

   The scenario calls for a message containing 7 AVPs s,t,e,p,h,e' and n
   to meet the following:
      AVPs s, t and e are to be encrypted for recipient P.



Calhoun, Farrell, Bulley,expires September 2002                [Page 25]


Internet-Draft                                                March 2002


      AVPs e, p and h are to be encrypted for recipient A.
      AVPs s, and e' are to be signed by originator T.
      AVP  s is to be sent to recipient A.
      AVP  n needs neither signing nor encryption.

   Note that though there is no explicit requirement that AVP s be
   encrypted for A, since it will be encrypted for P, we also have to
   encrypt it for A. Implementations SHOULD NOT send the same AVP both
   encrypted and in clear.

   The resulting message will look like:
      AVP1='P is set',   EnvelopedData-fnc(s|t|e,P)
      AVP2='P is set',   EnvelopedData-fnc(s|e|p|h,A)
      AVP3='P is set',   e'
      AVP4='P is clear', n
      AVP5='P is clear', SignedData(T)

   The result of this is that all AVPs except n are actually signed even
   though signing of t and e wasn't explicitly required.  However, this
   is no harm.


6.4  Local-CA-Info AVP

   The Local-CA-Info AVP (AVP Code 348) is of type Grouped.  The Grouped
   Data field has the following ABNF grammar:

      Local-CA-Info ::= < AVP Header: 348 >
                        { CA-Name }
                        { Key-Hash }


6.4.1  CA-Name AVP

   The CA-Name AVP (AVP Code 349) is of type UTF8String.  The AVP
   contains the DN (in LDAP string syntax [LDAPSTR]) of the Certificate
   Authority, e.g. "CN=CA;O=Baltimore Technologies;C=IE".

6.4.2  Key-Hash AVP

   The Key-Hash AVP (AVP Code 350) is of type OctetString, and contains
   the SHA-1 hash of a public key.

   The hash MUST be calculated over the representation of the CA public
   key which would be present in an X.509 public key certificate,
   specifically, the input for the hash algorithm MUST be the DER
   encoding of a SubjectPublicKeyInfo representation of the key. Note:
   This includes the AlgorithmIdentifier as well as the BIT STRING. The



Calhoun, Farrell, Bulley,expires September 2002                [Page 26]


Internet-Draft                                                March 2002


   rules given in [CERTPROF] for encoding keys MUST be followed.

   Since this AVP is used for indexing and not for security (since
   Diameter nodes SHOULD validate certificates), there is no need to
   support more than one hash algorithm here.


6.5  OCSP-Nonce AVP

   The OCSP-Nonce AVP (AVP Code 358) is of type OctetString, and
   contains a random value (RECOMMENDED to be at least 128 bits)
   generated by the Diameter node.


6.6  AAA-Node-Cert AVP

   The AAA-Node-Cert AVP (AVP Code 351) is of type OctetString and
   contains a public key certificate for the AAA node. Note: this AVP
   contains no CA certificates, just the end-entity certificate.
   Certificates MUST follow the naming conventions described in section
   3.2.

6.7  OCSP-Responses AVP

   The OCSP-Responses AVP (AVP Code 359) is of type OctetString, and
   contains an OCSP response message from an OCSP responder. If the
   OCSP-Request-Flags AVP indicating a response was required in the
   corresponding request message, the OCSP-Responses AVP MUST be
   present. Furthermore, the OCSP-Request-Flags AVP MAY request a fresh
   OCSP response message, which MUST also include the OCSP-Nonce AVP.


6.8  CA-Chain AVP

   The CA-Chain AVP (AVP Code 353) is of type OctetString, and contains
   a certificate chain, from one of the nominated locally trusted CAs
   down to the (one and only) CA which has issued the end entity
   certificates in the AAA-Node-Cert AVP. The OctetString contains a CMS
   "certs-only" message.

   To produce this AVP in an DSAA message, one (and only one) of the
   Local-CA-info values from the corresponding DSAR message is selected
   (call this the "top" CA for the purposes of this description). This
   AVP then contains a certificate path (in order) from the "top" CA
   down to the (one and only) CA which has issued the end entity
   certificate in the AAA-Node-Cert AVP.  The (typically self-signed),
   certificate of the "top" CA MUST NOT be included.




Calhoun, Farrell, Bulley,expires September 2002                [Page 27]


Internet-Draft                                                March 2002


6.9  OCSP-Request-Flags AVP

   The OCSP-Request-Flags AVP (AVP Code 361) is of type Enumerated, and
   specifies whether the sender wishes to receive an OCSP response. The
   following values are defined:

      NO_OCSP_RESPONSE    0
         The sender does not wish to receive an OCSP Response.

      OCSP_RESPONSE       1
         The sender wishes to receive an OCSP Response, and is willing
         to accept a stale response.

      OCSP_FRESH_RESPONSE 2
         The sender wishes to receive a fresh OCSP Response. When this
         value is set, the OCSP-Nonce AVP MUST be present.


6.10  DSAR-Target-Realm AVP

   The DSAR-Target-Realm AVP (AVP Code 360) is of type UTF8String, and
   contains the Destination-Realm of the resulting DSAR sent by a non-
   transparent proxy.


6.11  DSA-TTL AVP

   The DSA-TTL AVP (AVP Code 362) is of type Unsigned32, and contains
   the time to live (in seconds) of the Diameter Security Association.
   The expiration time (now+TTL) MUST NOT be greater than the earliest
   expiration time (NotAfter field) of all certificates included in this
   message accompanying this AVP. The DSA-TTL AVP in the DSAA MUST NOT
   be greater than the DSA-TTL AVP in the DSAR. A DSA-TTL AVP MUST also
   be included in the PDSA in order to provide information about the
   lenght of the DSA established by the proxy on behalf of the access
   device. Implementations MUST be able to support a DSL-TTL of one day.


7.0  Result-Code AVP Values

   This section defines new Result-Code [BASE] values that MUST be
   supported by all Diameter implementations that conform to this
   specification.


7.1  Transient Failures

   Errors that fall within the transient failures category are used to



Calhoun, Farrell, Bulley,expires September 2002                [Page 28]


Internet-Draft                                                March 2002


   inform a peer that the request could not be satisfied at the time it
   was received, but MAY be able to satisfy the request in the future.

      DIAMETER_KEY_UNKNOWN              4008
         This error code is returned when a CMS-Signed-Data or CMS-
         Encrypted-Data AVP is received that was generated using a key
         that is not locally recognized. This error could be caused if
         one of the participants of a DSA lost a previously agreed upon
         key, perhaps as a result of a reboot.

      DIAMETER_NO_CMS_THROUGH_PROXY     4009
         This error code is returned when a non-transparent proxy
         receives an DSAR message to state that it doesn't allow a DSA
         through it since it plans to modify AVPs.

      DIAMETER_CAN_ACT_AS_CMS_PROXY     4010
         This error code is returned when a non-transparent proxy
         receives an DSAR message, and although it doesn't allow a DSA
         through it, it is willing to initiate a DSA on behalf of the
         access device.

      DIAMETER_OCSP_NOT_SUPPORTED       4011
         This error code is returned when a DSAR message is received
         requesting OCSP validation, and the receiver does not support
         OCSP.

      DIAMETER_INVALID_AUTH             4012
         The signature in the CMS-Signed-Data AVP is invalid.

      DIAMETER_MISSING_SIGNED_AVPS      4013
         Some AVPs within a Diameter message were expected to be signed.


7.2  Permanent Failures

   Errors that fall within the permanent failures category are used to
   inform the peer that the request failed, and should not be attempted
   again.

      DIAMETER_INVALID_CMS_DATA          5019
         This error code is returned when a CMS-Data AVP is received
         with an invalid ContentInfo object.

      DIAMETER_NO_COMMON_TRUST           5020
         This error code is returned when a receiver receives a DSAR for
         which it has no common trust with the sender, which is required
         to establish the DSA.




Calhoun, Farrell, Bulley,expires September 2002                [Page 29]


Internet-Draft                                                March 2002


      DIAMETER_NO_DSA_ESTABLISHED        5021
         A Diameter message refers to a Diameter Security Association
         which does not exist.

      DIAMETER_DSA_EXPIRED               5022
         A Diameter message refers to a Diameter Security Association
         which has expired.

      DIAMETER_NO_DSA_RECIPIENT          5023
         A Diameter message was received with encrypted data, and the
         local Diameter node is not a potential recipient of the
         EnvelopedData.


8.0  AVP Occurrence Tables

   The table in this section presents the AVPs defined in this document,
   and specifies in which Diameter messages they MAY, or MAY NOT be
   present.  Note that AVPs that can only be present within a Grouped
   AVP are not represented in this table.

   The table uses the following symbols:
      0      The AVP MUST NOT be present in the message.
      0+     Zero or more instances of the AVP MAY be present in the
            message.
      0-1    Zero or one instance of the AVP MAY be present in the
            message.
      1     One instance of the AVP MUST be present in the message.
      1+    At least one instance of the AVP MUST be present in the
            message.





















Calhoun, Farrell, Bulley,expires September 2002                [Page 30]


Internet-Draft                                                March 2002


                                 +-----------------------+
                                 |      Command-Code     |
                                 |-----+-----+-----+-----+
   Attribute Name                | DSAR| DSAA| PDSR| PDSA|
   ------------------------------|-----+-----+-----+-----+
   Auth-Application-Id           | 1   | 1   | 1   | 1   |
   Destination-Host              | 0-1 | 0   | 0   | 0   |
   Destination-Realm             | 1   | 0   | 1   | 0   |
   Error-Message                 | 0   | 0-1 | 0   | 0-1 |
   Error-Reporting-Host          | 0   | 0-1 | 0   | 0-1 |
   AAA-Node-Cert                 | 0-1 | 0-1 | 0   | 0   |
   CA-Chain                      | 0-1 | 0-1 | 0   | 0   |
   CA-Name                       | 0   | 0   | 0   | 0   |
   CMS-Encrypted-Data            | 0   | 0   | 0   | 0   |
   CMS-Signed-Data               | 0-1 | 0-1 | 0   | 0   |
   DSA-TTL                       | 1   | 1   | 0   | 0   |
   DSAR-Target-Realm             | 0   | 0   | 0-1 | 0   |
   Local-CA-Info                 | 0+  | 0+  | 0   | 0   |
   OCSP-Nonce                    | 0-1 | 0   | 0   | 0   |
   OCSP-Request-Flags            | 1   | 0   | 0   | 0   |
   OCSP-Responses                | 0   | 1+  | 0   | 0   |
   Origin-Host                   | 1   | 1   | 1   | 1   |
   Origin-Realm                  | 1   | 1   | 1   | 1   |
   Original-State-Id             | 0-1 | 0-1 | 0-1 | 0-1 |
   Proxy-Info                    | 0+  | 0+  | 0+  | 0+  |
   Redirect-Host                 | 0   | 0+  | 0   | 0+  |
   Redirect-Host-Usage           | 0   | 0-1 | 0   | 0-1 |
   Redirect-Max-Cache-Time       | 0   | 0-1 | 0   | 0-1 |
   Result-Code                   | 0   | 1   | 0   | 1   |
   Route-Record                  | 0+  | 0   | 0+  | 0   |
   ------------------------------|-----+-----+-----+-----|


9.0  IANA Considerations

   This section contains the namespaces that have either been created in
   this specification, or the values assigned to existing namespaces
   managed by IANA.


9.1  Command Codes

   This specification assigns the value 304 and 305 from the Command
   Code namespace defined in [BASE]. See section 4.0 for the assignment
   of the namespace in this specification.


9.2  AVP Codes



Calhoun, Farrell, Bulley,expires September 2002                [Page 31]


Internet-Draft                                                March 2002


   This specification assigns the values 348-351, 353, 355, 358-362 from
   the AVP Code namespace defined in [BASE]. See section 6.0 for the
   assignment of the namespace in this specification.


9.3  Result-Code AVP Values

   This specification assigns the values 4008-4011, 5019-5023 from the
   Result-Code AVP (AVP Code 268) value namespace defined in [BASE]. See
   section 7.0 for the assignment of the namespace in this
   specification.


9.4  Application Identifier

   This specification assigns the value two (2) to the Application
   Identifier namespace defined in [BASE]. See section 1.6 for more
   information.


9.5  OCSP-Request-Flags AVP Values

   As defined in Section 6.9, the OCSP-Request-Flags AVP (AVP Code 361)
   defines the values 0-2. All remaining values are available for
   assignment via IETF Consensus [HUH???????].


10.0  Security Considerations

   This document describes how CMS security can be achieved in the
   Diameter protocol by allowing S/MIME Cryptographic Message Syntax
   [CMS] objects to be carried as a Diameter AVP.

   This specification does not mandate certificate revocation, however
   not verifying whether a given certificate has been revoked has
   serious implications, and MAY create a security hole.

   The PDSR and PDSA messages (sections 4.3 and 4.4) allow a third party
   proxy to establish a Diameter security association with a Diameter
   server in a target realm. An access device MUST ensure that the
   server establishing the SA on its behalf is a trusted entity, since
   the proxy in question could modify Diameter messages, which would be
   very difficult to trace.


11.0  References





Calhoun, Farrell, Bulley,expires September 2002                [Page 32]


Internet-Draft                                                March 2002


   Normative References



[BASE]
     P. Calhoun, J. Arkko, E. Guttman, G. Zorn, J. Loughney, "Diameter
     Base Protocol", draft-ietf-aaa-diameter-09.txt, IETF work in
     progress, March, 2002.

[CERTLDAP]
     Boyen, Howes, Richard, "Internet X.509 Public Key Infrastructure
     Operational Protocols - LDAPv2", RFC 2559, April 1999.

[CERTPROF]
     Housley, Ford, Polk, Solo, "Internet X.509 Public Key Infrastruc-
     ture Certificate and CRL Profile", RFC 2459, January 1999.

[CMS]
     R. Housley, "Cryptographic Message Syntax", RFC 2630, June 1999.

[LDAPSTR]
     M. Wahl, S. Kille, T. Howes, "Lightweight Directory Access Protocol
     (v3): UTF-8 String Representation of Distinguished Names", RFC
     2253, December 1997.

[MSG]
     B. Ramsdell, "S/MIME Version 3 Message Specification", RFC 2633,
     June 1999.

[MUSTSHOULD]
     S. Bradner, "Key words for use in RFCs to Indicate Requirement Lev-
     els", BCP 14, RFC 2119, March 1997.

[OCSP]
     Myers, Ankney, Malpani, Galperin, Adams, "X.509 Internet Public Key
     Infrastructure Online Certificate Status Protocol (OCSP)", RFC
     2560, June 1999.

[RCEK]
     Farrell, Turner, "Reuse of CMS Content Encryption Keys", RFC 3185,
     October 2001.

   Informative References


[AAAREQS]
     Aboba et al., "Criteria for Evaluating AAA Protocols for Network
     Access", RFC 2989, November 2000.



Calhoun, Farrell, Bulley,expires September 2002                [Page 33]


Internet-Draft                                                March 2002


[CDMAREQ]
     T. Hiller et al., "Cdma2000 Wireless Data Requirements for AAA",
     RFC 3141, June 2001.

[MIPREQ]
     S. Glass, S. Jacobs, C. Perkins, "Mobile IP Authentication, Autho-
     rization, and Accounting Requirements". RFC 2977. October 2000.


12.0  Acknowledgements

   The authors would also like to acknowledge the following people for
   their contribution in the development of this specification:

   Bernard Aboba, Jari Arkko, Steven Bellovin and Miguel A. Monjas

   Finally, Pat Calhoun would like to thank Sun Microsystems since most
   of the effort put into this document was done while he was in their
   employ.


13.0  Authors' Addresses

   Questions about this memo can be directed to:

      Pat R. Calhoun
      Black Storm Networks
      250 Cambridge Avenue, Suite 200
      Palo Alto, California, 94306
      USA

       Phone:  +1 650-617-2932
         Fax:  +1 650-786-6445
      E-mail:  pcalhoun@diameter.org


      Stephen Farrell
      Baltimore Technologies
      39 Parkgate Street,
      Dublin 8,
      IRELAND

       Phone:  +353-1-881-6000
         Fax:  +353-1-881-7000
      E-Mail:  stephen.farrell@baltimore.ie


      William Bulley



Calhoun, Farrell, Bulley,expires September 2002                [Page 34]


Internet-Draft                                                March 2002


      Merit Network, Inc.
      Building One, Suite 2000
      4251 Plymouth Road
      Ann Arbor, Michigan, 48105-2785
      USA

       Phone:  +1 734-764-9993
         Fax:  +1 734-647-5185
      E-mail:  web@merit.edu


14.0  Full Copyright Statement

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

   This document and translations of it may be copied  and  furnished
   to others,  and  derivative works that comment on or otherwise
   explain it or assist in its implementation may be prepared, copied,
   published and distributed,  in  whole  or  in part, without restric-
   tion of any kind, provided that the  above  copyright  notice  and
   this  paragraph  are included on all such copies and derivative
   works.  However, this docu- ment itself may not be modified in any
   way, such as  by  removing  the copyright notice or references to the
   Internet Society or other Inter- net organizations, except as needed
   for  the  purpose  of  developing Internet standards in which case
   the procedures for copyrights defined in the Internet Standards pro-
   cess must be followed, or as required  to translate it into languages
   other than   English.  The limited permis- sions granted above are
   perpetual and  will  not  be  revoked  by  the Internet  Society or
   its successors or assigns.  This document and the information con-
   tained herein is provided on an "AS IS" basis  and  THE INTERNET
   SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WAR-
   RANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY  WAR-
   RANTY  THAT  THE  USE  OF THE INFORMATION HEREIN WILL NOT INFRINGE
   ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
   FOR  A PARTICULAR PURPOSE."


15.0  Expiration Date

   This memo is filed as <draft-ietf-aaa-diameter-cms-sec-04.txt> and
   expires in September 2002.









Calhoun, Farrell, Bulley,expires September 2002                [Page 35]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/