Subject: [AAA-WG]: [issue] CMS proxy scenarios

From: Miguel Ángel Monjas Llorente <[email-masked]>
Date: Fri, 14 Sep 2001 10:52:56 +0200

Submitter name: Miguel A. Monjas
Submitter email address: [email-masked] 
Date first submitted: 2001-09-14
Reference:
http://www.merit.edu/mail.archives/aaa-wg/2001-08/msg00229.html
Document: CMS-02
Comment type: T
Priority: 2
Section: 1.2, 4.3
Rationale/Explanation of issue: 

As agreed in the discussion of issue 136, the description of two
scenarios regarding CMS proxies was introduced in the draft. These
scenarios are just examples, so that additional scenarios might be
considered. I've noticed that there might exist another scenario.

Let's consider a local AAA server that has to forward authentication
request from user that don't belong to its realm. It seems reasonable
that the AAA server establishes DSAs with other realms automatically
(that is, without any PDSA request from the clients). The local AAA
server would decide, accoding to its policies, with which realms it
must establish a DSA. This scenario seems reasonable since it puts the
intelligence of the system in the Diameter node and not in the client.

As a consecuence, at least three scenarios could be described. The two
escenarios also covered by the draft (as agreed on issue 136's
discussion):

   - The access device does not have the cryptographic ability to
     handle the 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 and provide the
     appropriate Local-CA-Info and the expected OCSP response from
     the DSA peer.

   - The access device has the cryptographic ability to perform the
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.

And an additional scenario (which IMHO could be even more common):

   - The access device does not have the cryptographic ability to
     handle the CMS functions locally but does not request such
     services from the local agent. Instead, the local agent has
     been configured to establish DSAs with certain realms in an
     automatic way, so that the existence of DSAs is transparent
     for the access device.

Requested change: 

Add such scenario to the draft. However, as this new scenario doesn't
requires a previous PDSA request, it looks like that this scenario
shouldn't be added to section 4.3 but to section 1.2. And that's a
problem, since Pat already stated that in order to add the scenarios
to section 1.2 a major "surgery taks" might be necessary.

If Pat and the rest of the WG agrees on adding this issue, I'll be
able to carry out this task.

Regards

  // M.A.

-- 
  Miguel Angel Monjas Llorente
  Systems Engineer, GSM/UMTS Systems Management
  Ericsson España, S.A. (EEM) UMTS/GSM Databases
  Tel: +34 91 3393605                 Mob: +34 629 570196
  <mailto:[email-masked]>  Fax: +34 91 3392538
  Retama 1, 4th. 28045 Madrid - SPAIN -

---

From: Pat Calhoun <[email-masked]>
Date: Sun, 16 Sep 2001 08:27:02 -0700

Although I tried hard to avoid re-writing this section, after reading 1.2
some more, I found some inconsistencies, so a re-write was probably in the
best interest of the WG :(

So, I've followed Miguel's proposed approach, and propose the following text
(of course, I removed the scenarios from section 4.3):

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

   Diameter messages between two participants of a DSA would fail
   verification if a proxy agent were to modify any protected AVPs.
   Therefore proxy agents either MUST NOT modify protected AVPs or else
   MUST NOT allow the DSA to be established. 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 the 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 and provide the
        appropriate Local-CA-Info and the expected OCSP response from
      - The access device has the cryptographic ability to perform the
        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.1 should be used
   instead.

   When a local agent receives a DSAR, it has the following options:
      - The local agent rejects all DSARs 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 all DSARs 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
        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, which it could be configured to only
        accept such DSAA messages from agents within its realm, 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 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-Domain = abc.com

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

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

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

            Figure 3: Establishing Security through Proxy Agent

   An optimized approach also allows the PDSR to be sent by the access
   device without the DSAR-Target-Domain AVP. This message is used to
   inform the proxy that it MUST establish a Diameter security
   association for all realms it will be communicating with on behalf of
   the access device.

   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.

Comments appreciated,

PatC

---

From: Miguel Ángel Monjas Llorente <[email-masked]>
Date: Mon, 17 Sep 2001 13:36:25 +0200

>         handle the CMS functions locally, and therefore requests such
                     ^^^^^^^^^^^^^

As discussed in issue #178 a more specific name would be used (maybe
"security CMS functions")

        the DSA peer.

>         CMS functions, but a proxy agent is in the route towards the
          ^^^^^^^^^^^^^

>       - The access device MAY have the cryptographic ability to perform
                            ^^^
This isn't a requirement (just a statement) so that maybe capital
letters aren't necessary.

>         CMS functions locally, but does not request a DSAR to request a
          ^^^^^^^^^^^^^
>        mno.net           mno.net           xyz.net           abc.com

No more comments

Regards

  // M.A.

---

From: Miguel Ángel Monjas Llorente <[email-masked]>
Date: Mon, 17 Sep 2001 19:22:30 +0200

An additional point: a Diameter proxy can deny a DSA setup attempt
through it by two reasons:

- Because it would modify any of the AVPs requested as protected, so
that the participants of the DSA would detect modifications in some of
the AVPs of the message.
- Because the proxy has been configured to act as a CMS proxy only
when the target of the DSA is within an allowed set.

This last condition hasn't been included. I would include a clarifying
text

>         whose Result-Code AVP is set to DIAMETER_NO_CMS_THROUGH_PROXY.

         This rejection can be due to the fact that the proxy would
modify
         some of the AVPs requested as protected or because, even not
         modifying any AVP, it has been configured not to allow a
         subsequent DSA with the given domain.

Regards

  // M.A.

  Ombú 3, 10th. 28045 Madrid - SPAIN -