Re: [secdir] Early SecDir Reviews

Joel Halpern <> Mon, 24 August 2015 20:05 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 00BB11AD0CE; Mon, 24 Aug 2015 13:05:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7_c359O431XW; Mon, 24 Aug 2015 13:05:28 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 960321AD0CB; Mon, 24 Aug 2015 13:05:28 -0700 (PDT)
X-AuditID: c618062d-f79ef6d000007f54-c4-55db1b68e530
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 6E.94.32596.86B1BD55; Mon, 24 Aug 2015 15:26:00 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.03.0210.002; Mon, 24 Aug 2015 16:05:26 -0400
From: Joel Halpern <>
To: Russ Housley <>, Susan Hares <>
Thread-Topic: Early SecDir Reviews
Thread-Index: AQHQ3F425WoS4nSBsU6hU5efBIZq554bupuAgAAVhwD//8cVIA==
Date: Mon, 24 Aug 2015 20:05:26 +0000
Message-ID: <>
References: <> <00c201d0de98$25ac79c0$71056d40$> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjkeLIzCtJLcpLzFFi42KZXLonQTdD+naowb1nNhYfXx9htVi7qpvV 4tWLm+wWDTvzLT4sfMhi8efNKxaL6XuvsTuwe6ztvsrmsXPWXXaPJUt+MnnMfn2d1WPVnS+s AaxRXDYpqTmZZalF+nYJXBmP905gL3ghVHHvRBd7A+Nvvi5GTg4JAROJiV+nsUPYYhIX7q1n A7GFBI4ySjy+ygNhL2eU+HDXEcRmE9CTWPv+MROILSLgJjH/ymQgm4uDWeAak8Th561gCWEB RYn2/7OYIYqUJJ493soCYTtJvPs9F6iGg4NFQFXi/0JfkDCvgK/Eur3nWCF2LWKUmDOhGsTm FHCQeLZuPlgrI9Bt30+tARvPLCAucevJfCaImwUkluw5zwxhi0q8fPyPFcJWkpjz+hozRL2O xILdn9ggbG2JZQtfM0PsFZQ4OfMJywRGsVlIxs5C0jILScssJC0LGFlWMXKUFqeW5aYbGWxi BEbcMQk23R2Me15aHmIU4GBU4uFV4LoVKsSaWFZcmXuIUZqDRUmc1zEqL1RIID2xJDU7NbUg tSi+qDQntfgQIxMHp1QDY95Lk8P685gv+GTMFpvUO6sp2fvYn6Mrw1iPqvtsOzvtYl951/Zz fQFdznK1Md+v3udUdfcOUjOMvvt1QnpD+I/Pu4/WvN95Ln7n9+Inj+4vWsJ768Yb/nWuHlpd FZ/fOFQL3O7gNi08zRlp2v31yfW9LZ5GYbWNOlNqv7InvHrec6XrZI1WoxJLcUaioRZzUXEi AP7jvqCZAgAA
Archived-At: <>
Cc: 'IETF SecDir' <>, 'Kathleen Moriarty' <>, "" <>, "" <>
Subject: Re: [secdir] Early SecDir Reviews
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 24 Aug 2015 20:05:31 -0000

Hannes is probably correct that we mean identifier, not identity, in almost all cases in the document.

In particular, regarding primary and secondry identifier, the secondary identifier is NOT used for any security decisions.  Access control is based only on the primary identifier.


-----Original Message-----
From: Russ Housley [] 
Sent: Monday, August 24, 2015 3:27 PM
To: Susan Hares
Cc:;; 'Stephen Farrell'; 'Kathleen Moriarty'; 'IETF SecDir'
Subject: Re: Early SecDir Reviews


> 1) Is REQ-8 a security requirement? 
>   o  SEC-REQ-08: Each Identity is associated with one secondary
>      identity during a particular read/write sequence, but the
>      secondary identity may vary during the time a connection between
>      the I2RS client and I2RS agent is active.  The variance of the
>      secondary identity allows the I2rs client to be associated with
>      multiple applications and pass along an identifier for these
>      applications in the secondary identifier.

Yes, if that identity is going to be used to make the access control decision.

> 2) Is REQ-12 - a security requirement for a protocol?  NETCONF asked 
> this of I2RS.
>   SEC-REQ-12: The I2RS Client and I2RS Agent protocol SHOULD implement
>   mechanisms that mitigate DoS attacks

Yes.  For example, the IKE cookie mechanism is only there to make it much more expensive the an attacker ti implement DDoS.  They can't fire and forget.  They need to keep state and hang around for at least 1.5 round trips.

> 3) Section 2.4.1 - is a description of the what happens when multiple 
> changes occur via multiple messages.
> My understanding from your question is that the implementation of how 
> an I2RS Agent processes the changes (change1, change2, change3) that 
> occur in multiple messages is not a security issue, but a 
> implementation issue.  If so, Please let me know.

There might be some protocol issues to assist keep things atomic, but I agree it i not a security issue.

> 4) Are you Ok with REQ-09 specifying a non-secure transport as an option? 

The security considerations need to be clear what the consequences are if this option is selected.