Re: [i2rs] Stephen Farrell's Discuss on draft-ietf-i2rs-protocol-security-requirements-14: (with DISCUSS and COMMENT)

Stephen Farrell <stephen.farrell@cs.tcd.ie> Thu, 29 September 2016 13:19 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: i2rs@ietfa.amsl.com
Delivered-To: i2rs@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99F5912B0F2; Thu, 29 Sep 2016 06:19:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.617
X-Spam-Level:
X-Spam-Status: No, score=-6.617 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vSuJfFrI439U; Thu, 29 Sep 2016 06:19:11 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79D7112B0FE; Thu, 29 Sep 2016 06:19:10 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 4A640BE4D; Thu, 29 Sep 2016 14:19:08 +0100 (IST)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bm7LcCr8YMVm; Thu, 29 Sep 2016 14:19:08 +0100 (IST)
Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8DF3FBE3E; Thu, 29 Sep 2016 14:19:07 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1475155148; bh=/JqOyZaSAYjus/99kaazAxWUoHD83EOUwjxD5rkpJ0c=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=LXLPRkHNuWKs5CqBnBJqBDcvupZUZLDd+MEUqA1umw3iI4pJsnILkGuMUnELWmSAR BvkgsCc9+FDhVP7DXtul8/SdJ6UUS6k8hlzOcWhwYuRV5PDXS/JuO7JyE+qC0EUnUM i9Gu7BpvpA+MnDuu/4ccdImApjcUE+Vb8hoj7KCk=
To: Susan Hares <shares@ndzh.com>, 'The IESG' <iesg@ietf.org>
References: <147509830903.16624.17764292480373284772.idtracker@ietfa.amsl.com> <002f01d21a52$80ccc6b0$82665410$@ndzh.com>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <1ccf2282-d35f-0da6-87fe-2b8e6ac8b0d3@cs.tcd.ie>
Date: Thu, 29 Sep 2016 14:19:08 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <002f01d21a52$80ccc6b0$82665410$@ndzh.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030408050107000909000202"
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/dCCFoZBje14kqwaCrr4iYSqPj5U>
Cc: jhaas@pfrc.org, i2rs@ietf.org, i2rs-chairs@ietf.org, draft-ietf-i2rs-protocol-security-requirements@ietf.org
Subject: Re: [i2rs] Stephen Farrell's Discuss on draft-ietf-i2rs-protocol-security-requirements-14: (with DISCUSS and COMMENT)
X-BeenThere: i2rs@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" <i2rs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2rs>, <mailto:i2rs-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i2rs/>
List-Post: <mailto:i2rs@ietf.org>
List-Help: <mailto:i2rs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2rs>, <mailto:i2rs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Sep 2016 13:19:15 -0000

Hi Sue,

On 29/09/16 14:07, Susan Hares wrote:
> Stephen:
> 
> This messages is to respond to your comments.   I've submitted a
> version 16 to deal with comments I could resolve.   I'm glad to work
> further with you on these comments - if you wish.
> 
> Sue
> 
> -----Original Message----- From: Stephen Farrell
> [mailto:stephen.farrell@cs.tcd.ie] Sent: Wednesday, September 28,
> 2016 5:32 PM To: The IESG Cc:
> draft-ietf-i2rs-protocol-security-requirements@ietf.org; Jeffrey
> Haas; i2rs-chairs@ietf.org; jhaas@pfrc.org; i2rs@ietf.org Subject:
> Stephen Farrell's Discuss on
> draft-ietf-i2rs-protocol-security-requirements-14: (with DISCUSS and
> COMMENT)
> 
> Stephen Farrell has entered the following ballot position for 
> draft-ietf-i2rs-protocol-security-requirements-14: Discuss
> 
> 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-i2rs-protocol-security-requirements/
>
> 
> 
> 
> ----------------------------------------------------------------------
>
> 
DISCUSS:
> ----------------------------------------------------------------------
>
> 
> 
> Thanks for the major revision, this is a lot better.  I have one
> discuss point and a bunch of comments.
> 
> The discuss is: I think it's an error to mix the secure and insecure
> transports in one set of protocol requirements. And I would
> definitely put a DISCUSS on any protocol solution that aims to weaken
> the security of e.g. port 443 or equivalent. In other words, I think
> you need to rule out any protocol solutions that weaken the secure
> transports that you are re-using. I therefore suggest adding a new
> requirement along these lines:
> 
> "SEC-REQ-NN: While I2RS might need to make use of both secure and
> insecure transports, this MUST NOT be done in any way that weakens
> the secure transport protocol, either as used in I2RS, or especially
> not as used in other contexts that do not have this requirement for
> mixing secure and insecure modes of operation and that depend on
> security being as good as we can provide."
> 
> So I'd like to discuss adding the above or similar.
> 
> 
> ----------------------------------------------------------------------
>
> 
COMMENT:
> ----------------------------------------------------------------------
>
> 
> 
> 
> - The topic of marking things as allowing insecure read access has
> been discussed a lot so I won't get into it again.
> 
>> - section 4: "Data passed over the insecure transport channel MUST
>> NOT contain any data which identifies a person or any >"write"
>> transactions." I don't get what identifying a write transaction
>> might mean?
> 
> Three types of transactions exists for the I2RS work:  Read, write,
> notify.   The data passed over insecure cannot identify any item that
> can be written so someone could use this to Act the device.  Do you
> have suggested wording? [no text added]

