Subject: [AAA-WG]: [issue] Diameter CMS Security - Require AAA-Node-Cert in DSAR and DSAA

From: Don Zick <[email-masked]>
Date: Mon, 11 Mar 2002 16:49:59 -0500

Submitter name: Don Zick
Submitter email address: [email-masked]
Date first submitted: March 11, 2002
Reference:
Document: cms
Comment type: T
Priority: 1
Section:
Rationale/Explanation of issue

A single occurrence of the AAA-Node-Cert AVP should be required in the
DSAR and the DSAA.

The Diameter CMS Security draft states (in section 3):
  In order to encrypt AVPs for a recipient, the originating Diameter
  node must have a copy of the recipient's public key. There are many
  well-known key retrieval schemes (e.g. LDAP [CERTLDAP]), but this
  specification also allows for the transportation of certificates
  within Diameter AVPs, which is expected to simplify implementations.

If inclusion of the AAA-Node-Cert AVP is optional then the expected
simplification in implementations is lost because compliant
implementations must be able to handle DSAR and DSAA messages that don't
include the AAA-Node-Cert AVPs.

Requested change:

Please update the occurrence rules table and the ABNF definitions for
the DSAR and DSAA to indicate that exactly 1 occurrence of the
AAA-Node-Cert must be present.

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 11 Mar 2002 15:00:54 -0800

> include the AAA-Node-Cert AVPs.

I disagree: compliant implementations must be able to handle DSAR and DSAA
messages that don't
include the AAA-Node-Cert AVPs, but they do _not_ have to include e.g. an
LDAP client and are therefore simpler.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 12 Mar 2002 11:41:22 +0000

Don,

I'd be with Glen on this one and would rather not insist that
certs must be present.

Also, note that if all that's needed is encryption from Alice 
to Bod, and Alice sends a DSAR, there's no need for Alice to 
ever have a certificate of her own.

Similarly, Bob's DSAA could (though I think it'd be unwise),
omit Bob's cert if somehow Bob knows that Alice will have
it via some other route.

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: Tue, 12 Mar 2002 09:16:06 -0500

Glen,

I'm sorry I'm not understanding your point.  If Diameter nodes have their own
certs available, why not just always stick them in the DSAR/DSAA messages so
that they're always available when needed?  What is the drawback of doing
this?  If my implementation must be able to handle DSAR/DSAA messages without
the AAA-Node-Cert AVP then don't I have to implement a scheme for retrieving
the certificate information elsewhere?

Don

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 12 Mar 2002 15:41:26 +0000

Don,

1. Not all nodes that can be party to a DSA need have 
certificates - only signers or decryptors actually need 
them. Verifiers and encryptors don't (if they don't do the 
opposite operations, that is). If AAA-Node-Cert were
mandatory, then every access device that wanted to encrypt
using CMS would have to get a cert that it'd never use.

2. Currently both DSAR and DSAA have the same three AVPs for 
cert-stuff, in the same order (below). That ought to simplify
coding.

              * { Local-CA-info }
              0*1[ CA-Chain ]
               * [ AAA-Node-Cert ]

3. If someone develops a Diameter implementation that uses 
standard PKI libraries, its very likely that they can get
certs from elsewhere too (e.g. local files, databases, ldap,
etc.). There's no reason to insist that a AAA-Node-Cert
always be present (it is however, advisable to include one 
if you've got one).

4. A DSA peer can basically accept a certificate it finds
on the floor so long as it meets the PKI and specific naming
rules contained/referenced in the CMS draft. That is, 
if a node can find a "better" cert than that supplied by the
peer, that's ok too. This can and does happen - say if there
are disjoint PKIs and the node in question has a cert for the 
same naming and key pair in each of the PKI. If its valid
to find a good cert anywhere, it seems wrong to insist that
some certificate is always sent in the protocol.

I think that's sufficient reason to stick with the ABNF we've
got.

Stephen.

---

From: Don Zick <[email-masked]>
Date: Tue, 12 Mar 2002 15:42:40 -0500

Hi Stephen,

I'm still struggling with this issue.  I'm not quite ready to give up on it.
Please see comments inline.

> using CMS would have to get a cert that it'd never use.

When a DSA is established I think the participating Diameter nodes will always
need to generate the CMS-Signed-Data AVP because most AVPs defined in the base
draft have the 'P' bit set (including Origin-Host, Origin-Realm, Destination-Host,
and Destination-Realm).   Practically speaking, all nodes that participate in a
Diameter DSA need a certificate.

> always be present (it is however, advisable to include one

No doubt certs can be obtained elsewhere, but it requires that a database of certs
be maintained and be made available to all Diameter nodes that can participate in
a DSA.  It seems much more scalable to only have to install a Diameter node's cert
on the Diameter node.

The reason for insisting that a AAA-Node-Cert always be present is that it is
easier to implement and configure.

> some certificate is always sent in the protocol.

I still don't see what harm it would cause if the DSAR and DSAA always included
the AAA-Node-Cert AVP.  If a Diameter implementation wanted to look up certificate
information in a database to find a "better" certificate nothing would prevent it
from doing so, but it would never be required to do so.  It may be valid to find a
good cert anywhere but it makes life simpler if you know of one place where the
cert can always be found.

(Side note: If it is reasonable to maintain a store of certificates for Diameter
nodes then I would suggest doing away with security associations altogether.
Diameter nodes could generate the CMS-Encrypted-Data and CMS-Signed-Data AVPs when
local policy indicates end-to-end security is enabled. Receiving nodes could cache
the certificate information required to interpret a sender's encrypted and signed
AVPs. I suggest this because I'm concerned about Mobile Node handoffs.  Mobile
Node handoffs require the use of multiple DSAs. The number of message exchanges
required to process the handoff request and to potentially activate DSAs is
problematic.  I realize that this would be a very big change and I'm just
mentioning it as a passing thought because I'm concerned about the complexity of
Mobile Node handoffs.)

---

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

Don,

> Please see comments inline.

Sure, but IMO point 1 below is the show-stopper. Much as I like to
see people needing certs (i.e. the things our poducts do a very
nice job of producing:-), it would be a mistake to insist that every
Diameter node that wants to use CMS has to have a cert. 

The encryptor-only use case is a real one and therefore we can't
force such nodes to have to include all the s/w, configuration and
administration (not to mention the couple of dollars) needed to 
end up with a certificate they then include in a DSAR for no 
reason whatsoever.

Stephen.

---

From: Don Zick <[email-masked]>
Date: Thu, 14 Mar 2002 08:58:29 -0500

Hi Stephen,

Okay, so the point I was missing is that if a node doesn't have a private key it
can still perform encryption but cannot sign. Would you agree with this text?

  "If a DSA peer is to sign or decrypt AVPs then it MUST send a certificate to
its DSA peer when the DSA is established."

Don

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 14 Mar 2002 14:06:07 +0000

I could buy that sentence with any of MUST/SHOULD/MAY, but lets 
take what you've proposed for now.

So the summary is: no change to the abnf, and add this new MUST
where the AVP is defined (section 6.6).

Any other inputs before we (ask Bernard to) add this as another
CMS issue (so that I include it when editing)?

Stephen.

---

From: Don Zick <[email-masked]>
Date: Thu, 14 Mar 2002 09:15:59 -0500

Hi Stephen,
I don't have any other issues regarding the AAA-Node-Cert AVP occurrence rules.
Thanks,
Don