Subject: [AAA-WG]: RE: [issue] CMS editorial stuff

From: <[email-masked]>
Date: Thu, 28 Mar 2002 10:40:48 +0200

Hi Jari,

I've added the text to 4.6 (as suggested) to the base.  316 can be now marked
closed for the base.

John

> -----Original Message-----
> From: ext Jari Arkko [mailto:[email-masked]]
> Sent: 28 March, 2002 01:44
> To: [email-masked]; Stephen Farrell; Loughney John (NRC/Helsinki)
> Subject: [issue] CMS editorial stuff
> 
> 
> 
> Hi,
> 
> On my way to the IETF I I decided to try and read the CMS 
> document well
> once more. I have only now found the time to send this e-mail 
> about some
> suggestions I have. Feel free to use these suggestions or discard them
> if you don't agree... note that there's also a related 
> clarification to
> base. And I'm proposing some modifications to the AVP occurrence rules
> in CMS so some of this borders on a technical issue.
> 
> Jari
> ----
> Issue:                    CMS editorial issues
> Submitter name:           Jari Arkko
> Submitter email address:  [email-masked]
> Date first submitted:     03-27-2002
> Reference:
> Document:                 cms-09, base-09
> Comment type:             Editorial
> Priority:                 S
> Section:                  CMS: Abs, ToC, 1, 2, 3, 4, 5, Base: 4.6
> Rationale:
> 
> 1) In the abstract "... perform message routing, and other
> than routing AVPs, do not modify Diameter messages." =>
> "... perform message routing and do not modify Diameter
> messages beyond routing AVPs."
> 
> 2) ToC and the document structure. I would suggest
> the following modifications:
> - Since terms generally need to introduced before they are
>    used, 1.1 needs to move to its own chapter before chapter 1.
> - I would add a Terms section. See attached file for initial
>    text.
> - I would name 2.0 "AVP Protection' and place current 2.0 under
>    it as '2.1. Format' and 1.7 under it as 2.3. Then I would
>    add some clarifying text on exactly what the CMS spec expects
>    nodes to do with AVPs (I couldn't find such text before this
>    point). See attached second file for initial text.
> - I would name 5.0 "Example Message Flow"
> 
> 3) Chapter 1. Doesn't really describe what the functionality
> provided here is, just talks about how it is provided. Suggested
> text to add before the third paragraph: "This specification
> provides an additional security mechanism to protect transport of
> Diameter AVPs through rogue Diameter agents."
> 
> 4) Chapter 1. "Redirector agent" => "redirect agent" (the term
> used in base).
> 
> 5) Chapter 1.2 last paragraph only talks about signing. Why? I
> suggest that we should talk about both signing and encryption.
> Here's some proposed text to add at the end: "Similarly, participants
> MAY apply encryption to protect one or more AVPs within a message."
> 
> 6) Chapter 4.6 in base. This is related to the above issue. We
> have now clarified very well what MAY ENCR means, but we haven't
> done the same for 'MAY Set P Bit'. Essentially, isn't this the same
> thing? Propose to add text after first paragraph of 4.6: "Similarly,
> for the originator of a DIameter message, a "P" in the "MAY" column
> means that if a message containing that AVP is to be sent
> via a proxy/agent then the message MUST NOT be sent unless there
> is a DSA between the originator and the recipient or the originator
> has locally trusted configuration that indicates  that
> CMS need not be used."
> 
> 7) Chapter 1.3 "reuse the values" -- what values? I think this
> is still referring to the old Encrypted-AVPs AVP, or something like
> that. Propose to delete the sentence.
> 
> 8) 1.3, "does not request a DSAR to request a DSA" => "does 
> not request
> a DSA through sending a DSAR message"
> 
> 9) 1.3, "the access device can then determine whether it is willing to
> provide service, based on its local policy". I would simply 
> say "The access
> device can then determine whether to trust this notification, based
> on local configuration i.e. the keys of trusted agents. If 
> the access device
> can not trust this notification, it MUST refuse the service 
> in question."
> 
> 10) 3.1, "... which AVPs should be encrypted, signed or 
> both..." -- remove
> this text, but keep the part about the public keys.
> 
> 11) 3.1. DSA[RA] message contents, doesn't clearly show which AVPs are
> used for which purpose, which makes the spec harder to read. Also,
> misses some of the AVPs. Proposed text in the third attachment.
> 
> 12) 4.2 Local-CA-Info appears to be unnecessary. Remove from this
> message.
> 
> 13) 3.2 "capable of acting as recipients for confidentiality" =>
> "that support DSAs".
> 
> 14) 3.3. AES. Replace the current text with "It is strongly 
> recommended
> that the AES algorithm is supported where it is available."
> 
> 15) 4.1 delete the statement about the cert distribution 
> protocol, I don't
> think we need to state that.
> 
> 16) 5.0 delete the text about the bidir signatures and encryption.
> 
> 17) 5.0 step h,add to the end "Those AVPs that need to be 
> kept confidential
> are placed in CMS-Encrypted-AVP in encrypted form. Modify 
> picture accordingly.
> 
> 18) 5.0 step i. Add before the encryption part "The message 
> includes the
> CMS-Signed-AVP, which authenticates the AVPs that need it".
> 
> 19) 5.0 step h. "that were requested by the Home Server in 
> the DSAA." =>
> "that need it".
> 
> 20) section 4.I think CA-Chain should be a "*" instead of "0*1". THere
> may be zero chains, if the roots and the certs don't mix or 
> if the peer
> should already know the chain. But there can be multiple 
> chains if several
> roots are used.
> 
> 
>