Individual Contribution                                   Pat R. Calhoun
Internet-Draft                                    Sun Microsystems, Inc.
Category: Standards Track                                Stephen Farrell
<draft-ietf-aaa-diameter-e2e-sec-02.txt>          Baltimore Technologies
                                                          William Bulley
                                                     Merit Network, Inc.
                                                                May 2001



                 Diameter End-2-End Security Extension



                          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 SSL for
   integrity and confidentiality between two Diameter nodes. The base
   protocol also defines a Diameter proxy server, that forwards requests
   to other servers when it detects that a given request cannot be
   satisfied locally.




Calhoun, Bulley, Farrell  expires October 2001                  [Page 1]


Internet-Draft                                                  May 2001


   The ROAMOPS Working Group has defined a requirement that allows for
   the Diameter servers communicating through the proxy to be able to
   provide for end-to-end AVP integrity and confidentiality, making it
   difficult for the proxy to be able to modify, and/or be able to view
   sensitive information, within the message. The Mobile-IP and NASREQ
   Working Groups have stated that strong authentication is a
   requirement for AAA data, such as accounting records, for the
   purposes of non-repudiation.

   This Diameter extension specifies how strong AVP authentication,
   integrity and encryption can be done using a mixture of symmetric and
   asymmetric transforms, by encapsulating Cryptographic Message Syntax
   (CMS) data into  Diameter AVPs. The CMS data can also be used to
   carry X.509 certificates.


Table of Contents

      1.0  Introduction
            1.1  Requirements language
            1.2  Advertising extension 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  E2E-SA-Setup-Request (ESSR) Command
            4.2  E2E-SA-Setup-Answer (ESSA) Command
      5.0  End-to-End Security Association Message Flow
      6.0  End-to-End 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
      7.0  Result-Code AVP Values
            7.1  Transient Failures
            7.2  Permanent Failures



Calhoun, Bulley, Farrell  expires October 2001                  [Page 2]


Internet-Draft                                                  May 2001


      8.0  IANA Considerations
            8.1  Command Codes
            8.2  AVP Codes
            8.3  Result-Code AVP Values
            8.4  Extension Identifier
      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 October 2001                  [Page 3]


Internet-Draft                                                  May 2001


1.0  Introduction

   The Diameter base protocol [1] leverages either IPsec or SSL for
   integrity and confidentiality between two Diameter nodes. The base
   protocol also defines a Diameter proxy server, that forwards requests
   to other servers when it detects that a given request cannot be
   satisfied locally.

   The ROAMOPS Working Group has defined a requirement in [10] that
   allows for the Diameter servers communicating through the proxy to be
   able to provide for end-to-end AVP integrity and confidentiality,
   making it difficult for the proxy to be able to modify and see
   sensitive information within the message.  The Mobile-IP and NASREQ
   Working Groups have stated in [6, 7, 8] that non-repudiation is a
   requirement for AAA data, such as accounting records.

   When a chain of proxies use hop-by-hop security (e.g. TLS, IPSec), a
   proxy may modify information in a Diameter message. It is virtually
   impossible for the rest of the nodes in the proxy chain to know that
   the message was modified in mid-stream. Figure 1 shows an example of
   such a network, where DIA3 modifies the contents of "foo" in both the
   request and the response.

              (Request)         (Request)         (Request)
             [AVP(foo)=x]      [AVP(foo)=x]      [AVP(foo)=y]
      +------+  ----->  +------+  ----->  +------+  ----->  +------+
      |      |          |      |          |      |          |      |
      | NASB +----------+ DIA2 +----------+ DIA3 +----------+ DIA1 |
      |      |          |      |          |      |          |      |
      +------+  <-----  +------+  <-----  +------+  <-----  +------+
               (Answer)          (Answer)          (Answer)
             [AVP(foo)=b]      [AVP(foo)=b]      [AVP(foo)=a]
                           Figure 1: Proxy Chain

   This document describes how strong authentication and encryption can
   be provided in the Diameter protocol, by encapsulating CMS objects
   [3] in AVPs. The CMS object can also be used to carry X.509
   certificates and revocation lists.

   In the example provided in Figure 1, the originator of the request
   and response adds a digital signature that covers a set of AVPs
   within the message. The protected AVPs should not be changed by an
   intermediate proxy server (DIA2, DIA3), since the signature
   validation performed by the end server would fail.

   The Diameter base protocol also allows a Diameter broker to provide
   redirect services, as shown in Figure 2. The Diameter broker MAY
   return information to a requesting server that would allow the



