Subject: [AAA-WG]: Issue 136: Proxy's DSAR on behalf of a client

From: Pat Calhoun <[email-masked]>
Date: Mon, 27 Aug 2001 09:01:52 -0700

Miguel,

I've been reading this issue, and I don't understand it :(

The issue states that a DSA created by a proxy on behalf of a client
should use some information from the first DSAR. I'm not sure what
the first DSAR is. Perhaps you meant PDSR, but the PDSR doesn't
include these AVPs.

Any help would be appreciated,

PatC

---

From: Miguel Ángel Monjas Llorente <[email-masked]>
Date: Tue, 28 Aug 2001 15:40:11 +0200

> Any help would be appreciated,

OK. I've made a mistake with this issue. I'll try to explain it. The
point is that, according to figure 3, I thought that a previous DSA
setup attempt was necessary to issue a PDSR. If so, it was natural to
think that there must be some relationship between the parameters of
the DSA setup attempt and the ones used by the proxy to establish it
own DSA with the Home Server.

There are actually two scenarios regarding proxy agents and CMS:

- The NAS hasn't got any cryptographic capability (or knows that
there's a proxy in its route or has been configured for always issuing
a PDSR to its aggregating proxy), so that it issues a PDSR. It's up to
the proxy to choose a DSA-TTL, provide Local-CA-Info or request OCSP
responses.

- The NAS has cryptographic capabilities (and doesn't know whether
there's a proxy in its route). If so, it issues a DSAR when he needs
it (according to its policy). The proxy provides the appropriate
result code and, if the NAS allows to use it as CMS proxy, it will
issue a PDSR. However, the proxy doesn't maintain any data from
previous DSA setup attempst, so that its own DSAR uses parameters 
according to its policy, not to previous DSA setup data.

Just a clarification, I'd add the following paragraph before the last
one in page 6:

If the access device determines that it is able to allow the proxy
agent
to establish a DSA on its behalf, it would issue a Proxy Diameter
Security Association Request (PDSR). This request MUST contain the
realm
with wich the access server wants the server to establish a DSA. The
proxy agent MUST use its own policy to establish the DSA (without
using
any of the parameters provided by the access device in the previous
DSA
setup attempt). Once established the DSA, the proxy agent MUST issue a
Proxy Diameter Security Association Answer (PDSA).

Regards

  // M.A.

---

From: Pat Calhoun <[email-masked]>
Date: Tue, 28 Aug 2001 06:35:28 -0700

> own DSA with the Home Server.

It isn't necessary. In the example I've provided, the client tries to
establish the DSA, and the proxy agent returns a failure. 

The client then requests that a DSA be established with the far end. 

The proxy agent establishes the DSA with the home server. If the proxy
agent wants to cache information from the first DSAR, then it could,
but this is purely an implementation issue. 

> the proxy to choose a DSA-TTL, provide Local-CA-Info or request OCSP

correct. I believe this is the more common case.

> according to its policy, not to previous DSA setup data.

correct.

> Proxy Diameter Security Association Answer (PDSA).

ok, but the above no longer allows the proxy agent from using previous
info from the DSAR, which it *could* use if it wanted to. There is no
reason to prohibit it, no?

PatC

---

From: Miguel Ángel Monjas Llorente <[email-masked]>
Date: Tue, 28 Aug 2001 16:00:49 +0200

> reason to prohibit it, no?

No, of course not :-))

  // M.A.

---

From: Pat Calhoun <[email-masked]>
Date: Tue, 28 Aug 2001 08:56:46 -0700

> > reason to prohibit it, no?

Then I am confused on what your position is. Could you rephrase the text
that you believe is correct?

