Subject: [AAA-WG]: [issue] Destination-Host in PDSR

From: Miguel Ángel Monjas Llorente <[email-masked]>
Date: Tue, 04 Sep 2001 15:25:51 +0200

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

The establishment of DSAs through evil proxies is usually a tricky
task. As stated in our discussion about issue 136, two main scenarios
are considered:

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

The ABNF grammar of a PDSR AVP is:

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

I'd like to focus in the second scenario. The agent has issued a DSAR
including the Destination-Realm AVP (let's use abc.com). An evil proxy
is in the route towards the home server, so that the evil proxy issues
a DSAA including the Origin-Host and the Origin-Realm AVPs (and a
DIAMETER_CAN_BE_A_COOL_CMS_PROXY result code). Following, the agent
issues a PDSR. Well, it will include again abc.com (but as
DSAR-Target-Domain) and the value of the Origin-Realm of the previous
DSAA as Destination-Realm of the PDSR.

However, it may happen that, once issued a PDSR with only a
Destination-Realm, it will be routed to other proxy in the same realm. 
Maybe this proxy doesn't support CMS (so that it issues a
DIAMETER_AINT_CMS_PROXY). Or maybe it supports CMS but, not being the
same proxy it won't be able to reuse any of the previously sent
parameters (parameters sent in the previous DSAR).

I understand that, in this scenario, a Destination-Host AVP must be
included in the PDSR. So that an optional Destination-Host AVP must be
included in the ABNF grammar of PDSR.

Requested change: 

a) Change the ABNF grammar of PDSR AVP including an optional field:

                 [ Destination-Host ]

b) Add explanatory text to 4.3

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 -