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

From: Stephen Farrell <[email-masked]>
Date: Wed, 24 Oct 2001 19:00:07 +0100

And the one other outstanding one:

I'd argue that this is a "reject" given my suggested 
resolution of #185.

Stephen.

Issue 180: AAA-Server-Certs 
Submitter name: Miguel A. Monjas 
Submitter email address: [email-masked] 
Date first submitted: 2001-09-14 
Reference: 
Document: CMS-02 
Comment type: T 
Priority: 2 
Section: 6.6 
Rationale/Explanation of issue: 

It remains unclear for me the meaning of AAA-Server-Certs. As far as I 
understand, a DSA is established between two Diameter agents (not 
between an agent and a realm) so that no CMS-protected AVP can come 
from a node "outside" the DSA. If this supposition is right, including 
certificates of other home nodes is useless, since the initiator of 
the DSA wouldn't accept CMS AVPs from a different node although 
belonging also to the home realm. 

Requested change: 

Add clarifying text. 

-- 
____________________________________________________________
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: Miguel Ángel Monjas Llorente <[email-masked]>
Date: Wed, 24 Oct 2001 20:06:51 +0200

Hi all,

> I'd argue that this is a "reject" given my suggested

I've got currently a close deadline. Could you keep this issue as open
until Friday?

Regards

  // M.A.

---

From: Miguel Ángel Monjas Llorente <[email-masked]>
Date: Wed, 24 Oct 2001 20:25:21 +0200

> I'd argue that this is a "reject" given my suggested

After some convincing arguments by Stephen, I'll try to show my point
of view.

My main concern is the following: I understand that, given that it
isn't necessary to establish a previous DSA to send CMS-enabled AVPs
(#185), any of the AAA Servers of the realm can answer a client that
has established a DSA with an only server (let's call it the front-end
server). That's the light side and looks fine.

My concern is the back-end processing. I mean, how do the rest of the
servers of the realms know about parameters such as the TTL of the
Expected-*-AVPs of the existing DSA. AFAIK this communication isn't
covered by the protocol. If that's true, it has no sense to add this
AVP (AAA-Server-Certs) since there isn't a Diameter way to send this
parameters. Or maybe I'm wrong and there's a way. Please, need an
explanation :-))

Regards

  // M.A.

---

From: Miguel Ángel Monjas Llorente <[email-masked]>
Date: Wed, 24 Oct 2001 20:27:35 +0200

> servers of the realms know about parameters such as the TTL of the
                                                              ^^ or

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 24 Oct 2001 19:33:31 +0100

Hi Miguel,

I had assumed that all of the servers concerned would have the
same expected-* and ttl configuration settings. But, you're
right that that wasn't stated (good catch).

So, how about adding:

"All of the AAA nodes for which certificates are present in the
AAA-Server-Certs AVP MUST have the same DSA-related configuration
settings, that is: they MUST emit the same Expected-* AVPs and
have the same limits imposted on DSA TTLs."

I'd put this into 4.2 or 3.2 (end of page 13) or even 6.7. I
prefer 3.2 myself.

Does that close it out?

Stephen.

---

From: Miguel Ángel Monjas Llorente <[email-masked]>
Date: Wed, 24 Oct 2001 21:51:47 +0200

> I'd put this into 4.2 or 3.2 (end of page 13) or even 6.7. I

I prefer you decide it :-))

My last and only concern is the following: You're thinking about
server->client communication. Let's imagine a client and two servers (A
and B) in the realm R. The client has been instructed to establish a DSA
with the realm R and to ask that AVP1 and AVP2 will be signed when
receiving them from the realm. The DSA is actually established by server
A. How does server B finds out that AVP1 and AVP2 were agreed as signed
by server A?

Do you see my point?

Regards

  // M.A.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 25 Oct 2001 17:22:14 +0100

Miguel, All,

Well, this turned out not to be so easy to fix after all ;-(

The problem with AAA-Server-Certs was (as Miguel pointed out) 
that we don't have a way to pass on DSA state (in particular
the peer's Expected-Encrypted-AVP value being the nasty case) 
to support failover.

I just chatted to Pat about this & we reckon that we should
make the following changes:

- AAA-Server-Certs -> AAA-Node-Cert now containing only one
  cert
- We made the DSAR and DSAA pki stuff the same (i.e. each
  can now contain a Local-CA-Info, CA-Chain and AAA-Node-Cert).

Basically, the argument is that's its better to remove the
partial support for failover rather than having to rely on 
vendor-specific mechanisms being implemented on all servers
within a realm.

Stephen.

---

From: Miguel Ángel Monjas Llorente <[email-masked]>
Date: Thu, 25 Oct 2001 18:44:51 +0200

> vendor-specific mechanisms being implemented on all servers

It's OK for me. Go ahead!! :-))

  // M.A.