Subject: [AAA-WG]: CMS Security questions

From: Don Zick <[email-masked]>
Date: Tue, 12 Mar 2002 13:19:59 -0500

Hi Stephen,

Before I go hog-wild submitting any more issues could you please address
the following questions concerning the Diameter CMS Security draft?

1. In section 3.1, it states:

     We use Diameter Security Association Request (DSAR) and Diameter
     Security Association Answer (DSAA) messages to establish a DSA,
which
     specifies which AVPs should be encrypted, signed or both, as well
as
     which public key(s) to use.

   Now that the expected-signed and expected-encrypted AVPs have been
   removed, shouldn't the text "which specifies which AVPs should be
   encrypted, signed or both" be removed?

2. The AVP occurrence rules table in section 8 shows that at most 1
   AAA-Node-Cert AVP may appear in a DSAR or a DSAA.  However, the
   ABNF definition for the DSAR and DSAA indicate that any number
   of AAA-Node-Cert AVPs may appear.  Is the AVP occurrene rules
   table correct?  If so, shouldn't "public key(s)" mentioned in
   item 1 really be "public key"?

3. In section 3.1, it states:

     - Its local policy allows the given TTL, realm, AVP protection
       expectations, certification status, and other parameters.

   Now that the expected-signed and expected-encrypted AVPs have been
   removed, shouldn't the text "AVP protection expectations" be removed?

4. In section 3.1 it states:

     ...the destination node returns the DSAA message which contains:
       ...
       - public key certificates for the Diameter servers in the
realm...

   This goes back to question #2. Must a Diameter server know all of
   the certificates for all servers in its realm?  Why is that useful
   when the Diameter node is only establishing a DSA with a single
   server?

5. In section 3.1 it states:

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

   Shouldn't this requirement be removed now that expected-signed and
   expected-encrypted AVPs have been removed?

6. In section 3.2 it states:

     For multiple Diameter servers within a realm that share a public
key,
     each server's identity is encoded in the subjectAltName extension.
     This allows any server within a realm to decrypt AVPs intended for
     that realm.

   Why would a server that is not part of the DSA ever decrypt AVPs?
   Wouldn't there be potential problems with content encryption key
   reuse?

7. In section 4.4, the PDSR is defined. When an access device sends
   a PDSR to a local proxy, the local proxy will establish a DSA with
   a server in the DSAR-Target-Realm. If the access device sends an
   authentication request to the local proxy and the authentication
   request contains Destination-Realm but does not contain
   Destination-Host, must the local proxy add the Destination-Host
   AVP to the message to ensure that it is routed to the server in
   the Destination-Realm that has the DSA?  If this is a requirement
   I think it should be stated explicitly.

8. Section 6.3 provides some example encodings for encrypted and
   signed AVPs.  The examples indicate that different Diameter
   nodes can have different encryption and signing requirements.
   Aren't these examples misleading now that the expected-signed
   and expected-encrypted AVPs have been removed?  (All Diameter
   nodes share the same encryption and signing requirements.)

9. The AVP occurrence rules table and ABNF message definitions
   have some inconsistencies:

                        DSAR ABNF       DSAR Occurrence rules table
     AAA-Node-Cert        *               0-1

                        DSAA ABNF       DSAA Occurrence rules table
     AAA-Node-Cert        *               0-1
     OCSP-Responses       *               1+
     Origin-Realm         0*1             1
     Redirect-Host        not listed      0+
     Redirect-Host-Usage  not listed      0-1
     Redirect-Max-
         Cache-Time       not listed      0-1

10. DSAA ABNF has Local-CA-info surrounded by curly brackets. I
   think square brackets are correct.

11.Origin-State-Id listed as Original-State-Id in AVP occurrence table.

12.Section 3.1 states:

     Once the DSA is in place, any Diameter messages created by a DSA
peer
     that has a private key MUST contain a signature over all AVPs whose

     definition states that their 'P' bit MAY be set.

   I think the CMS-Encrypted-Data AVP is an exception to this rule. It
   only requires a signature if any of the encrypted AVPs contained in
   the CMS-Encrypted-Data AVP require signing.

13.Some typos:

   Section 1: "two different set of messages"
              "two different sets of messages"

   Section 1.2 "DSA would the NAS"
               "DSA would be the NAS"

                "initiate an DSAR"
                "initiate a DSAR"

   Section 1.3 "such an an aggregating relay"
               "such as an aggregating relay"

               "recelived"
               "received"

   Section 3.1 "MUST re-validated"
               "MUST be re-validated"

               "implemetors"
               "implementors"

   Section 5 "CAA" (in diagram)
             "CEA"

             "issues an DSAR message"
             "issues a DSAR message"

   Section 6.11 "lenght"
                "length"

Thanks,
Don

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 14 Mar 2002 11:02:57 +0000

Don,

Thanks for these. Let's create an omnibus issue for 'em all.
Responses embedded below.

