Subject: [AAA-WG]: [issue] Diameter CMS Security - Remove DSA-TTL from PDSA message

From: Don Zick <[email-masked]>
Date: Mon, 11 Mar 2002 16:03:07 -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 diameter agent may establish security associations on behalf of access
devices. The access devices issue the PDSR message to request this. It
is simpler for the access devices if they do not have to re-issue the
PDSR because of DSA-TTL expiry. Also, the diameter agent may make use of
the same DSA for more than one access device; in this case it doesn't
make much sense for multiple access devices to be responsible for
re-establishing the same DSA.

Requested change:

Replace text from section 1.3:

  The PDSA MUST
  contain the TTL setting agreed by the proxy agent for its DSA.
  This information will allow the access device to re-issue a PDSR
  prior to the proxy's DSA expiry if it needs the DSA to remain
  active.

with this text:

  The proxy agent is responsible for re-establishing the DSA
  prior to expiration without any involvement by the access
  device.

Also, remove DSA-TTL from PDSA ABNF definition.

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 11 Mar 2002 20:32:50 -0800 (PST)

Assigned issue #307.

---

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

Don,

Reckon I'd be against this one at this stage (i.e. you might, but
haven't, convinced me;-),

> PDSR because of DSA-TTL expiry. 

Presumably the access device that sent the PDSR only did so because it
wants to be told (by an agent trusted via local configuration) that CMS 
will be used as appropriate. 

My take would be that without the TTL in the PDSA the agent would then
need a way to signal to the access device that CMS is about to go "off".
If true, that'd definitely not be simpler.

So, to me the simplification sounds a little nebulous; I understand 
how the current scheme can work and so would rather stick with it.

> Also, the diameter agent may make use of

There's no requirement that the agent in this case have many DSAs. If 
that were implied it would be wrong. The same TTL value can be used
in many PDSA messages if appropriate.

>   prior to expiration without any involvement by the access

If that were included, then what's the point of the PDSR/PDSA at
all?

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:00:35 -0500

Hi Stephen,

Comments inline.

Don

> how the current scheme can work and so would rather stick with it.

In section 1.3 underneath Figure 3 an optimized approach is explained.  With
this approach the proxy is responsible for re-establishing the DSA prior to
expiration without any involvement by the access device.  There is no
mechanism specified for this optimized approach to turn CMS "off".  I thought
it was necessary to bring down the connection between the access device and
the server if the PDSR/PDSA negotiated settings are no longer valid.  I don't
know if I'd want to wait for the TTL to expire before re-negotiating
PDSR/PDSA settings when there is a configuration change.  I guess I was just
trying to propose that DSA re-establishment always be handled in the way it
is handled with the optimized approach.

Do you think there are problems re-negotiating PDSR/PDSA settings with the
optimized approach explained under figure 3?

> in many PDSA messages if appropriate.

Okay

> If that were included, then what's the point of the PDSR/PDSA at

It informs the server that the access device is configured to require
CMS security.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 12 Mar 2002 14:55:13 +0000

Don,

Are you saying that the DSA-TTL is better being optional in the
ABNF, (rather than a MUST), because of the optimized case, where 
the value isn't needed by the access device? 

If so, I guess that's true, but I'd have though that leaving in 
the MUST is easier, even if the access device is going to ignore 
the value (e.g. in the optimized case), since the DSA-TTL is
useful for cases where the access device ought to control things.
(I.e. I'm still arguing to reject this one).

Say if a device were to require only occasional, short-lived,
"diverse peer", DSAs to be established. In that case, I'd say 
it'd be useful to allow the proxy to drop the DSA more rapidly, 
which can be done by including the DSA-TTL in the PDSA. I don't
know if that matches any of the real use cases though.

Regards,
Stephen.

---

From: Don Zick <[email-masked]>
Date: Tue, 12 Mar 2002 10:22:39 -0500

Stephen,

All I'm saying is that if my server has to be able to completely manage the
DSA-TTL for the optimized case then I don't see why it can't do the same for the
non-optimized case.  I think we have an opportunity to make things a little
simpler for the access device by not requiring it to manage the DSA-TTL.  Having
said that, the proposed change certainly isn't required for things to work and I
understand if such a request needs to be rejected at this point.

Regards,
Don

---

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

Don,

Fine so. In the absence of further reasons to change, let's
mark that a "reject" then.

Stephen.