Re: [Dime] Ben Campbell's No Objection on draft-ietf-dime-e2e-sec-req-04: (with COMMENT)

[Jouni Korhonen <[e-mail]>]

Ben,

Thanks for the review. See my comments inline.

6/1/2016, 8:23 AM, Ben Campbell kirjoitti:
> Ben Campbell has entered the following ballot position for
> draft-ietf-dime-e2e-sec-req-04: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-dime-e2e-sec-req/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Substantive:
>
> - I am concerned about the de-emphasis of privacy requirements. While
> there's a mention of confidentiality in Requirement 2, other text
> suggests that integrity is more important (implying privacy is less
> important). There are no privacy considerations. Finally, the  {AVP}k
> convention does not distinguish  hinders discussion about how the set of
> confidentiality-protected AVPs and integrity-protected AVPs might not be
> the same. [Note: I almost balloted DISCUSS over this point. I did not,
> because I don't want to force the working group to add requirements it
> doesn't believe in. But I'd like to see some discussion about this.]

First the convention {AVP}k.. it is used in the example figures that lay 
out the possible deployment models and scenarios. There the important 
thing is to illustrate where AVPs are protected.. somehow. I do not see 
any value going into details in those examples whether the AVPs (or some 
set of them) are confidentiality or integrity protected.

Second the privacy. I do not buy the de-amphasis argument. My belief and 
assumption so far has been that indiovidual user privacy needs to be 
addressed at a different level. You do not need confidentiality 
protection for that. That was, for example, how we did it in RADIUs 
(i.e., Chargeable-User-Identity). You system and used subscriber 
identities are already designed in a way that they provide privacy.

> - The "middle to *" models may be useful, but they are not end-to-end.
> Given the focus on those models, I find the title of the draft to border
> on disinformation. The description in the introduction about protecting
> AVPs between "non-neighbor" nodes is more accurate.

Right. I recall we had a discussion about this earlier. AFAIR we kind of 
agreed that we cannot really say where the e2e ends and what are the 
real endpoints. So it was "e2e" between two Diameter nodes given any 
topology between the two.

> - I find it odd to find 2119 keywords in the "motivation" sections. I
> suspect that most of those are statements of fact. If some are really
> requirements, they should be presented as such.

Ack. Should clean those away.


> - 4: The listed advantages of the middle-middle model (and also
> middle-to-end and end-to-middle) seem to assume that the number of
> "middles" is smaller than the number of "ends". While this may be true,
> especially for clienty ends, it should probably be explicitly stated.

Hmm.. okay.

> -- "firewalling Diameter proxy" needs a definition or reference.

Ack. We'll add a definition. Proposing the text below into Terminology 
Section:

    Diameter Firewall: a Diameter firewall is a proxy (or a relay) agent
      that acts similarly to conventional IP traffic firewalls but only
      at the Diameter AVP and command level. A Diameter firewall may,
      for example, discard security policy offending AVPs from
      traversing through it. The Diameter firewall may even discard
      entire Diameter messages based on the security policy.

> - Requirement 1: Does this need discussion on deprecating algorithms when
> vulnerabilities become known?

I don't think so. Deprecating an algorithm in my view in this case is 
more of an administrative decision to turn of certain deprecated 
algorithms in a given deployment.

>
> - Requirement 2: Please elaborate on backwards-compatibiltiy with
> existing applications. Is this intended to motivate the models with
> "middles"?

Motivating "middles" is one thing. The other thing is that it is 
valuable if the integrity protection can be turned on without requiring 
to update intermediate nodes between "e2e endpoints".

The requirement probably say here that the "backward-compatibilty" 
implies travesing non-updated proxy & relay agents.

> - Requirement 7: This (along with some text in the introduction) implies
> that non-repudiation is a requirement. If so, that should be listed and
> elaborated as a requirement.

I believe tnon-repudiation is already covered by the requirement #2, 
which says "..integrity, and data-origin authentication."

>
> Editorial and Nits:
>
>
> - 1, first paragraph: "mechanisms independent of Diameter (e.g., IPsec)
>    is used."
>
> s/is/are

Ack.

>
> - Requirement 3: The last sentence seems to ask the reader to draw a
> conclusion that wall-clock time can be used for anti-replay protection.
> If that's the intent, please say so explicitly.

Ack. Different nodes should have the same view of time, however, I am 
not sure whether that is a requirement for anti-replay.. it can also 
implemented using counters and such. I would simplify the whole 
requirement as:

    Requirement #3:  The solution MUST support replay protection.

Then we do not make any assumption what is the used mechanism.. counter, 
sequence number, token, time, or whatever.

- Jouni

>
>