Sorry but I still don't get it. If <frobble/> is potentially
writable but is also sent in a notification in clear, then
that identifies that there's a <frobble/> element, and for
most such things that'll mean someone can write it. So I
remain confused at to what you want to require here.

> 
>> 4.1: "AAA protocols MAY be used to distribute these identifiers,
>> but other mechanism can be used." If I'm doing TLS with 
>> mutual-auth, then I need a private key and certificate. I don't
>> think AAA protocols can transport those (and they probably >ought
>> not) so I'm not sure what's meant here.
> 
> I believe your comment is on: "SEC-REQ-03: Identifier distribution
> and the loading of these identifiers into I2RS agent and I2RS client
> SHOULD occur outside the I2RS protocol prior to the I2RS protocol
> establishing a connection between I2RS client and I2RS agent. AAA
> protocols MAY be used to distribute these identifiers, but other
> mechanism can be used.  "
> 
> The identifiers are not identifiers at the TLS layer.  These are the
> application layer (management layer) identifiers.

You may want to clarify that. That said, if mutual-TLS is the
basis for authentication then there is a need to bind to the
identifier(s) in the client certs.

> 
> [no text added]
> 
>> 4.2: What do "valid identity" and "valid identifier" mean? If the
>> same then use the same terms. But I think you need to define
>> "validity" or else say that work needs to be done later.
> 
> Per RFC 4949
> 
> $ identity (I) The collective aspect of a set of attribute values
> (i.e., a set of characteristics) by which a system user or other
> system entity is recognizable or known. (See: authenticate,
> registration. Compare: identifier.)
> 
> $ identifier (I) A data object -- often, a printable, non-blank
> character string -- that definitively represents a specific identity
> of a system entity, distinguishing that identity from all others. 
> (Compare: identity.)
> 
> SEC-REQ-04 - seeks to determine that the I2RS client has a valid
> identity (set of attribute values) to work with this client. 
> SEC-REQ-05 - seeks to determine the I2RS Agent identifier send in the
> I2RS protocol is a valid identifier is valid.
> 
> The language is from RFC4949.  The asymmetry is intended in that the
> mechanisms for read, write, and notification utilized by
> NETCONF/RESTCONF over TLS use slightly different attributes to
> identify the I2RS Client.   The use of identity in SEC-REQ-04
> encompasses the multiple identifiers.
> 
> All of this is above the TLS layer. [no text added]

Sorry, no - I asked what "valid" means here and 4949 cannot
define that.

> 
>> - 4.3: I think you're saying here that the i2rs client is trusted
>> to simply assert the secondary identifier. If so, then saying that
>> >would be good. If not, then I don't know what you mean.
> 
> This section provides the security for the multi-headed collision
> resolution, and the traceability of any changes. The I2RS client is
> trusted to simply assert the secondary identifier.
> 
> [Text added in -16]
> 
>> - 4.4: I still don't see why it'd not be better to use a different
>> protocol for the non-secure stuff and avoid all the potential
>> >discussion and pitfalls of trying to do all this in one protocol.
> 
> The management application mechanisms for notification are complex,
> and re-using these notification mechanisms between the
> secure/non-secure protocol provides a common base for these
> notifications. [no text added]

Well, my guess is that that "common base" idea may end up being
a bad one. But we'll see later I guess.

> 
>> - 4.4: "It is mandatory to use (MTU) on any I2RS client's Write
>> transaction or the configuration of an Event Scope transaction." >
>> Which "it" do you mean?
> 
> Nice catch.  I've revised this text to:
> 
> SEC-REQ-09: The I2RS protocol MUST be able to transfer data over a 
> secure transport and optionally MAY be able to transfer data over a 
> non-secure transport. The default transport is a secure transport, 
> and this secure transport is mandatory to implement (MTI) in all I2RS
> agents, and in any I2RS client which: a) performs a Write scope
> transaction which is sent to the I2RS agent or b): configures an
> Event Scope transaction. This secure transport is mandatory to use
> (MTU) on any I2RS client's Write transaction or the configuration of
> an Event Scope transaction.
> 
>> - 4.4: The BCP107 stuff is still not useful.
> 
> The reason it is stated here is that we have routing systems being
> deployed with manual keys rotations rather than automatic.   The
> emphasis on limiting the manual keying systems.
> 
> - 4.5: "detect when the data integrity is questionable" - I've no
> idea what that means. Nor what it could mean.  Can you explain?
> 
> Since some of the data transmitted will formatted based on its
> content (web service up/down, peers up/down), Then some amount of
> contextual checking may indicated data is corrupted based on its
> content.
> 
> Text changed to:
> 
> Integrity of data is important even if the I2RS protocol is sending 
> non-confidential data over an insecure connection. The ability to
> trace I2RS protocol messages that enact I2RS transactions provides a
> minimal aid to helping operators check how messages enact
> transactions on a secure or insecure transport. Contextual checks on
> specific non-confidential data sent over a insecure connection may
> indicate the data integrity is questionable.
> 

Sorry, I'm still not getting it. Data integrity, as a network
service, is a binary yes/no thing. Questionable is not the result
from checking the output of a cryptographic function. Perhaps
you need to not use the term integrity when discussing data
sent via an insecure transport?

S.