[secdir] Initial review of draft-ietf-anima-bootstrapping-keyinfra-03

"Nancy Cam-Winget (ncamwing)" <ncamwing@cisco.com> Mon, 18 July 2016 03:46 UTC

Return-Path: <ncamwing@cisco.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9CE412D0C9; Sun, 17 Jul 2016 20:46:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.807
X-Spam-Level:
X-Spam-Status: No, score=-15.807 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 Na62W4Csf1fv; Sun, 17 Jul 2016 20:46:35 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC55112D0FC; Sun, 17 Jul 2016 20:46:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24556; q=dns/txt; s=iport; t=1468813595; x=1470023195; h=from:to:subject:date:message-id:mime-version; bh=BdsQdSy4FWx+la9jeXxG653jk4qx/jdiJWSbHuDMyCc=; b=Nb8gUO93x7Mx1ZEtNcHpxQ+WyJutdZabN/9N5fRaL7KpCVBHfmq5lYx/ TlBWB/emSBcivoJaFw3+q80mejtj4rDp02AfCGpuYLCRZFn0fVcj9o8el oRVretBDKa6m0XFBChus6X+PMk5zvVhYtU9G+R3hByM4aLCU/lzXX4NLj 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BFAgAYUIxX/5tdJa1SAQmCcU6BWLh0g?= =?us-ascii?q?XmHQzgUAQEBAQEBAWUnhGMMZhkBBjpAJwQBEIgylBaqfQEBAQcBAQEBI48PARG?= =?us-ascii?q?FcQWIJZB/AYE0jSqPN5AdAR42g3M/hicrGH8BAQE?=
X-IronPort-AV: E=Sophos;i="5.28,382,1464652800"; d="scan'208,217";a="298901087"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Jul 2016 03:46:34 +0000
Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u6I3kYt8025497 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 18 Jul 2016 03:46:34 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 17 Jul 2016 23:46:33 -0400
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Sun, 17 Jul 2016 23:46:33 -0400
From: "Nancy Cam-Winget (ncamwing)" <ncamwing@cisco.com>
To: "anima@ietf.org" <anima@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Thread-Topic: Initial review of draft-ietf-anima-bootstrapping-keyinfra-03
Thread-Index: AQHR4Kb6hoXgv1OH80i6Ph02ZsBt5Q==
Date: Mon, 18 Jul 2016 03:46:33 +0000
Message-ID: <D3B19F25.17FA5F%ncamwing@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.6.6.160626
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.1.202]
Content-Type: multipart/alternative; boundary="_000_D3B19F2517FA5Fncamwingciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/mDneTgOYRrM4otoZB92DlDoMMck>
Subject: [secdir] Initial review of draft-ietf-anima-bootstrapping-keyinfra-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Jul 2016 03:46:38 -0000

As the Security Advisor for Anima, I have reviewed draft-ietf-anima-bootstrapping-keyinfra-03

and have the following comments:


General

—————

Device is used inconsistently, but I believe in general device in this draft is the “target” or “new device”  that is being bootstrapped, correct?



Introduction

—————


In the paragraph beginning with “A precise answer to these questions….” (at end of page 3)

I believe “devices from a variety of vendors” includes all network devices as well as any generic device coming into the network and require bootstrap, but its not clear?


Not clear what  “and a network infrastructure (the domain) that is operated

   by parties that do not have any priviledged relationship with the

   device vendors”…..who are the device vendors? I think it is the “new device” manfufacturer or vendor?


Terminology

——————

I am presuming domain = internet domain?


Typo:  “Imprint” definition “key material to identity” should be “key material to identify”


Pledge definition: I think all references to “device” is the device needing to be bootstrapped?


Audit Token: it would be good to describe the “manufacturer authorized signing authority” (e.g. MASA) as I believe the MASA is in general the vendor’s manufacturer but in general, the MASA is some authority that s the one that can authorize the prospective devices to a particular domain (e.g. the domain of interest).  Thus the “it” in the “…that it authorizes bootstrap” is the MASA where the domain has assigned as the trusted authority.


Section 1.2

———————

Figure 1: New Entity = New Device (these two terms seems to be used intermittently, my nit would be to pick one for consistency)


MASA service: doesn’t the MASA also holds an authoritative view of what new devices can join the specific domain?