Calhoun, Bulley, Farrell  expires October 2001                  [Page 4]


Internet-Draft                                                  May 2001


   servers to interact directly, bypassing the broker. This optimized
   approach reduces the complexity associated with end-to-end security.

                             +------------------+
                             |     Diameter     |
                             |      Broker      |
                             +------------------+
                              ^
                      Request |  Response +
                              |  Result Code =
                     Local    |  Redirect          Home
                      ISP     v                    ISP
                     +----------+              +----------+
                     | abc.net  |              | xyz.net  |
                     | Diameter |<------------>| Diameter |
                     |  Server  |              |  Server  |
                     +----------+    Direct    +----------+
                                 Communication
          Figure 2: Diameter Broker Returning Redirect Indication

   When redirect services are used, a network layer security protocol,
   such as IP Security, MAY be used to secure the traffic between the
   two Diameter servers. However, security at the application level may
   still be necessary in this network configuration, specifically the
   ability to authenticate a select set of AVPs. Brokers that operate in
   a redirect mode typically require that both Diameter servers sign the
   same set of AVPs, marked with the 'P' bit, in accounting records. The
   accounting record, signed by both parties is then forwarded to the
   broker via the local Diameter server. This provides the broker with
   some assurances that both networks agreed on the accounting data,
   which it MAY use for settlement purposes. If the underlying security
   protocol provides confidentiality, strong encryption MAY not be
   necessary in the redirect case.

   Given that asymmetric transform operations are expensive, Diameter
   servers may wish to use them only when dealing with inter-domain
   servers, as shown in Figure 3. This configuration is normally
   desirable since Diameter entities within a given administrative
   domain may inherently trust each other. Further, it is desirable to
   move this functionality to the edges, since NASes do not necessarily
   have the CPU power to perform expensive cryptographic operations.










Calhoun, Bulley, Farrell  expires October 2001                  [Page 5]


Internet-Draft                                                  May 2001


     +------------------------+
     |    Foreign Network     |
     |+-----+      +--------+ |      +--------+        +--------+
     ||     |      |Diameter| |      |Diameter|        |Diameter|
     || NAS +------+        +--------+        +--------+  Home  |
     ||     |      | Proxy  | |      | Broker |        | Server |
     |+-----+      +--------+ |      +--------+        +--------+
     |                        |
     +------------------------+
          <------------>    <-------------------------->
           <Hop-by-Hop>             <End-to-End>

                 Figure 3: Mixed Diameter Security Models


1.1  Requirements language

   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.2  Advertising extension support

   Diameter nodes conforming to this specification MAY advertise support
   by including the value of two (2) in either the Device-Reboot-Ind
   Command's [2] Auth-Extension-Id or Acct-Extension-Id AVPs.


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 a Diameter proxy
   server without detection.














Calhoun, Bulley, Farrell  expires October 2001                  [Page 6]


Internet-Draft                                                  May 2001


      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                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          AVP Length           |     Reserved        |P|R|V|R|M|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Vendor ID (opt)                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Data ...
      +-+-+-+-+-+-+-+-+
                       Figure 4: 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 e2e 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.

   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 use the end-to-end security
   extension. This is communicated during the End-to-End Security
   Association message exchange, listed in section 4.0.

   Finally, this section addresses the certificate profile to be used
   for this Diameter extension, which is a simplified profile of [4].


