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

From: "Ben Campbell" <[email-masked]>
Date: Wed, 01 Jun 2016 08:23:14 -0700

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.]

- 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.

- 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.

- 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.

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

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

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

- 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.

Editorial and Nits:

- 1, first paragraph: "mechanisms independent of Diameter (e.g., IPsec)
   is used."

s/is/are

- 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.

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 01 Jun 2016 11:45:16 -0400

By the way, <[email-masked]> bounces. Is there an updated address?

Ben.

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 1 Jun 2016 10:12:02 -0700

Kervin is not with Oracle anymore. I haven't managed to reach him yet.

- Jouni

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 1 Jun 2016 11:14:34 -0700

Ben,

Thanks for the review. See my comments inline.

> https://datatracker.ietf.org/doc/draft-ietf-dime-e2e-sec-req/

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.

> 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.

> requirements, they should be presented as such.

Ack. Should clean those away.

> 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.

> 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.

> existing applications. Is this intended to motivate the models with

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.

> elaborated as a requirement.

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

> - 1, first paragraph: "mechanisms independent of Diameter (e.g., IPsec)

Ack.

> 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

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 1 Jun 2016 19:32:39 +0100

Thanks all for the discussion. I've one thing to add... as you
may detect, it's a thing about which I'm not neutral:-)

> which says "..integrity, and data-origin authentication."

I'll put a DISCUSS on this if anyone adds non-repudiation as
a requirement! :-)

Non-repudiation is not a network service, even though it has been
described as one for decades. (Blame the security addendum to the
OSI reference model - afaik, that's where it started;-)

If one wants to provide what was claimed to be provided by
non-repudiation then one needs signed timestamps for pretty much
everything (and with counter signing for algorithm changes) and
distributed logs with signed events (and log integrity) for things
that happen at all nodes, and much else. None of that is useful for
Diameter and it therefore ought not be mentioned. Even were it
claimed to be useful, one would need to define a whole bunch of
new AVPs to try (but fail) to provide that fictional service.

Jouni is IMO correct that data origin authentication and data
integrity are the network security services that are relevant
and that can be offered here.

All that said, this is likely just a terminology thing, since
some people do still use the NR term when they mean integrity
and DAO with signatures, but it is *really* not a good idea to
add the NR term to the mix as it has distracted and misdirected
folks for literally decades and going back to that would be a
bad plan.

Cheers,
S.

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 01 Jun 2016 14:37:46 -0400

I may not have been clear, but my concern was not that I though there 
should be a non-repudiation requirement. It was that the text seemed to 
have an implicit one, and if that was intended, it should be explicit.

I'm also perfectly happy for the draft to not have such a requirement 
(implicit or otherwise.)

Ben.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 1 Jun 2016 19:40:38 +0100

> I'm also perfectly happy for the draft to not have such a requirement

I'd also prefer to see no mention of N-R. And I'm surprised I missed
the use of the term in my AD review - I usually whine when I see that;-)

S

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 01 Jun 2016 14:44:11 -0400

On 1 Jun 2016, at 14:37, Ben Campbell wrote:

> should be a non-repudiation requirement. It was that the text seemed 
> to have an implicit one, and if that was intended, it should be 
> explicit.

(To further clarify after re-reading my notes...)

I inferred the "implied" requirement from the fact that non-repudiation 
was used as the motivating example for the asymmetric algorithm 
requirement. That made the little voice in my head ask "Wait, is 
non-repudiation a requirement?"

Ben.

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 1 Jun 2016 16:18:20 -0700

Hi Stephen,

> I'll put a DISCUSS on this if anyone adds non-repudiation as

Bummer ;-)

> and that can be offered here.

Phew..

> folks for literally decades and going back to that would be a

Okay, I'll clean non-repudiation away, since origin authentication and 
integrity protection is really meant here.

- Jouni