Subject: [AAA-WG]: [issue] DSA error codes

From: Miguel Ángel Monjas Llorente <[email-masked]>
Date: Mon, 03 Sep 2001 11:05:37 +0200

Submitter name: Miguel A. Monjas
Submitter email address: [email-masked] 
Date first submitted: 2001-09-03
Reference: http://www.merit.edu/mail.archives/aaa-wg/msg02002.html
Document: Base-07, CMS-02
Comment type: T
Priority: 1
Section: 
Rationale/Explanation of issue: 

Apart from the error codes related to OCSP there are only two other
errors: DIAMETER_KEY_UNKNOWN and DIAMETER_INVALID_CMS_DATA.

The former is related to the locally stored encryption key (symmetric)
while the later talks about CMS-*-Data AVPs.

The Base Protocol draft (7.1.3) states:

      DIAMETER_INVALID_CMS_DATA          3006
         The Request did not contain a valid CMS-Data [11] AVP.

While in the CMS Security draft (7.2) it is said that:

      DIAMETER_INVALID_CMS_DATA          5019
         This error code is returned when a CMS-Data AVP is received
         with an invalid ContentInfo object.

As stated in the reference mail, my first concern is about the
definition (which is slightly different) and the type of error (in the
base draft it's a protocol error while in the CMS draft it's a
permanent failure).

My second concern is about the error situations related to CMS. I can
foresee the following:

- In a DSA setup dialogue, the initiator can provide a set of "direct
trust" CA which isn't supported by the receiver. I understand that a
permanent failure code error must be issued.

- In a DSA setup dialogue, the initiator, once received the DSAA,
might fail to verify the conditions listed in section 3.1 of the CMS
draft. Like no ACK is foreseen in the specification, I understant that
when in a subsequent Diameter message, the initiator receives an AVP
related to CMS, this node should issue a permanent error. For example,
DIAMETER_NO_DSA_ESTABLISHED

- If a Diameter node receives a message with encrypted or signed AVPs
once the DSA has expired (or even with no previous DSA established),
the node should issue another error. Maybe, DIAMETER_DSA_EXPIRED (or
maybe making use of the former code suggested).

Requested change: 

I suggest unifying the definition of DIAMETER_INVALID_CMS_DATA in both
drafts (or maybe dropping the mention of the error in base draft).

For the rest of concerns, I'd add some clarifying text in order to
state wheter those are really error situations or not.

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: Mon, 03 Sep 2001 15:26:42 +0200

Submitter name: Miguel A. Monjas
Submitter email address: [email-masked]
Date first submitted: 2001-09-03
Reference: http://www.merit.edu/mail.archives/aaa-wg/msg02002.html,
http://www.merit.edu/mail.archives/aaa-wg/msg02022.html
Document: Base-07, CMS-02
Comment type: T
Priority: 1
Section: Base (7.1.3), CMS (6.2)
Rationale/Explanation of issue:

Apart from what I wrote in
http://www.merit.edu/mail.archives/aaa-wg/msg02022.html, I'd like to
add the following:

 DIAMETER_CMS_SECURITY              3008
   A proxy has detected that CMS security has been applied to
   portions of the Diameter message, and the proxy does not allow
   this security mode since it needs to alter the message by
   applying some local policies.

I suppose that this error code has been superseded by the error codes
defined in CMS-02 1.2 (Establishing Security Relationships through
proxy agents).

Also, the CMS-02 draft (section 6.1) says that:

   If the signature cannot be verified correctly, a response with the
   Result-Code AVP set to DIAMETER_INVALID_AUTH [1] MUST be returned.

I haven't found such a error code in Base-07

Requested change:

a) Drop error 3008 from base draft.
b) Correct which error code is issued when the signature isn't
properly verified.

Regards

  // M.A.

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

---

From: Pat Calhoun <[email-masked]>
Date: Mon, 3 Sep 2001 10:42:46 -0700

> drafts (or maybe dropping the mention of the error in base draft).

Done, the one in the base protocol draft has been removed.

> state wheter those are really error situations or not.