confused :(

PatC

---

From: Miguel Ángel Monjas Llorente <[email-masked]>
Date: Tue, 28 Aug 2001 18:28:05 +0200

> that you believe is correct?

Sorry. I didn't wanted to confuse you :-))

I just wanted to clarify the proxy behaviour when acting as a CMS
proxy. I've got no preference about it using cached data or not. What
about the following?

  If the access device determines that it is able to allow the proxy
  agent to establish a DSA on its behalf, it would issue a Proxy
  Diameter Security Association Request (PDSR). This request MUST
  contain the realm with wich the access server wants the server to
  establish a DSA. The proxy agent MAY use any of the parameters
  provided by the access device in the previous DSA setup attempt to
  establish the DSA. Once established the DSA, the proxy agent MUST
  issue a Proxy Diameter Security Association Answer (PDSA).

Is it a little bit clearer?

  // M.A.

---

From: Pat Calhoun <[email-masked]>
Date: Tue, 28 Aug 2001 16:10:36 -0700

yes, sounds good. I will close this issue.

PatC

---

From: Miguel Ángel Monjas Llorente <[email-masked]>
Date: Wed, 29 Aug 2001 12:09:40 +0200

> > according to its policy, not to previous DSA setup data.

Maybe you might consider to add these paragaphs (or a enhanced version
of them) to the draft to make it clearer...

Regards

  // M.A.

---

From: Pat Calhoun <[email-masked]>
Date: Wed, 29 Aug 2001 05:03:17 -0700

> of them) to the draft to make it clearer...

Wait. I'd sent you the proposed text to close this issue yesterday, and
you gave me thumbs up. Are you now asking for more text?

Here's what I had sent in:

"  It is important to note that proxy agents establishing DSA's on
   behalf of a client will most likely need to reorder AVPs during the
   encryption process, in order to fit the encrypted AVPs within a
   CMS-Encrypted-Data AVP. This is contrary to the rule established in
   the Diameter base protocol [1], which states that proxy agents SHOULD
   NOT reorder AVPs."

and the next paragraph was already in the draft:

"  Allowing the first hop agent to be used to establish the DSA with
   the home server MAY reduce the current concerns that the cryptographic
   operations resulting from this specification MAY overburden embedded
   access devices."

So both of these paragraphs appear to state what I had above. Is this
sufficient?

PatC

---

From: Miguel Ángel Monjas Llorente <[email-masked]>
Date: Wed, 29 Aug 2001 14:45:39 +0200

> So both of these paragraphs appear to state what I had above. Is this

Of course it's sufficient. I've got an only purpose when proposing
this new text: to make the draft cleared (what doesn't imply that now
it's clear enough). IMHO some kind of information about the
"scenarios" in which CMS Security is used will be useful for CMS Sec
implementators. Just that. If you consider that doesn't add any
additional info or that this information isn't suitable in a
specification, no problem. I respect your opinion :-)))

Regards

  // M.A.

---

From: Pat Calhoun <[email-masked]>
Date: Thu, 30 Aug 2001 20:30:09 -0700

> specification, no problem. I respect your opinion :-)))

Since this is purely for clarification purposes, I will accept this issue.

I've added the following text to 4.3 to further explain when
this message is used. I was going to add it to 1.2, but it would require
some major surgery to the text, and I don't feel comfortable doing that
at this time (of course, if you can think of a great way to add this
text in the existing framework, and it would read well, then I'd welcome
some input).

Here's the proposed text:

The PDSR is used for the following reasons:
      - The access device does not have the cryptographic ability to handle the
        CMS functions locally, and therefore requests such services from the
        local agent, such an an aggregating relay or proxy agent. The NAS
        may have been configured to always issue a PDSR to its local agent
        for CMS services. In such cases, the agent MUST select is the values
        for the DSA-TTL and provide the appropriate Local-CA-Info and the
        expected OCSP response from the DSA peer.

      - The access device has the cryptographic ability to perform the CMS functions,
        but a proxy agent is in the route towards the home server, and it 
        returned a failure to the DSAR messages stating that it was not willing
        to allow the DSA to traverse through it. Such agents MAY attempt to
        re-use the values from the initial DSAR sent by the access device.

Comments appreciated.

PatC

---

From: Miguel Ángel Monjas Llorente <[email-masked]>
Date: Fri, 31 Aug 2001 09:53:30 +0200

> Since this is purely for clarification purposes, I will accept this issue.

Yes. After reading for first time the draft, I had the feeling that a
previous DSA setup attempt was necessary to issue a PDSR. Just for the
second I noticed that there was other possibilities....

> text in the existing framework, and it would read well, then I'd welcome

If you don't feel comfortable with this surgery task, you will be able
how I feel :-))

>         for CMS services. In such cases, the agent MUST select is the values
only this........................................................^^

>         re-use the values from the initial DSAR sent by the access device.

It's OK for me.

Regards

  // M.A.