Subject: [AAA-WG]: CMS Security and TLS Certificates

From: Don Zick <[email-masked]>
Date: Fri, 26 Oct 2001 15:18:32 -0400

It would be nice if the same certificates could be used for both TLS and
CMS Security.  In order to allow for this, Diameter over TLS and
CMS Security should interpret the certificate dNSName in the same way.
(The Diameter base draft does not currently address how the certificate
dNSName should be used.)

From the  CMS Security Application draft, section 3.2:

>3.2  Certificate Requirements
>
>   Certificates used for the purposes of Diameter MUST conform to the
>   PKIX profile [4], and MUST also include a Diameter node's FQDN,
which
>   is typically added in the Origin-Host AVP [1], as one of the values
>   of the subjectAltName extension of the Certificate.  The FQDN is to
>   be encoded as a dNSName within the subjectAltName.
>
>   For Diameter nodes (capable of acting as recipients for
>   confidentiality), the FQDN MUST be of the form
>   "Diameter-<xxx>.<realm>". Other Diameter nodes MAY use this naming
>   scheme. Note that this naming constraint is for PKI purposes only,
>.   and in no way restricts a Diameter's host name.

The CMS Security application requires that the dNSName be set to
"Diameter-<xxx>.<realm>".  Rather than using this syntax, could we set
the dNSName to the Diameter-Identity string defined in the base draft
and make this a requirement for both TLS over Diameter and
CMS Security?  With the recent change to AAA-Server-Cert AVP, does
having a certificate per Diameter-Identity make sense?

Thanks,
Don

---

From: "Jari Arkko" <[email-masked]>
Date: Sat, 27 Oct 2001 07:18:02 +0300

> CMS Security?

1) I don't think the certificate syntax allows adding the port etc stuff
that we had in Diameter-Identity string.

2) The current format for the CMS security name (Diameter-xxx)
is there to act as a poor man's authorization tool: your network can
use one PKI, yet not all your devices will be seen as legal diameter
devices, only those that are prefixed with "Diameter" (by the way, why
the capitalization?) So, removing "Diameter-" is propably not
appropriate just to sync the TLS and CMS certs as you suggest.

3) It might though be possible to use the same scheme in TLS (and
IKE!) to require that they also use only Diameter-xxx names, for the
same authorization reason. Perhaps however this would have less
benefit in them, as TLS/IKE both work in a quite independent way
and typical current implements would *not* check the names in
this manner. So it could be that we can recommend this as a good
practise, but in reality it may not be feasible to change the implementations
to do the checks!

4) We may not need to do this, since as far as I can see, the certs
sufficient for CMS will be perfectly usable also for TLS and IKE.
Just set fqdn = Diameter-xxx! No additional authorization check,
but hey, this is hop-by-hop so the problem is much smaller.

So it would seem that my advice is to not change the specs,
unless I missed something.

Jari

---

From: Don Zick <[email-masked]>
Date: Tue, 30 Oct 2001 09:24:24 -0500

Hi Jari,

OK, the "Diameter-<xxx>.<realm>" syntax sounds fine.  I was a little concerned
about the case of multiple Diameter nodes running on the same host with the same
FQDN, but I guess that's not a case worth worrrying too much about.

I do have a couple of questions about TLS.  I'm not sure I followed your points
#3 and #4 below.  I have code that checks that the TLS certificate Common Name
matches the FQDN of the connecting peer.  CMS Security requires the FQDN to be
put into the certificate dNSName, not the certificate Common Name.  Wouldn't it
be helpful if the base draft stated that the certficate dNSName must be set in
the same manner for both TLS and CMS Security?

Thanks,
Don

---

From: Don Zick <[email-masked]>
Date: Mon, 29 Oct 2001 12:45:05 -0500

Hi Jari,

Okay, the "Diameter-<xxx>.<realm>" convention for the certificate dNSName should
be fine for CMS.  I was a little concerned about the case where multiple
Diameter nodes are configured on the same host with the same FQDN, but I guess
that's not a case worth worrrying too much about.

I do have some questions about TLS.  (I didn't completely follow what you said
in #3 and #4 below.) During TLS authentication, my code currently checks the
certificate Common Name field to make sure that it matches the FQDN of the
configured peer.  I could just as easily check the certificate dNSName field
instead of the Common Name field.  Wouldn't it be helpful for interoperability
if the base protocol specification stated that for TLS the certificate dNSName
should follow the same conventions that are used for CMS certificates?

Also, TLS usually performs server authentication but often does not perform
client authentication.  Diameter is a peer to peer protocol where it makes as
much sense to authenticate the client as it does the server.  I think it would
be helpful if the base draft stated that when TLS authentication is performed,
client authentication as well as server authentication is performed.

Your thoughts?

Thanks,
Don

---

From: "Jari Arkko" <[email-masked]>
Date: Tue, 30 Oct 2001 18:05:18 +0200

> I was a little concerned

Yes. If you need to run several Diameter instances on the same box, and yet
with different security certificates, then inventing additional FQDNs might
be your solution.

> the same manner for both TLS and CMS Security?

What I meant was that your standard TLS library would propably not check
that the peer's certificate has a name that uses the pattern 'Diameter-xxx'.
Of course, you can add this to a library (if you have access to it), or you
can build additional code in your application to do this. However, what I'm
saying is that I find these things more necessary in the case of CMS
end-to-end than in TLS h2h. Therefore, I wouldn't like to put additional
requirements to TLS libraries or IPsec/IKE implementations that they
do any sort of additional checks beyond those they currently already
perform.

> client authentication as well as server authentication is performed.

Good point. This indeed has to be done, and here we don't have the
concept of HTTP authentication to cover for the client side authentication.
Let's add some text to the spec to require the above.

Jari