Subject: [AAA-WG]: Issue 138: Signed DSA messages

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

> However, I'm a little bit concerned when the presence of a 
> CMS-Signed-Data AVP is required. This AVP contains a digital signature 
> on other (or others) AVPs. Those protected AVPs must have the 'P' bit 
> set. But let's imagine that neither of the AVPs included in the 
> message have the 'P' bit set (maybe because the implementation does 
> not consider that they must be protected). I assume that the 
> implementation must detect those cases and, when a CMS-Signed-Data AVP 
> is required, set the 'P' bit of an AVP, maybe chosen randomly or maybe 
> fixed in the configuration (for example, the DSA-TTL AVP is always 
> present, so that the implementation might be configured to protect it 
> always when a digital signature is required). Is this issue up to the 
> implementation or should be specified in the specification? 

This issue has to do with the fact that there is no mandatory AVP
in the DSAA, which MUST be signed, whose 'P' bit MUST be set. One
proposal (above) is to require that the DSA-TTL AVP MUST have the 'P'
bit set. However, the DSA-TTL is also mandatory in the DSAR, which
currently states that it SHOULD be signed, and such a change would
make it a MUST be signed.

I propose that the AAA-Server-Certs AVP MUST have the 'P' bit set,
which will require the presence of the CMS-Signed-AVP AVP.

PatC

---

From: Miguel Ángel Monjas Llorente <[email-masked]>
Date: Tue, 28 Aug 2001 11:45:05 +0200

> which will require the presence of the CMS-Signed-AVP AVP.

The solution seems good to me. However, it only solves half the
problem. I mean, it deals only with the DSAA message. But, what
happens with the DSAR message? There is also no mandatory AVP in the
DSAR. Expected-Signed-AVP and Expected-Encrypted-AVP are mandatory to
protect, so that, if issued, the must be signed. But, what happens if
no such AVPs are included in the DSAR?

Let's imagine the following scenario. A NAS is wishing to send
accounting messages to a Home Server. It's supposed that such messages
will contain AVPs that must be encrypted. But the indication about
such fact will be carried by the DSAA issued by the Home Server, not
by the NAS. So that, the NAS will establish a DSA with the Home Server
in order to send subsequently accounting messages. It's up to the Home
Server to include an Expected-Encrypted-AVP in its DSAA. The DSAR
won't include any AVP which must be protected. If so, the problem is
the same as the stated in the original issue....

Comments?

  // M.A.

---

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

> the same as the stated in the original issue....

That's because protecting the DSAR is a SHOULD, not a MUST. If one includes
the expected-*****-AVP, then it will have to protect the message. Adding a
mandatory AVP, which has the 'P' bit always set, would now make protecting
the DSAR a MUST, and text throughout the spec would have to be revised to
reflect this change.

PatC

---

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

> the DSAR a MUST, and text throughout the spec would have to be revised to

No such change is necessary.

Maybe the point is that protecting the DSAR is a MUST only when a
Expected-*-AVP is included and a MAY in the rest of the cases. I mean,
according to the definition of the command, the paragraph (third in
the page 12) might be something like this:

   The DSAR MAY include a CMS-Signed-Data AVP. If the originating node
   has a private key, it might specify protection expectations for
AVPs.
   If so, the DSAR MUST include a CMS-Signed-Data AVP.

Regards

  // M.A.

---

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

>    If so, the DSAR MUST include a CMS-Signed-Data AVP.

but the current text (in my version of the draft) is:

4.1  Diameter-Security-Association-Request

   The Diameter-Security-Association-Request command, indicated by the
   Command-Code field set to 304 and the 'R' bit set in the message
   flags field, is sent by a Diameter node to establish a Diameter
   Security Association. The DSAR message MUST NOT be used simply as 
   a convenient certificate distribution protocol without establishing 
   a DSA. The CMS-Signed-Data AVP MUST be present if any AVP in the 
   message has the 'P' bit set.

Is anything else necessary? Doesn't the above pretty much state what 
you did above, or was there something else needed?

PatC

---

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

> you did above, or was there something else needed?

No. It's OK. Just take into account that my proposal and your
statement belong to different parts of the draft (mine to 3.1 and
yours to 4.1). Both say the same, so if a paragraph describing the
signature "status" of DSAR is included in 3.1, it should be similar to
my paragraph (otherwise, that paragraph, and the one describing DSAA
should be dropped).

Regards

  // M.A.

---

From: Pat Calhoun <[email-masked]>
Date: Wed, 29 Aug 2001 04:56:55 -0700

> my paragraph (otherwise, that paragraph, and the one describing DSAA

Oh, I see that there is a similar sentence for the DSAA in 3.1, so how about
I add the following:

  - the DSAR message MAY include the CMS-Signed-Data AVP. If the
    originating node has a private key, and it includes AVPs whose
    'P' bit is enabled, the CMS-Signed-Data AVP MUST be present.

PatC

---

From: Miguel Ángel Monjas Llorente <[email-masked]>
Date: Wed, 29 Aug 2001 14:35:15 +0200

>     'P' bit is enabled, the CMS-Signed-Data AVP MUST be present.

Perfect!!

  // M.A.