Subject: [AAA-WG]: [issue] Expiration of DSAs on behalf of a client

From: Miguel Ángel Monjas Llorente <[email-masked]>
Date: Thu, 06 Sep 2001 14:37:15 +0200

Submitter name: Miguel A. Monjas
Submitter email address: [email-masked] 
Date first submitted: 2001-09-06
Reference:
http://www.merit.edu/mail.archives/aaa-wg/2001-08/msg00246.html
Document: CMS-02
Comment type: T
Priority: S
Section: 1.2, 4.4, 6.14
Rationale/Explanation of issue:

When a CMS proxy establishes a DSA on behalf of a client, it uses its
own parameters (or maybe some of the provided by the client in a
previous DSA attempt). Once established, it issues a PDSAA to inform
the client about the status of the DSA. But, what happens once the DSA
has expired? It may receive a message of the same client with AVPs
that it (the proxy) would have protected while the DSA existed.

Does it have to try to establish a new DSA (transparently for the
client)? Or has to warn the client issuing a Diameter message with an
appropriate Result-Code (so that the client issues a PDSAR again)?

My idea is that the proxy should include the TTL of its established
DSA in the PDSAA in order to inform the client when it has to reissue
a PDSAR to make the proxy establish a new DSA.

Requested change: 

Add the following text to the proposed text for issue 136:

  The PDSAA MUST contain the TTL setting agreed by the proxy agent
  for its DSA. This information will allow the access device to
  re-issue a PDSAR when the proxy's DSA has expired.

Change the ABNF grammar of the PDSAA AVP (4.4), being the result:

      <PDSA> ::= < Diameter-Header: 305, PXY >
                 { Result-Code }
                 { Origin-Host }
                 { Origin-Realm }
                 { Auth-Application-Id }
                 { DSA-TTL }
                 [ Origin-State-Id ]
               * [ AVP ]
               * [ Proxy-Info ]
               * [ Route-Record ]

Add the followig text to the description of a DSA-TTL AVP in 6.14:

  A DSA-TTL AVP MUST also be included in the PDSAA in order to
  provide information about the lenght of the DSA established by
  the proxy on behalf of the access device.

Regards

  // 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
  Retama 1, 4th. 28045 Madrid - SPAIN -

---

From: Miguel Ángel Monjas Llorente <[email-masked]>
Date: Fri, 07 Sep 2001 16:28:10 +0200

>   re-issue a PDSAR when the proxy's DSA has expired.

Well, the PDSAR may be used also (without DSA-Target-Realm) to inform
the proxy that it must establish DSAs with all the realms it will be
communicating with, so that maybe a MAY instead a MUST would be
better.

>       <PDSA> ::= < Diameter-Header: 305, PXY >

                   [ DSA-TTL ]

>   the proxy on behalf of the access device.

Same comment

Regards

  // M.A.

---

From: "Jari Arkko" <[email-masked]>
Date: Fri, 7 Sep 2001 21:16:03 +0300

>a) When issuing a DSA-Request, a digital signature (by means of a
>CMS-Signed-Data AVP) may be included. If so, an appropriate CMS-Cert
>must be included (unless the certificate is included within the
>SignedData estructure).

Section 5.0 states that the CMS-Cert may be present in DSAR
and DSAA. For the return message, it's the home server's cert.
But as far as I can see, the CMS-Cert MUST be present and can't
be avoided. (Unless we want to optimize the case where we already
have the cert? No, I think it is too messy)

So, the correct new line is:

   CMS-Cert                      | 1   | 1   | 0   | 0   |

>b) Clarify if a CMS-Cert is necessary in a DSAA or if it's superseded
>by a certificate present in AAA-Server-Cert

I can't find AAA-Server-Cert from the cms-sec-02 version.

>BTW, shouldn't be present Key-Hash AVP in the AVP occurrence table?

No, because it's a subpart of Local-CA-Info AVP which you can find
from the table already.

In conclusion I think we should change the AVP occurrence line
for CMS-Cert, but nothing else.

Jari

---

From: Miguel Ángel Monjas Llorente <[email-masked]>
Date: Mon, 10 Sep 2001 09:27:36 +0200

> have the cert? No, I think it is too messy)

I've seen it, but being only an example, I'd rather want to know the
right answer.

>    CMS-Cert                      | 1   | 1   | 0   | 0   |

Assuming that a CMS-Cert MUST always go with a digital signature, it's
OK.

> I can't find AAA-Server-Cert from the cms-sec-02 version.

Sorry by the typo. It's AAA-Server-Certs and it's described in section
6.6. As far as I understand, the destination node of the DSA is one of
the AAA servers of the domain, so that the digital signature included
in the DSAA can be verified by means of one of such certificates.
Can't it?

> No, because it's a subpart of Local-CA-Info AVP which you can find

Yes. I thought the same. But I also noticed that the other subpart of
Local-CA-Info AVP (CA-Name AVP) is actually listed. As far as I
understand both o none of them must be listed.

> for CMS-Cert, but nothing else.

You're assuming that:

- No optimization would be employed (what looks right).
- The digital certificate of the destination DSA participant isn't
included in AAA-Server-Certs (what I'd like to be confirmed).

Comments?

  // M.A.

  Ombú 3, 10th. 28045 Madrid - SPAIN -

---

From: Jari Arkko <[email-masked]>
Date: Mon, 10 Sep 2001 16:29:59 +0300

> understand both o none of them must be listed.

Right. Take both away then.

> included in AAA-Server-Certs (what I'd like to be confirmed).

I have actually managed to get now confused on the AAA-Server-Certs
and CMS-Cert. Which one is what, and why doesn't AAA-Server-Certs
specify the format of the contents, like CMS-Cert does?

Jari

---

From: Miguel Ángel Monjas Llorente <[email-masked]>
Date: Mon, 10 Sep 2001 15:52:46 +0200

> Right. Take both away then.

It is the more coherent option...

> specify the format of the contents, like CMS-Cert does?

Good question. Maybe Pat or Stephen could answer this question... (the
only mention of this AVP was in the discussion about the obligation of
including a digital signature in the DSA-Answer; this AVP MUST have
its 'P' bit set)

Regards

  // M.A.

---

From: Miguel Ángel Monjas Llorente <[email-masked]>
Date: Fri, 14 Sep 2001 12:41:31 +0200

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.

Regards

  // M.A.