Subject: [AAA-WG]: Stupid CMS Questions/Comments

From: David Frascone <[email-masked]>
Date: Wed, 6 Feb 2002 08:12:21 -0600

Sorry, I've finally studied the CMS draft sufficently enough to be confused:

First, in section 1.0:

	Why is it a MUST for Diameter clients to support PDS?  Either I'm	
	confused as to what a client is, or I think this is an error.
	If a NAS is a client, then forcing it to support CMS is asking too
	much.  My vote is change MUST -> SHOULD.

I think I understand the proxying . . . please correct me if I'm wrong:

	When a proxy issues DIAMETER_CAN_ACT_AS_CMS_PROXY, and the client 
	accepts it, it really ends up making two end-to-end connections,
	right?  The entire message is decrypted, and re-encrypted/signed
	for the destination (or next proxy), right?  

	So, it's just like hop-by-hop security, except, instead of every
	diameter hop decrypting the messages, only the proxies you trust
	decrypt the messages.

In section 4.2, shouldn't [CMS-Singed-Data] be 0*1[CMS-Signed-Data] like
in the DSAR?

In section 5.0, it mentions that when sending DSARs, you can provide a list
of AVPs that you expect to be encrypted, but I can't seem to find the format
of that AVP list.

Also in that example, the home server did not return a certificate, indicating
one way encryption.  How can you request two way encryption in a DSAR?  Is
it possible?  Or, do the holders of certificates mandate whether or not it
can receive encrypted data?

Sorry if any of these questions are ignorant . . . 

-Dave

---

From: "Jari Arkko" <[email-masked]>
Date: Fri, 8 Feb 2002 22:24:29 +0200

> much.  My vote is change MUST -> SHOULD.

No, the idea of the PDS[RA] is to have the NAS *not* need
to support CMS, and allow the local ISP proxy to handle it
on its behalf.

(But a question to you: do a find some part of the text
misleading in this respect? If so, we should fix it.)

> for the destination (or next proxy), right?  

No, just hbh protection to the proxy, then real CMS protection to the
end of the path.

> In section 4.2, shouldn't [CMS-Singed-Data] be 0*1[CMS-Signed-Data] like

I quote section 3.1:

   "The DSAR message MAY include the CMS-Signed-Data AVP. If the
   originating node has a private key, and it includes AVPs whose 'P'
   bit set, the CMS-Signed-Data AVP MUST be present.

   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."

> of AVPs that you expect to be encrypted, but I can't seem to find the format

You know, I can't find it either. I'm not sure if this is because it's late
friday evening or because it isn't described anywhere... someone?

> can receive encrypted data?

If you are talking about draft-ietf-aaa-diameter-cms-sec-03.txt and the
example in section 5 *does* return a cert. On the other hand, it states
CMS-Cert, which isn't defined anywhere. It is also referenced from base,
and not defined... looks like an issue needs to be filed, or at least the
issue data base needs to be checked if this has already been fixed.

Jari

---

From: David Frascone <[email-masked]>
Date: Fri, 8 Feb 2002 14:50:13 -0600

Ok, I think I've got a handle on it now.  (comments inline)

> misleading in this respect? If so, we should fix it.)

I was mistakenly assuming that PDS[RA]'s were setting up hops of 
encryption.  See below.

> No, just hbh protection to the proxy, then real CMS protection to the

Ok, so when the PDS[RA] is issued, the proxy and the other side form the
Security Association.  Data is "in the clear" from the originating side to
the proxy, then the proxy uses CMS to protect it to the far side.  I get
it.

What happens if the proxy receives the DIAMETER_CAN_ACT_AS_CMS_PROXY from
another hop?  It seems that the originator of the message should be the only
entity that can decide if a message should be sent in the clear, right?

> issue data base needs to be checked if this has already been fixed.

Ok, then, how is it decided what should or should not be encrypted.  The
draft seems to have two mechanisms, the may-encrypt flag in the dictionary,
and the mystical list of avps.

We need to better define that list.

-Dave

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 9 Feb 2002 06:16:51 -0800 (PST)

Can someone file an issue on this, suggesting new text that could make
this more clear?