Subject: [AAA-WG]: Issue 180: AAA-Server-Certs

From: Pat Calhoun <[email-masked]>
Date: Mon, 24 Sep 2001 04:54:02 -0700

All,

The AAA-Server-Cert allows more than one node to be the target of
a DSA, which is needed for various redundancy and PKI naming schemes.
This is quite clear from the spec already, so I would propose rejecting
this issue.

PatC

---

From: Miguel Ángel Monjas Llorente <[email-masked]>
Date: Mon, 24 Sep 2001 16:37:06 +0200

> This is quite clear from the spec already, so I would propose rejecting

Well, what is quite clear is the alleged necessity of this AVP. What
isn't so clear is the implications of this fact.

First of all, the DSAs aren't actually established between two nodes
but between a node and a realm. This fact will make more complex a
Diameter server:

- The DSA destination node will have to forward the certificate of the
originator to the AAA server that would process subsequent requests
(or maybe this secondary AAA server would have to fetch the
certificate of the originator once it receives a request from it; or
maybe the originator has to include its certificate in all its
messages when they include a digital signature).

- When encrypting AVPs, the originator node will have to maintain a
register of the actual AAA server with which it is communicating,
since it has to choose a specific certificate (or maybe include all
the possible receivers in the ReceiptInfo values). According to the
draft, all the AAA servers may have the same key ("For multiple
Diameter servers within a realm that share a public key" in section
3.2), but that's only a possibility.

BTW, if there's an only AAA server in the realm, its certificate
should be the one included in a CMS-Cert AVP, so that the following
row in section 8.0 is wrong:

   AAA-Server-Certs              | 0   | 1+  | 0   | 0   |

And should be replaced by

   AAA-Server-Certs              | 0   | 0+  | 0   | 0   |

  // M.A.

-- 
  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
  Ombú 3, 10th. 28045 Madrid - SPAIN -

---

From: Pat Calhoun <[email-masked]>
Date: Mon, 24 Sep 2001 07:39:09 -0700

> isn't so clear is the implications of this fact.

ok

> messages when they include a digital signature).

correct. The server in the dest realm can return the certs of all AAA servers
in its network.

> 3.2), but that's only a possibility.

sure, but it can maintain a cache of all servers, with the associated
cert.

> row in section 8.0 is wrong:

no, my understanding is that it would be in the AAA-Server-Cert.

>    AAA-Server-Certs              | 0   | 0+  | 0   | 0   |

Stephen?

PatC

---

From: Miguel Ángel Monjas Llorente <[email-masked]>
Date: Mon, 24 Sep 2001 18:33:40 +0200

> correct. The server in the dest realm can return the certs of all AAA servers

Well, I'm not actually talking about the destination server sending
the certificates of the AAA servers (using the AAA-Server-Certs AVP)
but about the way in which the destination node of the DSA forwards
the certificate of the originator.

As far as I understand, a DSA is established with one of the AAA
servers of the destination realm. This server includes its certificate
(and the certificates of the rest of AAA servers in the realm) in a
AAA-Server-Certs AVP. As the DSAR coming from the DSA originator may
include its certificate, this one would be available only for the
destination node of the DSA (but not for the rest of AAA servers of
the realm). Unless this certificate is available for such servers, the
DSA originator will always have to include its certificate any
Diameter message that contains a digital signature. Otherwise, the
protocol itself will have to specify that the actual destination node
of the DSA must "publish" this certificate in a repository or forward
this certificate to the rest of AAA servers of the realm (acording to
the specification itself, it's not allowed to push certificates
without establishing a DSA).

Besides, the destination node has to forward also the agreed TTL to
inform the rest of AAA servers about when they would have to
re-validate the certificates, hasn't it? (as well as the information
regarding the AVPs that must be signed or encrypted). Some kind of
proxy? 

Unless I'm missing anything, I reckon that the way in which
AAA-Server-Cerst is intended to work is a little bit difficult to
implement. I'd like some clarification about this point.

> sure, but it can maintain a cache of all servers, with the associated

Yes, of course, but as determinating with which AAA server it is
actually communicating can be a hard task, it will always encrypt the
CEK of a CMS-Encrypted-Data APV for ALL the AAA servers of the realm
(whose certs it's got, of course)

> no, my understanding is that it would be in the AAA-Server-Cert.

OK. I've checked it again and you're right. My fault...

Regards

  // M.A.