3.1  Usage Scenario

   When a Diameter node is about to send a message which MAY use end-
   to-end security, it must determine whether to use the end-to-end
   security service or not. We assume the Diameter node knows the user's
   NAI, which determines the user's realm.



Calhoun, Bulley, Farrell  expires October 2001                  [Page 7]


Internet-Draft                                                  May 2001


   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 E2E-SA-Setup-Request (ESSR) and E2E-SA-Setup-Answer
   (ESSA) messages to establish whether end-to-end security is required
   and if so, for which AVPs and which public key(s) to use.

   The originating node sends the ESSR message to a server in the
   destination realm. The ESSR 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.

   The destination node returns the ESSA 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:




Calhoun, Bulley, Farrell  expires October 2001                  [Page 8]


Internet-Draft                                                  May 2001


       - 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 ESSR message
       - the realm part of the user's NAI must occur as a subjectAltName
         (with the rfc822Address option) in the AAA server's
         certificate. This rfc822Address MUST be of the form "Diameter-
         <XXX>@<domain>" where <domain> is the NAI'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 ESSA 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 ESSR message

         If certificate status (revocation) is an issue for the Diameter
         node, then the ESSR message MAY contain a nonce value. The idea
         is that the sender of the ESSA makes OCSP requests on behalf of
         the Diameter node and returns the OCSP responses to the
         Diameter node as part of the ESSA message. The use of the nonce
         value ensures that the sender of the ESSA 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
         nonce more than once.]

         The ESSR MAY be signed. If the originating node has a private
         key and protection expectations for AVPs are specified, then
         the ESSR SHOULD be signed.

         The ESSA MUST be signed to prevent an intermediate node from
         modifying the protection expectations for AVPs. The ESSA MUST
         be signed a Diameter node from the destination realm (based on
         the signer's name).

         If e2e confidentiality or digial 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 NAI, which
   is typically added in the Host-Name AVP [1], as one of the values of
   the subjectAltName extension of the Certificate.  The NAI is to be



Calhoun, Bulley, Farrell  expires October 2001                  [Page 9]


Internet-Draft                                                  May 2001


   encoded as an rfc822Name within the subjectAltName.

   For Diameter nodes (capable of acting as recipients for e2e
   confidentiality), the NAI 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 NAI of the intended recipient (which is assumed to be
         known).

   In either case, the presence of the required NAI as an rfc822Name
   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 rfc822Name 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 [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.



Calhoun, Bulley, Farrell  expires October 2001                 [Page 10]


Internet-Draft                                                  May 2001


3.4 Reuse of CMS Content Encryption Keys

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

   [15] leaves open some issues, namely how to handle loss of a shared
   secret (say following a node 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 Diameter nodes may then use
   the ESSR/ESSA exchange, or cached asymmetric keys to rebuild their
   security association.

   In [15], the default value for the maximum number of decryptions
   allowed (CEKMaxDecrypts) when re-using a content encryption key is
   one. 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 (based on the Expected-Encrypted-AVP settings
   exchanged during the ESSR/ESSA 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?]


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
      --------------------------------------------------------
      E2E-SA-Setup-Request      ESSR      304           4.1
      E2E-SA-Setup-Answer       ESSA      304           4.2


4.1  E2E-SA-Setup-Request (ESSR) Command

   The E2E-SA-Setup-Request command, indicated by the Command-Code field



Calhoun, Bulley, Farrell  expires October 2001                 [Page 11]


Internet-Draft                                                  May 2001


   set to 304 and the 'R' bit set in the message flags field, is sent by
   a Diameter node to establish a Diameter End-to-End Security
   Association.


      <E2E-SA-Setup-Request> ::= < Diameter-Header: 304, R >
                                 { Origin-FQDN }
                                 { Origin-Realm }
                                 { Destination-Realm }
                               + { Local-CA-info }
                                 { Auth-Extension-Id }
                                 [ Destination-FQDN ]
                               * [ Expected-Signed-AVP ]
                               * [ Expected-Encrypted-AVP ]
                               * [ OCSP-Nonce ]
                              0*1[ CMS-Signed-Data ]
                               * [ Proxy-Info ]
                               * [ Route-Record ]


4.2  E2E-SA-Setup-Answer (ESSA) Command

   The E2E-SA-Setup-Answer command, indicated by the Command-Code field
   set to 304 and the 'A' bit set in the message flags field, is sent by
   a Diameter node in response to an ESSR message.

   <E2E-SA-Setup-Answer> ::= < Diameter-Header: 304, A >
                             { Origin-FQDN }
                             { Origin-Realm }
                          0*1{ CA-Chain }
                           + { AAA-Server-Certs }
                           * { OCSP-Responses }
                             { Destination-FQDN }
                             { Auth-Extension-Id }
                           * [ Expected-Signed-AVP ]
                           * [ Expected-Encrypted-AVP ]
                             [ CMS-Signed-Data ]
                           * [ Proxy-Info ]
                           * [ Route-Record ]


5.0 End-to-End Security Association Message Flow

   This section contains an example of a NAS in domain xyz.com,
   communicating with its local proxy, which in turn communicates with a
   Diameter 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 an end-to-end



Calhoun, Bulley, Farrell  expires October 2001                 [Page 12]


Internet-Draft                                                  May 2001


   security association message exchange, followed by an authentication
   request.

           +-------+            +-------+            +---------+
           |  NAS  |            | Proxy |            | abc.com |
           |       |            |  Srv  |            |Home Srv |
           +-------+            +-------+            +---------+
               |                    |                    |
               |DRI extensions 1, 2 |                    |
          (a)  |------------------->|                    |
               |DRI extension 1, -1 |                    |
          (b)  |<-------------------|                    |
               |         .          |DRI extensions 1, 2 |
          (c)  |                    |<-------------------|
               |                    |DRI extension 1, -1 |
          (d)  |                    |------------------->|
             ->| User alice@abc.com |                    |
          (e)  | Requests Access    |                    |
               |                    |                    |
               |       ESSR         |                    |
               | Dest-Realm=abc.com |                    |
               | CMS-Cert           |                    |
          (f)  |--------------------+------------------->|
               |                    |      ESSA          |
               |                    | Origin-FQDN=foo    |
               |                    | CMS-Cert           |
          (g)  |<-------------------+--------------------|
               | Auth-Request +     |                    |
               | CMS-Signed-Data    |                    |
               | Dest-FQDN=foo      |                    |
          (h)  |--------------------+------------------->|
               |                    | Auth-Answer +      |
               |                    | CMS-Encrypted-Data |
          (i)  |<-------------------+--------------------|
       Figure 5: Example of an End-to-End Security Association Setup

      (a) NAS sends a DRI message to its proxy server indicating that it
          supports extensions 1 (NASREQ) and 2 (E2E Security).

      (b) The proxy server sends a DRI message to the NAS indicating
          that it supports extension 1 (NASREQ), as well as the wildcard
          extension.

      (c) ABC.COM's Home Server sends a DRI message to a proxy server
          indicating that it supports extensions 1 (NASREQ) and 2 (E2E
          Security).

      (d) The proxy server sends a DRI message to ABC.COM's Home Server



Calhoun, Bulley, Farrell  expires October 2001                 [Page 13]


Internet-Draft                                                  May 2001


          indicating that it supports extension 1 (NASREQ), as well as
          the wildcard extension.

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

      (f) The NAS issues an ESSR message, with the Destination-Realm AVP
          set to abc.com, and its certificate in the CMS-Cert AVP. The
          ESSR 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 ESSR message, and replies
          with the ESSA message. The ESSA 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-FQDN AVP set to the value of the Origin-FQDN AVP
          in the ESSA. The message includes the CMS-Signed-AVP, which
          authenticates the AVPs that were requested by the Home Server
          in the ESSA.

      (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 ESSR.


6.0  End-to-End Security AVPs

   This section contains AVPs that are used to establish a Diameter
   End-to-End Security Association.


















Calhoun, Bulley, Farrell  expires October 2001                 [Page 14]


Internet-Draft                                                  May 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  |
   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-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 produce strongly protected
   Diameter messages.

   To package a set of AVPs as a MIME type, the AVPs are first
   concatenated in the order in which they occur in the Diameter
   message. The entire AVP MUST be input to the signing process, from
   the first byte of the AVP code to the last byte of the AVP data,
   including all other fields, length, reserved/flags, and optional
   vendor IDs, and padding.  The AVP MUST be input to the signing
   process in network byte order.

   The signature is calculated over the catenation of all the 'P' bit
   AVPs, but the AVPs themselves are not carried within the CMS-Signed-
   Data AVP. Instead, the digest value within the SignedData structure
   contains the digest over these AVPs. Multiple Diameter entities MAY



Calhoun, Bulley, Farrell  expires October 2001                 [Page 15]


Internet-Draft                                                  May 2001


   add their signatures to an existing 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 node's signature covers the existing
   signatures in the CMS object. A countersignature MUST cover all AVPs
   in the message that have the 'P' bit enabled (i.e. the same AVPs as
   the first signature). Receiving Diameter nodes MAY, but need not, be
   able to support the use of the countersignature attribute.

   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 prior to the AVP that have
   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. This means that where a set of AVPs is protected
   using CMS, the set MUST first be catenated a sequence of encoded
   AVPs.

   The entire AVP MUST be input to the encryption process, from the
   first byte of the AVP code to the last byte of the AVP data,
   including all other fields, length, reserved/flags, and optional
   vendor IDs, and padding. The AVP MUST be input to the encryption
   process in network byte order, and the encryptor is free to order
   AVPs whatever way it chooses. This value is then encrypted and used
   as the value of the EncryptedContent field within CMSEnvelopedData.




Calhoun, Bulley, Farrell  expires October 2001                 [Page 16]


Internet-Draft                                                  May 2001


   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
   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 are REQUIRED to be able to add a new CMS-Encrypted-
   Data AVP value and are also REQUIRED to 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, then 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.



Calhoun, Bulley, Farrell  expires October 2001                 [Page 17]


Internet-Draft                                                  May 2001


   This use of the CMS-Cert AVP can be used to "push" public key and
   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   = CA-Name Key-Hash
         CA-Name       = ; See Section 6.4.1
         Key-Hash      = ; See Section 6.4.2

   The Local-CA-Info AVP Data field contains the Certificate Authority's
   name in the CA-Name AVP, as well as a hash of the key in the Key-Hash
   AVP.

      +---------------------------------------------------------------+
      |                 AVP Header (AVP Code = 348)                   |
      +---------------------------------------------------------------+
      |                         CA-Name AVP                           |
      +---------------------------------------------------------------+
      |                         Key-Hash AVP                          |
      +---------------------------------------------------------------+


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".




Calhoun, Bulley, Farrell  expires October 2001                 [Page 18]


Internet-Draft                                                  May 2001


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
   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.

   [Issue: Currently the nonce value also indicates the wish to receive
   OCSP responses. It might be better to make this a grouped AVP with a
   flag and optional nonce.]


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. This AVP
   MUST only be included in an ESSA message for which the corresponding
   ESSR message contained an OCSP nonce.


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



Calhoun, Bulley, Farrell  expires October 2001                 [Page 19]


Internet-Draft                                                  May 2001


   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 ESSA message, one (and only one) of the
   Local-CA-info values from the corresponding ESSR 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.]


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-Code Vendor-Id
         AVP-Code       = ; See Section 6.11
         Vendor-Id      = ; See [1]

   A Diameter node adds the Expected-Signed-AVP AVP to inform the ESSR/A
   peer that any message received which contains the AVP specified in
   this AVP MUST be authenticated via the CMS-Signed-Data AVP.  The
   Vendor-Id MAY contain a non-zero value if the AVP specified in the
   AVP-Code AVP is vendor-specific.

      +---------------------------------------------------------------+
      |                 AVP Header (AVP Code = 356)                   |
      +---------------------------------------------------------------+
      |                        Vendor-Id AVP                          |
      +---------------------------------------------------------------+
      |                         AVP-Code 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-Code Vendor-Id
         AVP-Code       = ; See Section 6.11
         Vendor-Id      = ; See [1]




Calhoun, Bulley, Farrell  expires October 2001                 [Page 20]


Internet-Draft                                                  May 2001


   A Diameter node adds the Expected-Encrypted-AVP AVP to inform the
   ESSR/A peer that any message received which contains the AVP
   specified in this AVP MUST be encrypted via the CMS-Encrypted-Data
   AVP.  The Vendor-Id MAY contain a non-zero value if the AVP specified
   in the AVP-Code AVP is vendor-specific.

      +---------------------------------------------------------------+
      |                 AVP Header (AVP Code = 357)                   |
      +---------------------------------------------------------------+
      |                        Vendor-Id AVP                          |
      +---------------------------------------------------------------+
      |                         AVP-Code 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.


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 endpoints of an end-to-end security association 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.




Calhoun, Bulley, Farrell  expires October 2001                 [Page 21]


Internet-Draft                                                  May 2001


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


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], and extended in [13] and [14]. See section
   4.0 for the assignment of the namespace in this specification.


8.2  AVP Codes

   This specification assigns the values 348-359 from the AVP Code
   namespace defined in [1], and extended in [13] and [14]. 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 from the Result-Code
   AVP (AVP Code 268) value namespace defined in [1], and extended in
   [14].  See section 7.0 for the assignment of the namespace in this
   specification.


8.4  Extension Identifier

   This specification assigns the value two (2) to the Extension
   Identifier namespace defined in [1]. See section 1.2 for more
   information.


9.0  Security Considerations

   This document describes how end-to-end 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



Calhoun, Bulley, Farrell  expires October 2001                 [Page 22]


Internet-Draft                                                  May 2001


   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, A. Rubens, H. Akhtar, E. Guttman, "Diameter Base
        Protocol", draft-ietf-aaa-Diameter-04.txt, IETF work in pro-
        gress, May 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",
        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.




Calhoun, Bulley, Farrell  expires October 2001                 [Page 23]


Internet-Draft                                                  May 2001


   [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 Extension",
        draft-ietf-aaa-Diameter-nasreq-04.txt, IETF work in progress,
        May 2001.

   [14] P. Calhoun, C. Perkins, "Diameter Mobile IP Extensions", draft-
        ietf-aaa-Diameter-mobileip-04.txt, IETF work in progress, May
        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 the Diameter protocol:

   Bernard Aboba, Jari Arkko, William Bulley, Daniel C. Fox, Lol Grant,
   Ignacio Goyret, Nancy Greene, Peter Heitman, Paul Krumviede, Fergal
   Ladley, Ryan Moats, Victor Muslin, Kenneth Peirce, Sumit Vakil, John
   R. Vollbrecht, Jeff Weisberg and Glen Zorn


12.0  Authors' Addresses

   Questions about this memo can be directed to:

      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




Calhoun, Bulley, Farrell  expires October 2001                 [Page 24]


Internet-Draft                                                  May 2001


      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
   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."



Calhoun, Bulley, Farrell  expires October 2001                 [Page 25]


Internet-Draft                                                  May 2001


14.0  Expiration Date

   This memo is filed as <draft-ietf-aaa-diameter-e2e-sec-02.txt> and
   expires in October 2001.















































Calhoun, Bulley, Farrell  expires October 2001                 [Page 26]