Subject: [AAA-WG]: Signing of DSA requests and aswers

From: Miguel Ángel Monjas Llorente <[email-masked]>
Date: Tue, 14 Aug 2001 12:00:15 +0200

Hi,

I've dealing with CMS Security Application draft and there are some
issues that remain unclear for me.

In 3.1 (Usage scenario), it's said that:

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

As far as I understand, any Diameter message that includes an AVP with
the P flag set, must include a CMS-Signed-Data containing the digital
signature of those AVPs. In 6.9 and 6.10, it's stated that both
Expected-Signed-AVP and Expected-Encrypted-AVP must be authenticated
using the CMS-Signed-Data AVP. According to all these points, wouldn't
be necessary to change the previous paragraph and write:

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

since protection expectations for AVPs can only refer to
Expected-Signed-AVP and Expected-Encrypted-AVP

The next paragraph in 3.1 is the following:

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

Neither of the mandatory AVPs of this command (Result-Code,
Origin-Host, Origin-Realm, CA-Chain, AAA-Server-Certs, OCSP-Responses,
Destination-Host, Auth-Application-Id, DSA-TTL) must be protected
(according to 6.0). So that, if the signing of the answer is
mandatory, it will be necessary to protect an AVP (just to have any
AVP to sign) or to include a field whose protection is mandatory. I'm
not really sure about how to deal with this.

And finally an editorial question. I don't think that the sentence:
"The DSA(R|A) (MAY|MUST) be signed". In fact, only protected AVPs
inside the command are signed, so that I think it would be more
appropriate to say "The DSA(R|A) (MAY|MUST) include a digital
signature". What do you think?

Regards

-- 
  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: Tue, 14 Aug 2001 09:41:46 -0700

>    protection expectations for AVPs are specified, then the DSAR MUST

yes, you are correct. I would file an issue on this.

> not really sure about how to deal with this.

to be clear, these AVPs MAY have the 'P' bit set, according to section 6.
So, the issue is that it is a MAY, and not a MUST, right?

> signature". What do you think?

How about "... (MAY|MUST) include the CMS-Signed-Data AVP" instead?

PatC

---

From: Miguel Ángel Monjas Llorente <[email-masked]>
Date: Tue, 14 Aug 2001 19:00:21 +0200

> yes, you are correct. I would file an issue on this.

OK

> So, the issue is that it is a MAY, and not a MUST, right?

That's right. I just wanted to point the fact that in some extreme
conditions, the command would fail if the implementation wasn't quite
careful.

> How about "... (MAY|MUST) include the CMS-Signed-Data AVP" instead?

Perfect!!! :-))

  // M.A.

---

From: Miguel Ángel Monjas Llorente <[email-masked]>
Date: Mon, 20 Aug 2001 15:29:01 +0200

> So, the issue is that it is a MAY, and not a MUST, right?

Yes. That's right. But I've just noticed that this change must affect
not only the paragraph written down above but also the following
paragraph (also in 3.1 Usage Scenario, in the check list of the DSAR
originator):

   - the DSAA 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 DSAR message

Logically, this item must be replaced by another. Maybe the following:

   - the DSAA message MAY include a CMS-Signed-Data AVP. If present,
     this signature MUST be validated and the signer's certificate
     chain MUST terminate as a CA mentioned in the DSAR message

Regards

  // M.A.