The following result codes have been added:

      DIAMETER_NO_COMMON_TRUST           5020
         This error code is returned when a receiver receives a PDSR for which
         it has no common trust with the sender, which is required to establish 
         the DSA.

      DIAMETER_NO_DSA_ESTABLISHED        5021
         A Diameter message refers to a Diameter Security Association which
         does not exist.

      DIAMETER_DSA_EXPIRED               5022
         A Diameter message refers to a Diameter Security Association which
         has expired.

Thanks,

PatC

---

From: Pat Calhoun <[email-masked]>
Date: Mon, 3 Sep 2001 10:47:29 -0700

> a) Drop error 3008 from base draft.
done

> b) Correct which error code is issued when the signature isn't

      DIAMETER_INVALID_AUTH             4012
         The signature in the CMS-Signed-Data AVP is invalid.

Thanks,

PatC

---

From: Miguel Ángel Monjas Llorente <[email-masked]>
Date: Tue, 04 Sep 2001 11:10:45 +0200

>          A Diameter message refers to a Diameter Security Association which

May I suppose that appropriate references to this result codes have
been added to the draft (let's say to chapter 3.1)?

For example, before the sentence "The destination node returns the
...", I would add a paragraph similar to the following:

Once received a DSA-Request, the destination node MUST verify that:

- The digital signature included in the CMS-Signed-Data AVP can
  be verified (i.e. proper digital certificates are available to
  verify the digital signature).
- One of the Local-CA-info AVP values from the DSA-Request message
  can act as the top CA of a certificate chain down to the CA
  which has issued all the end entity certificates of the AAA
  servers in the Home Domain.

Otherwise a DSA-Answer with a Result-Code
DIAMETER_NO_DSA_ESTABLISHED must be issued.

[Maybe something here about OCSP, but really after so many changes I'd
need an up to date draft to sugest coherent changes]

Again, after the list of conditions written down in page 11, I'd add
somthing like the following:

If the initiator fail to verify all the conditions, the DSA MUST
NOT be considered as established. As no explicit acknowlegment
is considered by the protocol, when in a subsequent Diameter
message, the initiator receives an AVP related to this failed DSA
it should issue a Diameter message with a Result-Code
DIAMETER_NO_DSA_ESTABLISHED

Comments?

  // M.A.

---

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

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

In chapter 6.2 it's written down that:

   When a conforming implementation receives a Diameter message which
   contains encrypted AVPs within a CMS EnvelopedData, the recipient
   MUST check to see if it is on the list of recipients specified in
the
   RecipientInfos of the EnvelopedData. If not, the recipient MAY
choose
   to process the message or indicate an error. If the recipient is in
   the RecipientInfos and an error occurs during decryption, then the
   recipient MUST indicate an error.

Two error situations are pointed:

- When the DSA recipient isn't in the list of recipients of
EnvelopedData.
- Being in the recipient list, an error occurs during decryption.

However, no Result-Code is provided in such situations.

Requested change:

a) create appropriate result codes (maybe DIAMETER_NO_DSA_RECIPIENT
and DIAMETER_DSA_DECRYPTION_FAILED)
b) clarify the previous paragraph including references to appropriate
result codes

Regards

  // M.A.

---

From: Miguel Ángel Monjas Llorente <[email-masked]>
Date: Tue, 04 Sep 2001 11:40:38 +0200

Something missed:

>   servers in the Home Domain.

 - It may agree on a TTL less or equal to the provided in the DSAA
   (via the DSA-TTL AVP or the earliest expiration of all
   certificates included in the message)

Regards

  // M.A.

---

From: Miguel Ángel Monjas Llorente <[email-masked]>
Date: Tue, 04 Sep 2001 12:44:24 +0200

Something missed again:

> DIAMETER_NO_DSA_ESTABLISHED

What implies that the sentence previous to the list of items should be
dropped. At the moment, it's said:

   The originating Diameter node now has to check the response. Any
   failure results in error messages and auditing and not sending the
   Diameter message.

   Checks:
       - the certificate chain selected is cryptographically ...

A more proper solution might be:

   The originating Diameter node now has to check the DSA-Answer:
       - the certificate chain provided is cryptographically ...

And the previously issued paragraph after the list of checks.

Regards

  // M.A.