< draft-richardson-anima-smarkaklink-00.txt   draft-richardson-anima-smarkaklink-01.txt >
6tisch Working Group M. Richardson 6tisch Working Group M. Richardson
Internet-Draft Sandelman Software Works Internet-Draft Sandelman Software Works
Intended status: Informational J. Latour Intended status: Informational J. Latour
Expires: September 12, 2019 CIRA Labs Expires: January 9, 2020 CIRA Labs
F. Khan A. Schiltkneckt
A. Joshi Viagenie
Twelve Dot Systems July 08, 2019
March 11, 2019
BRSKI enrollment of with disconnected Registrars -- smarkaklink BRSKI enrollment of with disconnected Registrars -- smarkaklink
draft-richardson-anima-smarkaklink-00 draft-richardson-anima-smarkaklink-01
Abstract Abstract
This document details the mechanism used for initial enrollment using This document details the mechanism used for initial enrollment using
a smartphone of a BRSKI Registrar system. a smartphone of a BRSKI Registrar system.
There are two key differences in assumption from There are two key differences in assumption from
[I-D.ietf-anima-bootstrapping-keyinfra]: that the intended registrar [I-D.ietf-anima-bootstrapping-keyinfra]: that the intended registrar
has Internet, and that the Pledge has no user-interface. has Internet, and that the Pledge has no user-interface.
skipping to change at page 1, line 45 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 12, 2019. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 32 skipping to change at page 2, line 32
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Intermittent Device connectivity . . . . . . . . . . . . 4 1.1. Intermittent Device connectivity . . . . . . . . . . . . 4
1.2. Additional Motivation . . . . . . . . . . . . . . . . . . 4 1.2. Additional Motivation . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. History and Origin of the name . . . . . . . . . . . . . 6 2.1. History and Origin of the name . . . . . . . . . . . . . 6
3. Requirements Language . . . . . . . . . . . . . . . . . . . . 6 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 6
4. Assumptions and Required Setup . . . . . . . . . . . . . . . 6 4. Assumptions and Required Setup . . . . . . . . . . . . . . . 6
5. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7 5. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Scan the QR code . . . . . . . . . . . . . . . . . . . . 7 5.1. Scan the QR code . . . . . . . . . . . . . . . . . . . . 7
5.2. Enroll with the manufacturer . . . . . . . . . . . . . . 7 5.2. Enroll with the manufacturer . . . . . . . . . . . . . . 7
5.3. Connect to BRSKI join network . . . . . . . . . . . . . . 7 5.3. Gather name details for new device . . . . . . . . . . . 7
5.4. Connect to Adolescent Registrar (AR) . . . . . . . . . . 8 5.4. Connect to BRSKI join network . . . . . . . . . . . . . . 8
5.5. Pledge Requests Voucher-Request from the Adolescent 5.5. Connect to Adolescent Registrar (AR) . . . . . . . . . . 8
Registrar . . . . . . . . . . . . . . . . . . . . . . . . 8 5.6. Pledge Requests Voucher-Request from the Adolescent
5.6. AR processing of voucher-request, request. . . . . . . . 9 Registrar . . . . . . . . . . . . . . . . . . . . . . . . 9
5.6.1. Additions to Voucher-Request . . . . . . . . . . . . 9 5.7. AR processing of voucher-request, request. . . . . . . . 10
5.7. Smartphone validates connection . . . . . . . . . . . . . 9 5.7.1. Additions to Voucher-Request . . . . . . . . . . . . 10
5.8. Smart-Phone connects to MASA . . . . . . . . . . . . . . 10 5.8. Smartphone validates connection . . . . . . . . . . . . . 10
5.9. MASA processing . . . . . . . . . . . . . . . . . . . . . 10 5.9. Smart-Phone connects to MASA . . . . . . . . . . . . . . 11
5.10. Smartpledge processing of voucher . . . . . . . . . . . . 10 5.10. MASA processing . . . . . . . . . . . . . . . . . . . . . 11
5.11. Adolescent Registrar (AR) receives voucher . . . . . . . 11 5.11. Smartpledge processing of voucher . . . . . . . . . . . . 11
5.12. Adolescent Registrar (AR) grows up . . . . . . . . . . . 11 5.12. Adolescent Registrar (AR) receives voucher . . . . . . . 12
5.13. Smartphone enrolls . . . . . . . . . . . . . . . . . . . 11 5.13. Adolescent Registrar (AR) grows up . . . . . . . . . . . 12
5.14. Validation of connection . . . . . . . . . . . . . . . . 12 5.14. Enrollment status . . . . . . . . . . . . . . . . . . . . 12
6. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 12 5.15. Smartphone enrolls . . . . . . . . . . . . . . . . . . . 13
6.1. Quick Response Code (QR code) . . . . . . . . . . . . . . 12 5.16. Validation of connection . . . . . . . . . . . . . . . . 13
6.1.1. The Smarkaklink Attribute . . . . . . . . . . . . . . 13 6. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 14
6.1.2. Link-Layer Address Attribute . . . . . . . . . . . . 13 6.1. Quick Response Code (QR code) . . . . . . . . . . . . . . 14
6.1.3. ESSID Name Attribute . . . . . . . . . . . . . . . . 14 6.1.1. The Smarkaklink Attribute . . . . . . . . . . . . . . 14
6.2. Enrollment using EST . . . . . . . . . . . . . . . . . . 14 6.1.2. Link-Layer Address Attribute . . . . . . . . . . . . 15
7. Smart Pledge enrollment with manufacturer . . . . . . . . . . 14 6.1.3. ESSID Name Attribute . . . . . . . . . . . . . . . . 15
7.1. minimal Smart Pledge enrollment . . . . . . . . . . . . . 16
8. Threat Analysis . . . . . . . . . . . . . . . . . . . . . . . 16 6.2. Enrollment using EST . . . . . . . . . . . . . . . . . . 15
8.1. Wrong Administrator . . . . . . . . . . . . . . . . . . . 16 7. Smart Pledge enrollment with manufacturer . . . . . . . . . . 15
8.2. Rogue Administrator . . . . . . . . . . . . . . . . . . . 16 7.1. minimal Smart Pledge enrollment . . . . . . . . . . . . . 17
8.3. Attack from Internal device . . . . . . . . . . . . . . . 16 8. Threat Analysis . . . . . . . . . . . . . . . . . . . . . . . 17
8.4. Attack from camera enabled robot . . . . . . . . . . . . 16 8.1. Wrong Administrator . . . . . . . . . . . . . . . . . . . 18
8.5. Attack from manipulator enabled robot . . . . . . . . . . 17 8.2. Rogue Administrator . . . . . . . . . . . . . . . . . . . 18
9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8.3. Attack from Internal device . . . . . . . . . . . . . . . 18
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 8.4. Attack from camera enabled robot . . . . . . . . . . . . 18
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 8.5. Attack from manipulator enabled robot . . . . . . . . . . 18
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18
12.1. Normative References . . . . . . . . . . . . . . . . . . 17 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
12.2. Informative References . . . . . . . . . . . . . . . . . 18 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
Appendix A. Resulting DPP QR code specification . . . . . . . . 18 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
Appendix B. Swagger.IO definition of API . . . . . . . . . . . . 19 12.1. Normative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 12.2. Informative References . . . . . . . . . . . . . . . . . 19
Appendix A. Resulting DPP QR code specification . . . . . . . . 20
Appendix B. Swagger.IO definition of API . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
The problem of bootstrapping a new device is described at length in The problem of bootstrapping a new device is described at length in
[I-D.ietf-anima-bootstrapping-keyinfra] (aka BRSKI). The problem [I-D.ietf-anima-bootstrapping-keyinfra] (aka BRSKI). The problem
that BRSKI solves is the case of a smart, properly configured network that BRSKI solves is the case of a smart, properly configured network
with a minimum of network connectivity (or previously pre-previoned with a minimum of network connectivity (or previously pre-previoned
with nonceless vouchers), and a relatively stupid new device (the with nonceless vouchers), and a relatively stupid new device (the
Pledge), which lacks a user interface. Pledge), which lacks a user interface.
skipping to change at page 7, line 45 skipping to change at page 7, line 47
The smartphone does an HTTP POST to the provided URL using it's The smartphone does an HTTP POST to the provided URL using it's
generated certificate as it's ClientCertificate. As described in generated certificate as it's ClientCertificate. As described in
Section 7, the manufacturer MAY respond with a 302 result code, and Section 7, the manufacturer MAY respond with a 302 result code, and
have the end user go through a web browser based process to enroll. have the end user go through a web browser based process to enroll.
After that process, a redirection will occur using OAUTH2. After that process, a redirection will occur using OAUTH2.
The result should finally be a 201 result code, and at that URL is a The result should finally be a 201 result code, and at that URL is a
new certificate signed by the manufacturer. new certificate signed by the manufacturer.
5.3. Connect to BRSKI join network 5.3. Gather name details for new device
The contents of the scanned QR code may some necessary information to
facilititate the connection. After enrolling with the manufacturer,
the smartphone makes a request to the manufacturer to get more
details.
A POST request is made containing the public key of the device. The
public key is used as an index, and this MAY result in a literal
reply, or may result in an HTTP 201 response with a Location: header
where details on the device may be obtained.
The final result is a JSON object that provides additional details
about the device. At present, a key detail that does not fit into
the QR code is the full certificate distinguished name that the
device will respond with.
This is the Adolescent Router Fully Qualified Domain Name, or AD-
FQDN.
Additionally, if the device does not have a certificate that has a
public WebPKI anchor, then the manufacturer will include an
appropriate trust anchor with which to validate the device. If the
device has a self-signed certificate, then it may be returned.
5.4. Connect to BRSKI join network
The application then reconnects the Wi-Fi interface of the smartphone The application then reconnects the Wi-Fi interface of the smartphone
to the ESSID of the AR. This involves normal 802.11 station to the ESSID of the AR. This involves normal 802.11 station
attachment. The given ESSID explicitely has no WPA or other security attachment. The given ESSID explicitely has no WPA or other security
required on it. required on it.
There will be no DHCPv4 on this network. This simplifies the There will be no DHCPv4 on this network. This simplifies the
operation of the devices that are enrolling, but it also makes the operation of the devices that are enrolling, but it also makes the
network uninteresting to other random users that may stumble upon the network uninteresting to other random users that may stumble upon the
open ESSID. open ESSID.
A IPv6 Router Solicitation may elicit an answer (confirming the A IPv6 Router Solicitation may elicit an answer (confirming the
device is there), but it is acceptable for there to be no prefix device is there), but it is acceptable for there to be no prefix
information. An IPv6 Neighbour Discovery is done for the IPv6 Link- information. An IPv6 Neighbour Discovery is done for the IPv6 Link-
Local address of the AR. Receipt of an answer confirms that the Local address of the AR. Receipt of an answer confirms that the
ESSID is correct and present. ESSID is correct and present.
(XXX - not using GRASP here. Could use GRASP, but QR code is better) (XXX - not using GRASP here. Could use GRASP, but QR code is better)
5.4. Connect to Adolescent Registrar (AR) 5.5. Connect to Adolescent Registrar (AR)
The smarkaklink application then makes a direct (no proxy) TLS The smarkaklink application then makes a direct (no proxy) TLS
connection to port 8443 (!XXX!) of the AR, on the IPv6 Link-Local connection to port 8081 (!To be confirmed!) of the AR, on the IPv6
address given. This is as in section 5.1 of Link-Local address given.
[I-D.ietf-anima-bootstrapping-keyinfra]. The smartphone uses it's
SelfDevID as the TLS ClientCertificate, as the smartphone and This is as in section 5.1 of [I-D.ietf-anima-bootstrapping-keyinfra].
smarkaklink will not have a manufacturer signed IDevID. The smartphone uses it's SelfDevID as the TLS ClientCertificate, as
the smartphone and smarkaklink will not have a manufacturer signed
IDevID.
Additionally, the AR will use it's IDevID certificate as the Additionally, the AR will use it's IDevID certificate as the
ServerCertificate of the TLS conncetion. As with other BRSKI IDevID, ServerCertificate of the TLS conncetion. As with other BRSKI IDevID,
it will have a MASA URL extension, as described in it will have a MASA URL extension, as described in
[I-D.ietf-anima-bootstrapping-keyinfra] section 2.3.2. [I-D.ietf-anima-bootstrapping-keyinfra] section 2.3.2.
The Adolescent Registrar acts in the role of pledge! The Adolescent Registrar is acting here in the role of pledge.
5.5. Pledge Requests Voucher-Request from the Adolescent Registrar Given typical libraries, the connection will be made initially with
all TLS peer name validation turned off, as the connection will not
be to an IPv6 Link-Local address, which can not be placed into a
certificate. The certificate should still be verified if possible up
to a public trust anchor.
The smartphone generates a random nonce _SPnonce_. To this is added After connecting, the certificate presented by the AR MUST contain
SOMETHING-that-is-time-unique, to create a _voucher-request the AR-FQDN provided above as a subjectAltName rfc822Name extension.
challenge_. This is placed in the voucher-challenge-nonce field.
Using the public-key of the AR that was scanned from the QR code, the Alternatively, a custom certification verification call back may be
smartphone encrypts the challenge using CMS (or COSE?). made.
5.6. Pledge Requests Voucher-Request from the Adolescent Registrar
The smartphone generates a random nonce _SPnonce_. (Do we need
something time-based too here?)
The smarkaklink client encrypts this to the public key of the AR,
which was found in the QR code. If the key is RSA, this is a simple
public key operation (we need to reference appropriate padding due to
various attacks). In the mandatory to implement ECDSA case, then
ECIES is used instead.
The result goes into the Voucher-Request-Request, posted as a JSON
containing a single field: _voucher-request challenge_. This is
placed in the voucher-challenge-nonce field.
(XXX-should be done with JOSE? Probably)
NOTE: DPP has a round with the SHA256 of the device's key to make NOTE: DPP has a round with the SHA256 of the device's key to make
sure that the correct device has been chosen. The TLS connection sure that the correct device has been chosen. The TLS connection
effectively provides the same privacy that the Bx keys provided. effectively provides the same privacy that the Bx keys provided.
The resulting object is POST'ed to the new BRSKI endpoint: The resulting object is POST'ed to the new BRSKI endpoint:
/.well-known/est/requestvoucherrequest /.well-known/est/requestvoucherrequest
[or should it be named: /.well-known/est/requestvoucherchallenge [or should it be named: /.well-known/est/requestvoucherchallenge
skipping to change at page 9, line 4 skipping to change at page 10, line 6
NOTE: DPP has a round with the SHA256 of the device's key to make NOTE: DPP has a round with the SHA256 of the device's key to make
sure that the correct device has been chosen. The TLS connection sure that the correct device has been chosen. The TLS connection
effectively provides the same privacy that the Bx keys provided. effectively provides the same privacy that the Bx keys provided.
The resulting object is POST'ed to the new BRSKI endpoint: The resulting object is POST'ed to the new BRSKI endpoint:
/.well-known/est/requestvoucherrequest /.well-known/est/requestvoucherrequest
[or should it be named: /.well-known/est/requestvoucherchallenge [or should it be named: /.well-known/est/requestvoucherchallenge
] ]
5.6. AR processing of voucher-request, request. 5.7. AR processing of voucher-request, request.
The AR processes this POST. First it uses the private key that is The AR processes this POST. First it uses the private key that is
associated with it's QR printed public key to decrypt the voucher- associated with it's QR printed public key to decrypt the voucher-
request challenge. Included in this challenge is a nonce, and also request challenge. Included in this challenge is a nonce, and also
the link-local address of the smartphone. the link-local address of the smartphone.
The AR SHOULD verify that the link-local address matches the The AR SHOULD verify that the link-local address matches the
originating address of the connection on which the request is originating address of the connection on which the request is
received. received.
skipping to change at page 9, line 34 skipping to change at page 10, line 37
In addition to the randomly generated nonce that the AR generates to In addition to the randomly generated nonce that the AR generates to
place in the the voucher-request, into the nonce field, it also place in the the voucher-request, into the nonce field, it also
includes the _SPnonce_ in a new _voucher-challenge-nonce_ field. includes the _SPnonce_ in a new _voucher-challenge-nonce_ field.
{EDNOTE: hash of nonce?} {EDNOTE: hash of nonce?}
This voucher-request is then _returned_ during the POST operation to This voucher-request is then _returned_ during the POST operation to
the smartphone. (This is in constrast that in ANIMA the voucher- the smartphone. (This is in constrast that in ANIMA the voucher-
request is sent by the device to the Registrar, or the MASA) request is sent by the device to the Registrar, or the MASA)
5.6.1. Additions to Voucher-Request 5.7.1. Additions to Voucher-Request
QUESTION: should the _voucher-challenge-nonce_ be provided directly QUESTION: should the _voucher-challenge-nonce_ be provided directly
in the voucher-request, or should only a hash of the nonce be used? in the voucher-request, or should only a hash of the nonce be used?
The nonce is otherwise not disclosed, and a MITM on the initial TLS The nonce is otherwise not disclosed, and a MITM on the initial TLS
connection would get to see the nonce. A hash of the nonce validates connection would get to see the nonce. A hash of the nonce validates
the nonce as easily. the nonce as easily.
5.7. Smartphone validates connection 5.8. Smartphone validates connection
The smartphone then examines the resulting voucher-request. The The smartphone then examines the resulting voucher-request. The
smartphone validates that the voucher-request is signed by the same smartphone validates that the voucher-request is signed by the same
public key as was seen in the TLS ServerCertificate. public key as was seen in the TLS ServerCertificate.
The smartphone then examines the contents of the voucher-request, and The smartphone then examines the contents of the voucher-request, and
looks for the _voucher-challenge-nonce_. As this nonce was encrypted looks for the _voucher-challenge-nonce_. As this nonce was encrypted
to the AR, the only way that the resulting nonce could be correct is to the AR, the only way that the resulting nonce could be correct is
if the correct private key was present on the AR to decrypt it. if the correct private key was present on the AR to decrypt it.
Succesful verification of the _voucher-challenge-nonce_ (or the hash Succesful verification of the _voucher-challenge-nonce_ (or the hash
of it, see below) results in the smartphone moving it's end of the of it, see below) results in the smartphone moving it's end of the
connection from provisional to validated. connection from provisional to validated.
5.8. Smart-Phone connects to MASA 5.9. Smart-Phone connects to MASA
The smarkaklink application running on the smartphone then examines The smarkaklink application running on the smartphone then examines
the MASA URL provided in the TLS ServerCertificate of the AR. The the MASA URL provided in the TLS ServerCertificate of the AR. The
smarkaklink application then connects to that URL using it's 3G/LTE smarkaklink application then connects to that URL using it's 3G/LTE
connection, taking on the temporary role of Registrar. connection, taking on the temporary role of Registrar.
A wrapped voucher-request is formed by the smartphone in the same way A wrapped voucher-request is formed by the smartphone in the same way
as described in section 5.4 of as described in section 5.4 of
[I-D.ietf-anima-bootstrapping-keyinfra]. The prior-signed-voucher- [I-D.ietf-anima-bootstrapping-keyinfra]. The prior-signed-voucher-
request is filled in with the voucher-request that was created by the request is filled in with the voucher-request that was created by the
skipping to change at page 10, line 31 skipping to change at page 11, line 32
The proximity-registrar-cert of the wrapped voucher-request is set to The proximity-registrar-cert of the wrapped voucher-request is set to
be the SelfDevID certificate of the smartphone. The voucher-request be the SelfDevID certificate of the smartphone. The voucher-request
is to be signed by the SelfDevID. is to be signed by the SelfDevID.
The voucher-request is POST'ed to the MASA using the same URL that is The voucher-request is POST'ed to the MASA using the same URL that is
used for Registrar/MASA operation: used for Registrar/MASA operation:
/.well-known/est/requestvoucher /.well-known/est/requestvoucher
5.9. MASA processing 5.10. MASA processing
The MASA processing occurs as specified in section 5.5 of The MASA processing occurs as specified in section 5.5 of
[I-D.ietf-anima-bootstrapping-keyinfra] as before. The MASA MUST [I-D.ietf-anima-bootstrapping-keyinfra] as before. The MASA MUST
also copy the _voucher-challenge-nonce_ into the resulting voucher. also copy the _voucher-challenge-nonce_ into the resulting voucher.
5.10. Smartpledge processing of voucher 5.11. Smartpledge processing of voucher
The smartphone will receive a voucher that contains it's IDevID as The smartphone will receive a voucher that contains it's IDevID as
the _pinned-domain-cert_, and the _voucher-challenge-nonce_ that it the _pinned-domain-cert_, and the _voucher-challenge-nonce_ that it
created will also be present. The smartphone SHOULD verify the created will also be present. The smartphone SHOULD verify the
signature on the artifact, but may be unable to validate that the signature on the artifact, but may be unable to validate that the
certificate used has a relationship to the TLS ServerCertificate used certificate used has a relationship to the TLS ServerCertificate used
by the MASA. (This limitation exists in ANIMA as well). by the MASA. (This limitation exists in ANIMA as well).
The smartphone will then POST the resulting voucher to the AR using The smartphone will then POST the resulting voucher to the AR using
the URL the URL
skipping to change at page 10, line 50 skipping to change at page 12, line 4
the _pinned-domain-cert_, and the _voucher-challenge-nonce_ that it the _pinned-domain-cert_, and the _voucher-challenge-nonce_ that it
created will also be present. The smartphone SHOULD verify the created will also be present. The smartphone SHOULD verify the
signature on the artifact, but may be unable to validate that the signature on the artifact, but may be unable to validate that the
certificate used has a relationship to the TLS ServerCertificate used certificate used has a relationship to the TLS ServerCertificate used
by the MASA. (This limitation exists in ANIMA as well). by the MASA. (This limitation exists in ANIMA as well).
The smartphone will then POST the resulting voucher to the AR using The smartphone will then POST the resulting voucher to the AR using
the URL the URL
/.well-known/est/voucher /.well-known/est/voucher
If an existing TLS connection is still available, it MAY be reused. If an existing TLS connection is still available, it MAY be reused.
If a TLS session-resumption ticket (see [RFC8446] section 2.2 for TLS If a TLS session-resumption ticket (see [RFC8446] section 2.2 for TLS
1.3, and [RFC5077] for TLS 1.2) has been obtained, it SHOULD be used 1.3, and [RFC5077] for TLS 1.2) has been obtained, it SHOULD be used
if the TLS connection needs to be rebuilt. This is particularly if the TLS connection needs to be rebuilt. This is particularly
useful in the disconnected use case explained in Section 1.1. useful in the disconnected use case explained in Section 1.1.
5.11. Adolescent Registrar (AR) receives voucher 5.12. Adolescent Registrar (AR) receives voucher
When the AR receives the voucher, it validates that it is signed by When the AR receives the voucher, it validates that it is signed by
it's manufacturer. This process is the same as section 5.5.1 of it's manufacturer. This process is the same as section 5.5.1 of
[I-D.ietf-anima-bootstrapping-keyinfra]. [I-D.ietf-anima-bootstrapping-keyinfra].
Again note that the AR is acting in the role of a pledge. Again note that the AR is acting in the role of a pledge.
Inside the voucher, the pinned-domain-cert is examined. It should Inside the voucher, the pinned-domain-cert is examined. It should
match the TLS ClientCertificate that the smartphone used to connect. match the TLS ClientCertificate that the smartphone used to connect.
This is the SelfDevID. This is the SelfDevID.
At this point the AR has validated the identity of the smartphone, At this point the AR has validated the identity of the smartphone,
and the AR moves it's end of the connection from provisional to and the AR moves it's end of the connection from provisional to
validated. validated.
5.12. Adolescent Registrar (AR) grows up 5.13. Adolescent Registrar (AR) grows up
The roles are now changed. The roles are now changed.
If necessary, the AR generates a new key pair as it's Domain CA key. If necessary, the AR generates a new key pair as it's Domain CA key.
It MAY generate intermediate CA certificates and a seperate Registrar It MAY generate intermediate CA certificates and a seperate Registrar
certificate, but this is discouraged for home network use. certificate, but this is discouraged for home network use.
The AR is now considered a full registrar. The AR now takes on the The AR is now considered a full registrar. The AR now takes on the
role of Registrar. role of Registrar.
5.13. Smartphone enrolls 5.14. Enrollment status
The AR responds to the POST of the voucher with the enrollment status
as the reply to the POST, as per the enrollment status object defined
in BRSKI section 5.9.4.
The smartphone MAY POST the resulting enrollment status to the MASA,
in a manner similar to BRSKI section 5.9.4. Note that the operation
described in that section is about telemetry from the pledge to the
Registrar. That telemetry was return as part of the POST above.
Returning enrollment status to the MASA is an optional action; while
there are privacy implications of doing so, the logicstics feedback
of a failure likely will result in a service technician visit, which
is hardly privacy enhancing. This telemetry return is strongly
encouraged.
The POST to /.well-known/est/enrollstatus MUST include some
additional information to tell the MASA which device was involved.
This section therefore defines a new element for the status return to
be the "voucher" attribute; it is to be filled in with the base64
encoding of the voucher that was provided. While this is excessive,
it discloses no information that the MASA does not already have, has
been signed and identifies both the Adolescent Router and the Smart
Phone client involved.
5.15. Smartphone enrolls
At this stage of the smarkaklink protocol, the typical BRSKI exchange At this stage of the smarkaklink protocol, the typical BRSKI exchange
is over. A Secure Transport has been established between the is over. A Secure Transport has been established between the
smartphone and the fully-grown AR. The smartphone now takes on the smartphone and the fully-grown AR. The smartphone now takes on the
role of secured pledge, or EST client. role of secured pledge, or EST client.
The smartphone MUST now request the full list of CA Certificates, as The smartphone MUST now request the full list of CA Certificates, as
per [RFC7030] section 4.1. As the Registrar's CA certificate has per [RFC7030] section 4.1. As the Registrar's CA certificate has
just been generated, the smartphone has no other way of knowing it. just been generated, the smartphone has no other way of knowing it.
skipping to change at page 12, line 4 skipping to change at page 13, line 31
role of secured pledge, or EST client. role of secured pledge, or EST client.
The smartphone MUST now request the full list of CA Certificates, as The smartphone MUST now request the full list of CA Certificates, as
per [RFC7030] section 4.1. As the Registrar's CA certificate has per [RFC7030] section 4.1. As the Registrar's CA certificate has
just been generated, the smartphone has no other way of knowing it. just been generated, the smartphone has no other way of knowing it.
The smartphone MUST now also generate a CSR request as per The smartphone MUST now also generate a CSR request as per
[I-D.ietf-anima-bootstrapping-keyinfra] section 5.8.3. The [I-D.ietf-anima-bootstrapping-keyinfra] section 5.8.3. The
smartpledge MAY reuse the SelfDevID key pair for this purpose. (XXX smartpledge MAY reuse the SelfDevID key pair for this purpose. (XXX
- maybe there are good reasons not to reuse?) - maybe there are good reasons not to reuse?)
The Registrar SHOULD grant administrator privileges to the smartphone The Registrar SHOULD grant administrator privileges to the smartphone
via the certificate that is issued. This may be done via special via the certificate that is issued. This may be done via special
attributes in the issued certificate, or it may pin the certificate attributes in the issued certificate, or it may pin the certificate
in a database. Which method to use is a local matter. in a database. Which method to use is a local matter.
The TLS/EST connection MUST remain open at this point. This is The TLS/EST connection MUST remain open at this point. This is
connection one. connection one.
5.14. Validation of connection 5.16. Validation of connection
The smartphone MUST now open a new HTTPS connection to the Registrar The smartphone MUST now open a new HTTPS connection to the Registrar
(AR), using it's newly issued certificate. (XXX should this be on a (AR), using it's newly issued certificate. (XXX should this be on a
different IP, or a different port? If so, how is this indicated?) different IP, or a different port? If so, how is this indicated?)
The smartphone MUST validate that the new connection's TLS Server The smartphone MUST validate that the new connection's TLS Server
certificate can be validated by the Registrar's new CA certificate. certificate can be validated by the Registrar's new CA certificate.
The registrar MUST validate that the smartphone's ClientCertificate The registrar MUST validate that the smartphone's ClientCertificate
is validated by the Registrar's CA. The smartphone SHOULD perform a is validated by the Registrar's CA. The smartphone SHOULD perform a
skipping to change at page 12, line 24 skipping to change at page 14, line 4
The smartphone MUST now open a new HTTPS connection to the Registrar The smartphone MUST now open a new HTTPS connection to the Registrar
(AR), using it's newly issued certificate. (XXX should this be on a (AR), using it's newly issued certificate. (XXX should this be on a
different IP, or a different port? If so, how is this indicated?) different IP, or a different port? If so, how is this indicated?)
The smartphone MUST validate that the new connection's TLS Server The smartphone MUST validate that the new connection's TLS Server
certificate can be validated by the Registrar's new CA certificate. certificate can be validated by the Registrar's new CA certificate.
The registrar MUST validate that the smartphone's ClientCertificate The registrar MUST validate that the smartphone's ClientCertificate
is validated by the Registrar's CA. The smartphone SHOULD perform a is validated by the Registrar's CA. The smartphone SHOULD perform a
POST operation on this new connection to the POST operation on this new connection to the
[I-D.ietf-anima-bootstrapping-keyinfra] Enrollment Status Telemetry [I-D.ietf-anima-bootstrapping-keyinfra] Enrollment Status Telemetry
mechanism, see section 5.8.3. mechanism, see section 5.8.3.
Upon success, the original TLS/EST connection (one) MAY now be Upon success, the original TLS/EST connection (one) MAY now be
closed. closed.
Should the validations above fail, then the original EST connection
MUST be used to GET a value from the
/.well-known/est/enrollstatus
from the Registrar. The contents of this value SHOULD then be sent
to the MASA, using a POST to the enrollstatus, and including the
reply from the AR in a new attribute, "adolescent-registrar-reason".
6. Protocol Details 6. Protocol Details
6.1. Quick Response Code (QR code) 6.1. Quick Response Code (QR code)
Section 5.3 of [dpp] describes the contents for an [iso18004] image. Section 5.3 of [dpp] describes the contents for an [iso18004] image.
It specifies content that starts with DPP:, and the contains a series It specifies content that starts with DPP:, and the contains a series
of semi-colon (;) deliminated section with a single letter and colon. of semi-colon (;) deliminated section with a single letter and colon.
This markup is terminated with a double semi-colon. This markup is terminated with a double semi-colon.
Although no amending formula is defined in DPP 1.0, this document is Although no amending formula is defined in DPP 1.0, this document is
skipping to change at page 17, line 41 skipping to change at page 19, line 15
[dpp] "Device Provisioning Protocol Specification", n.d., [dpp] "Device Provisioning Protocol Specification", n.d.,
<https://www.wi-fi.org/downloads-registered-guest/Device_P <https://www.wi-fi.org/downloads-registered-guest/Device_P
rovisioning_Protocol_Draft_Technical_Specification_Package rovisioning_Protocol_Draft_Technical_Specification_Package
_v0_0_23_0.zip/31255>. _v0_0_23_0.zip/31255>.
[I-D.ietf-anima-bootstrapping-keyinfra] [I-D.ietf-anima-bootstrapping-keyinfra]
Pritikin, M., Richardson, M., Behringer, M., Bjarnason, Pritikin, M., Richardson, M., Behringer, M., Bjarnason,
S., and K. Watsen, "Bootstrapping Remote Secure Key S., and K. Watsen, "Bootstrapping Remote Secure Key
Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-
keyinfra-18 (work in progress), January 2019. keyinfra-22 (work in progress), June 2019.
[iso18004] [iso18004]
"Information technology --- Automatic identification and "Information technology --- Automatic identification and
data capture techniques --- Bar code symbology --- QR data capture techniques --- Bar code symbology --- QR
Codes (ISO/IEC 18004:2015)", n.d., Codes (ISO/IEC 18004:2015)", n.d.,
<https://github.com/yansikeim/QR-Code/blob/master/ <https://github.com/yansikeim/QR-Code/blob/master/
ISO%20IEC%2018004%202015%20Standard.pdf>. ISO%20IEC%2018004%202015%20Standard.pdf>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
skipping to change at page 22, line 28 skipping to change at page 23, line 42
Michael Richardson Michael Richardson
Sandelman Software Works Sandelman Software Works
Email: mcr+ietf@sandelman.ca Email: mcr+ietf@sandelman.ca
Jacques Latour Jacques Latour
CIRA Labs CIRA Labs
Email: Jacques.Latour@cira.ca Email: Jacques.Latour@cira.ca
Faud Khan Audric Schiltkneckt
Twelve Dot Systems Viagenie
Email: faud.khan@twelvedot.com
Abhishek Joshi
Twelve Dot Systems
Email: abhishek.joshi@twelvedot.com Email: audric.schiltknecht@viagenie.ca
 End of changes. 30 change blocks. 
87 lines changed or deleted 149 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/