Subject: [AAA-WG]: [issue] Erroneous protection expectations

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

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

A Diameter node can request protection on certain AVPs that are not
allowed (i.e. requested as signed an AVP which can't set its 'P' bit
or as encrypted an AVP which can't be encrypted). No check nor error
code has been defined.

Requested change: 

Add the following paragraph to 3.1 (after the list of components of
the DSAR):

   The destination node MUST check that the provided elements of
   the DSAR are valid. It MUST check, at least, that:

      - Its local policy allows it to provide a TTL compatible with 
        the value provided in the request.
      - One of the CAs provided is suitable of being the top of a
        CA certificate chain that will assure the certificates of
        the servers in the Home Domain.

   If these conditions can not be verified, the destination node MUST
   return a DSAA with the Result-Code AVP set to 
   DIAMETER_NO_DSA_ESTABLISHED.

   The destination node MUST also verify that the protection
   expectations are valid. If it is requested as signed an AVP
   which may not set its 'P' bit or as encrypted an AVP which may
   not be encrypted, the destination node MUST return a DSAA with the
   Result-Code AVP set to DIAMETER_ERRONEOUS_PROTECTION_EXPECTATIONS.

   In the event....

Add the following paragraph to 6.9:

   If the AVP code specified in the Expected-Signed-AVP is not
   valid (that it, that AVP is not allowed to set its 'P' bit), the
   implementation MUST issue an error message containing the
   DIAMETER_ERRONEOUS_PROTECTION_EXPECTATIONS result code

Add the following paragraph to 6.10:

   If the AVP code specified in the Expected-Encrypted-AVP is not
   valid (that it, that AVP is not allowed to be encrypted), the
   implementation MUST issue an error message containing the
   DIAMETER_ERRONEOUS_PROTECTION_EXPECTATIONS result code

Add the following error code to 7.2:

      DIAMETER_ERRONEOUS_PROTECTION_EXPECTATIONS         50xx
         The protection expectations stated in the Expected-Signed-AVP
         or Expected-Encrypted-AVP are invalid. A Diameter message
         indicating this error MUST include the offending AVPs within
         a Failed-AVP AVP.

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: Fri, 7 Sep 2001 20:41:43 +0300

I agree with the parts of this issue. However, I would
suggest that instead of creating a new error code we
could simply use DIAMETER_INVALID_AVP_VALUE.
Otherwise we end up creating a special error code for
all AVPs.

Also, I would suggest we don't list all the checks explicitly
because, essentially, the destination node must check
ALL sent parameters according to the policies. I've reformulated
the text slightly to be a bit more general in this respect.

Edited change request below.

Jari

>       - Its local policy allows the given TTL, realm, AVP protection
>         expectations, certification status, and other parameters. 
>       - A common "top" of the certificate chain can be found between
>         the home and foreign domains.
> 
>    Result-Code AVP set to DIAMETER_INVALID_AVP_VALUE.
> 
> 
>    In the event....
> 
>    DIAMETER_INVALID_AVP_VALUE result code
> 
>    DIAMETER_INVALID_AVP_VALUE result code

---

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

> Otherwise we end up creating a special error code for

You're right. Maybe I'd better point only error situations and not
result codes.

> Edited change request below.

I agree on Jari's re-replacements.

Regards

  // M.A.