Subject: [AAA-WG]: [issue] CMS Usage Scenario precisions

From: Miguel Ángel Monjas Llorente <[email-masked]>
Date: Wed, 05 Sep 2001 18:14:57 +0200

Submitter name: Miguel A. Monjas
Submitter email address: [email-masked] 
Date first submitted: 2001-09-05
Reference: 
Document: CMS-02
Comment type: T
Priority: 2
Section: 3.1
Rationale/Explanation of issue:

a) In the list of elements that comprise a DSAA quoted in 3.1, it's
listed the following:

  - a chain of CA certificates (possibly empty)

Why this element (that I assume it's the CA-Chain AVP) is, possibly,
empty? I understand that most of the times, the CA that has issued the
certificates of the Home Realm are the same than the provided in the
Local-CA-Info AVP, but saying that "possibly" it's empty is maybe too
hard.

b) On the other hand, in the list of elements that comprise a DSAR
quoted in 3.1, it's listed the following:

  - the realm part of the user's NAI

Is that really true? I mean, I understant this meaning when an
authorisation or authentication operation is involved. But let's take
an accounting operation. Which is the user's NAI?

c) In the checks listing (according to conclusion in issue 126) the
proposed text stated that:

  - the name in the certificate is consistent with the rules detailed
    in section 3.2.

My concern is the following. Which certificates are we talking about?
The included in the CMS-Cert AVP? The ones from AAA-Server-Certs?
Both? BTW, I suppose that the certificate of the DSA receiver (the
node issuing the DSAA) in included within the AAA-Server-Certs, so
that no CMS-Cert would be necessary?

d) The last paragraph of 3.1 talks (again, so that some paragraphs has
been included at the beginning of the section) about certificate
revocation checks:

   If certificate revocation is enabled, anytime a certificate is used
   from the local certificate cache, a revocation check MUST be
   performed.

This paragraph contradicts Stephen's precissions about certificate
revocation checks which approximately say that no revocation check is
necessary until the "safe" period has ended.

Requested change: 

a) Replace "(posibly empty)" with "(frequently empty since the CA that
has issued the certificates for the Diameter servers in the realm are
usually included within the CAs contained in the DSAR message).

b) Clarify this item.

c) Clarify this item (maybe with something like "the name in all the
certificates included is consistent with the rules detailed in section
3.2.")

d) Drop the quoted paragraph

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: Jari Arkko <[email-masked]>
Date: Thu, 06 Sep 2001 17:32:36 +0300

Error replies to requests with no session id

Submitter name: Jari Arkko 
Submitter email address: [email-masked] 
Date first submitted: September 6, 2001
Reference: - 
Document:base 
Comment type: T 
Priority: 1 
Section: 7.2 
Rationale/Explanation of issue: 

  Diameter has a couple of messages such as Device-Watchdog-
  Request that do not include a session id in the request.
  Yet section 7.2 requires that error replies to request
  have the session id. How can we make an error reply
  to Device-Watchdog-Request, for instance? And section
  6.2 then talks about answers, and says that Session-Id
  must be copied where it exists. Perhaps this is the
  right approach, but should the BNF in 7.2 be changed
  then?

  Other messages without Session-Id are Capabilities-
  Exchange-Req and Disconnect-Peer-Request.

Requested change: 

  Perhaps the BNF in 7.2 should be changed, or at
  least words added. I'm not sure how to change the
  BNF, given that we can't indicate a fixed position
  AVP that is optional...

  If added words is enough, then put in at the end
  of 7.2: "Note also that the Session-Id should be
  present if and only if the corresponding request
  contained it."