Subject: [AAA-WG]: Issue 137: CMS Proxy's DSAAs

From: Pat Calhoun <[email-masked]>
Date: Mon, 27 Aug 2001 09:12:26 -0700

> When a proxy is involved in the establishment of a DSA, the proxy will
> reject the DSA indicating to the agent that:
> 
> - it is not possible to establish a DSA (Result-Code is
> DIAMETER_NO_CMS_THROUGH_PROXY)
> - it can act as a CMS proxy on behalf of it (Result-Code is
> DIAMETER_CAN_ACT_AS_CMS_PROXY). According to 1.2:
> 
>    The DSAA MUST be signed by the proxy agent, and include its
>    certificate, to allow the access device to validate the 
>    originator of the DSAA.
> 
> However, being the Result-Code a permanent failure code, the message
> will have the 'E' bit set, so that the message will not conform to the
> ABNF described for the command (DSAA). Then, on which AVPs is going to
> be applied the digital signature?

This assumes that the 'E' bit will be set for the above Result Codes,
but if one looks at the Result-Code value definitions:

      DIAMETER_NO_CMS_THROUGH_PROXY      5020
         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      5021
         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.

you can see that these are not defined as protocol errors, and the
following text can be found in the base protocol:

[...]
     E(rror)     - If set, the message contains a protocol error, and
                   the message will not conform to the ABNF described 
                   for this command. Messages with the 'E' bit set is 
                   commonly referred to as an error message. This bit 
                   MUST NOT be set in request messages. See section 7.2.
[...]
7.1.3  Protocol Errors

   Errors that fall within the Protocol Error category SHOULD be treated
   on a per-hop basis, and Diameter proxies MAY attempt to correct the
   error, if it is possible. Note that these errors MUST only be used in
   answer messages whose 'E' bit is set.

so as you can see from above, the 'E' bit wouldn't be set for errors
in the 5xxx class, which is where the CMS Result-Code AVP values are
defined.

So I propose that we reject this issue.

PatC

---

From: Miguel Ángel Monjas Llorente <[email-masked]>
Date: Tue, 28 Aug 2001 12:04:02 +0200

> So I propose that we reject this issue.

OK. I understand what you mean (I didn't read carefully the base
specification about the different kinds of errors).

But the fact I was trying to point is the following: what happens with
the format of a DSAA when a Permanent Error result code is issued by a
proxy? Which is the content of AAA-Server-Certs and DSA-TTL AVPs when
the result code is 5020 or 5021 (since no DSA is finally established)?

Comments?

  // M.A.

---

From: Pat Calhoun <[email-masked]>
Date: Tue, 28 Aug 2001 06:36:23 -0700

> the result code is 5020 or 5021 (since no DSA is finally established)?

So the issue is that these AVPs must be optional, but must be present
if the result code is successful. right?

PatC

---

From: Miguel Ángel Monjas Llorente <[email-masked]>
Date: Tue, 28 Aug 2001 16:04:38 +0200

> if the result code is successful. right?

Yes. I should have begun with that :-))

  // M.A.

---

From: Pat Calhoun <[email-masked]>
Date: Tue, 28 Aug 2001 09:15:14 -0700

> Yes. I should have begun with that :-))

so how abou the following:

"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-Server-Certs, DSA-TTL and
   CMS-Signed-Data AVPs MUST be present.

   Message Format

      <DSAA> ::= < Diameter-Header: 304, PXY >
                 { Result-Code }
                 { Origin-Host }
                 { Auth-Application-Id }
                 [ Origin-Realm ]
              0*1[ CA-Chain ]
               * [ AAA-Server-Certs ]
                 [ DSA-TTL }
               * [ OCSP-Responses ]
               * [ Expected-Signed-AVP ]
               * [ Expected-Encrypted-AVP ]
                 [ CMS-Signed-Data ]
                 [ Origin-State-Id ]
               * [ AVP ]
               * [ Proxy-Info ]
               * [ Route-Record ]"

PatC

---

From: Miguel Ángel Monjas Llorente <[email-masked]>
Date: Tue, 28 Aug 2001 18:39:23 +0200

> so how abou the following:

Looks great!

  // M.A.