Ownership Tracker: in the Figure they are shown as part of the “Vendor Service” and “MASA”, are they abstractly all the same component but can physically be separate entities?  As it is understood there could be devices that come from multiple vendors, there can be many instances of the “Vendor Service”….but could also imply that within a “Vendor Service” there can be a decoupling of the MASA and Ownership Tracker?


Section 3.1

————-—

“A New Entity MUST NOT automatically initiate bootstrapping….”  how can this be enforced?  There should be some description of implications in the Security Considerations section (e.g. there may be instances in which a New Entity may need to go to a “factory default” state and be re-bootstrapped?)


Figure 2:  “Optional” can occur in advance” ….not clear what steps can be created in advance and how far in advance.  As the New Entity requests to join, it’s ID is not known to the Registrar, at least until the TLS connection is established….also, the Nonce is listed as optional, but SHOULD or MUST be required to map it to provided Join Request (e.g. it should be part of the same sequence).

Clarity somewhere in the document should be provided as to the operionality of which entity does the Authorization for the New Entity to be bootstrapped (e.g. is it the MASA or the Domain Registrar)….at this point it is not clear


Figure 3: Should the box be “Identify” vs “Identity”?


Step 2: “Identify itself” : what is meant by “Although the Registrar is also authenticated these

       credentials are only provisionally accepted at this time”?  I think the Registrar is provisionally accepting the 802.1AR to protect the TLS channel, is that the point of this sentence?  But I also believe the New Device must provisionally accept the Registrar’s cert (also indicated in Figure 2)?


Step 3: “Request to Join” maps to “Request Audit Token” in Figure 2?


Step 4:  “This requires verification of…”: the New Entity does the verification?  How does it do that? There is not enough details in here to describe how it actually does this. Perhaps these steps should be prefaces as “Summary” or “Brief/Abbreviated” state descriptions….


Step 5: this reads a bit awkward….I think the point of this step is that it now has enough information, for instance, knowing the domain registrar’s certificate to be able to initiate certificate enrollment; and can do such enrollment using RFC 7030. Correct?


Step 6: a nit: membership is based on the successful certificate enrollment of the new entity…correct?  This is correctly shown in Figure 3 :-)


Section 3.1.1

——————

1st paragraph is awkward, especially the last sentence, what is the point of stating “Therefore or clarity a Proxy is always assumed”?  I think the point is that typically, the discovery is typically achieved through a Proxy but there can be cases in which it “could” go to a Domain Registrar, but unlikely, thus a Proxy is needed, right?


Typo in step “d” : there’s an extra “k” in “bootstrapks service”


Section 3.1.2

——————

“the communication protocol” to be more explicit is during the Discovery protocol, correct?


What is the “bootstrapping protocol server” , the Domain Registrar?


Section 3.1.3

———————

What is the “bootstrapping protocol server” , the Domain Registrar?  This text seems to be inconsistent with Figure 2 as that Figure seems to indicate that the Join Request must be responded to before EST can come into play?


Section 3.1.4

————————

Similarly, I didn’t think EST was here “yet”….the Join Response (where the Audit Token is received by the New Entity) must be processed.  It is implied here that the Domain Registrar’s trust anchor is received.  But I think there are more explicit details to the contents of this response and how the New Device can actually verify (not sure it can validate?) that it has the right information to proceed with EST.


Section 3.3

———————

Would be good to have naming consistancy: Domain registrar vs. Registrar vs. Bootstrap Server (should be kept to 1 or 2 names to avoid confusion given that there are already several actors in the flow).


1st paragraph: Implies that the bootstrap server is the one that maintains the authorization database/state for which entities may be bootstrapped or not?


How does the Registrar know which/what MASA to reach to for the entity?  Is there a required trust relationship between the Registrar and the MASA to process the Audit request?  I think there is a MUST for this but I don’t see it in this section.


This section speaks to using EST, but I think the Join Request/Response are new messages (operations) which are augmented then to EST??


Section 4

——————

Is the Domain Operator the MASA?

Figure 5 looks different than Figure 2 and should be consistent or perhaps should be converged unless more details are to be provided in this sequence?



Security Considerations

———————————————

I need to better understand the full flow and roles of the different actors to later be able to more fully comment on what should be in the security considerations.


I think given the current state, this section provides a good start but would like to see more on the considerations of trust between the different actors (especially between the registrar and the MASA)

- Nancy