Bernard - will you make this a new CMS issue? (Also #307 can,
I believe, be closed/rejected, given Don's mail [1]).

Stephen.

[1] http://www.merit.edu/mail.archives/aaa-wg/msg03431.html

Submitter name: Stephen Farrell
Submitter email address: [email-masked]
Date first submitted: March 14, 2002
Reference:
Document: CMS
Comment type: T/E
Priority: 1
Section: various
Rationale/Explanation of issue:

>    encrypted, signed or both" be removed?

Yes. Will do.

>    item 1 really be "public key"?

We do want to allow >1 certificate to be included (we're just 
insisting they all be verifiable from a single CA-Chain).

So, I'd go for changing the avp occurrence rule and leaving the
text and abnf alone.

>    removed, shouldn't the text "AVP protection expectations" be removed?

Yes.

>    when the Diameter node is only establishing a DSA with a single

Fixed with #2.

>    expected-encrypted AVPs have been removed?

Hmm...That's a reasonable point, but I'd (somewhat less than entirely 
convincingly) argue to stick with the DSAA MUST be signed position for 
the following reasons:

- A node producing a DSAA really has to have a private key for anything
  useful to subsequently happen, therefore requiring the signature
  doesn't require any additional code or administration, just the few
  additional CPU cycles required for signing this message.
- The signed AVPs from the DSAA (in particular the DSA-TTL) can't be
  modified by intermediaies, though that's not much of a threat 
  compared to modifying expected-* AVPs, I agree.
- It provides some assurance that the originator of the message is
  the entity that (the CA said) has the relevant private key. However, 
  for this to be better, a random challenge should be added to
  the DSAR and (that or a digest of the DSAR) reflected back in 
  the DSAA as a signed AVP (I was thinking of proposing this as 
  an addition to -04 but didn't).

>    Why would a server that is not part of the DSA ever decrypt AVPs?

Various forms of load-balancing I guess.

>    Wouldn't there be potential problems with content encryption key

Yes. As with reboots, so nothing new there.

>    I think it should be stated explicitly.

I guess we do need more text here and will add that. I guess I 
should change "authentication request" to "any Diameter message" in 
the above though?

>    nodes share the same encryption and signing requirements.)

The examples are based on requirements on AVPs which can be determined
from the RFC or by an astrologer. So I disagree that this is related
to the expected-* removal. 

>                         DSAR ABNF       DSAR Occurrence rules table

Was the above meant to be in your mail?
 
>                         DSAA ABNF       DSAA Occurrence rules table
                                            should be 0+

>      OCSP-Responses       *               1+
                                            should be 0+
>          Cache-Time       not listed      0-1
I don't know what's right for these. Want to suggest
something?

>    think square brackets are correct.

Disagree. Doesn't *{foo} mean "one or more", whereas *[foo] means
"zero or more". One or more is what's wanted.

> 11.Origin-State-Id listed as Original-State-Id in AVP occurrence table.

I'm guessing that Origin-State-Id is the right name?

>    the CMS-Encrypted-Data AVP require signing.

Good point. I'll add text indicating this.

>    Section 5 "CAA" (in diagram)
Thanks,
Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:[email-masked]
Ireland                             http://www.baltimore.com

---

From: Don Zick <[email-masked]>
Date: Fri, 15 Mar 2002 11:30:00 -0500

Hi Stephen,

comments inline...

> So, I'd go for changing the avp occurrence rule and leaving the

Okay

>   an addition to -04 but didn't).

I don't have an issue with requiring the signing, but can the text "to
prevent an intermediate node from modifying the protection expectations for
AVPs" be removed?

> should change "authentication request" to "any Diameter message" in

Okay. One other concern is that the Destination-Host AVP has the 'P' bit set.
If this AVP is added by a local proxy won't the proxy have to break the rules
and not set the 'P' bit? Otherwise the Destination-Host will not be able to
validate the CMS-Signed-Data AVP from the Origin-Host.

This brings up a bigger issue.  Suppose you have 3 Diameter nodes, A, B, and
C.  Suppose there is a DSA between A and C and that all messages between A
and C are routed through B.  Can server B ever add AVPs with the 'P' bit set
to a message? It seems not because then the CMS-Signed-Data AVP created by
A and C could no longer be validated. Is the CMS Security application
supposed to allow intermediate nodes to add AVPs and sign them?

> to the expected-* removal.

Okay, I see.

> Was the above meant to be in your mail?

Yes, this was the one inconsistency I noticed in the DSAR message.

> I don't know what's right for these. Want to suggest

Origin-Realm is a 1 for all the other DSA message and I think it should be 1
for the DSAA.  I *think* the redirect host AVPs should be allowed in the DSAA
as specified by the occurrence rules table, and should be added to the
DSAA ABNF.  I hope someone with more knowledge of redirect servers could
chime in here.

> "zero or more". One or more is what's wanted.

Okay, then there is another inconsistency between the DSAA ABNF and the DSAA
occurrence rule table settings.  Please change the occurrence rules table for
the DSAA to indicate Local-CA-info can occur 1+ times instead of 0+ times.

> I'm guessing that Origin-State-Id is the right name?

Yes

Thanks,
Don

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 15 Mar 2002 16:43:58 +0000

Don,

I think this mail might close down this batch issue.
Couple of things in-line below.

Stephen.

> prevent an intermediate node from modifying the protection expectations for

Sure.

> supposed to allow intermediate nodes to add AVPs and sign them?

No. We only support signing one set of AVPs and once a signature is 
attached that's it. That was a deliberate decision of the WG since the
alternative is just too complex to be worthwhile (and no-one really wanted
it either). Note that using countersignatures you can of course have as
many signatures as you like, they just have to be applied sequentially and
over the same set of AVPs.

A proxy behaving as you've desribed is broken. Adding an AVP with the
P bit set when a signature is present is not allowed.

> Yes, this was the one inconsistency I noticed in the DSAR message.

My fault - didn't notice the "R" :-)

> the DSAA to indicate Local-CA-info can occur 1+ times instead of 0+ times.

Ok.