< draft-lear-eap-teap-brski-02.txt   draft-lear-eap-teap-brski-03.txt >
Network Working Group E. Lear Network Working Group E. Lear
Internet-Draft O. Friel Internet-Draft O. Friel
Intended status: Standards Track N. Cam-Winget Intended status: Standards Track N. Cam-Winget
Expires: August 26, 2019 Cisco Systems Expires: January 6, 2020 Cisco Systems
February 22, 2019 D. Harkins
HP Enterprise
July 05, 2019
Bootstrapping Key Infrastructure over EAP Bootstrapping Key Infrastructure over EAP
draft-lear-eap-teap-brski-02 draft-lear-eap-teap-brski-03
Abstract Abstract
In certain environments, in order for a device to establish any layer In certain environments, in order for a device to establish any layer
three communications, it is necessary for that device to be properly three communications, it is necessary for that device to be properly
credentialed. This is a relatively easy problem to solve when a credentialed. This is a relatively easy problem to solve when a
device is associated with a human being and has both input and device is associated with a human being and has both input and
display functions. It is less easy when the human, input, and display functions. It is less easy when the human, input, and
display functions are not present. To address this case, this memo display functions are not present. To address this case, this memo
specifies extensions to the Tunnel Extensible Authentication Protocol specifies extensions to the Tunnel Extensible Authentication Protocol
skipping to change at page 1, line 42 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 August 26, 2019. This Internet-Draft will expire on January 6, 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. TEAP BRSKI Architecture . . . . . . . . . . . . . . . . . . . 3 2. TEAP BRSKI Architecture . . . . . . . . . . . . . . . . . . . 4
3. BRSKI Bootstrap and Enroll Operation . . . . . . . . . . . . 4 3. BRSKI Bootstrap and Enroll Operation . . . . . . . . . . . . 4
3.1. Executing BRSKI in a TEAP Tunnel . . . . . . . . . . . . 5 3.1. Discovery of Trusted MASA . . . . . . . . . . . . . . . . 5
4. PKI Certificate Authority Considerations . . . . . . . . . . 8 3.2. Executing BRSKI in a TEAP Tunnel . . . . . . . . . . . . 5
4.1. TEAP Tunnel Establishment . . . . . . . . . . . . . . . . 8 4. PKI Certificate Considerations . . . . . . . . . . . . . . . 9
4.2. BRSKI Trust Establishment . . . . . . . . . . . . . . . . 9 4.1. TEAP Tunnel Establishment . . . . . . . . . . . . . . . . 9
5. Channel and Crypto Binding . . . . . . . . . . . . . . . . . 10 4.2. BRSKI Trust Establishment . . . . . . . . . . . . . . . . 11
6. Protocol Flows . . . . . . . . . . . . . . . . . . . . . . . 10 4.3. Certificate Expiration Times . . . . . . . . . . . . . . 12
6.1. TEAP Server Grants Access . . . . . . . . . . . . . . . . 10 5. Channel and Crypto Binding . . . . . . . . . . . . . . . . . 12
6.2. TEAP Server Instructs Client to Perform BRSKI Flow . . . 12 6. Protocol Flows . . . . . . . . . . . . . . . . . . . . . . . 12
6.3. TEAP Server Instructs Client to Reenroll . . . . . . . . 15 6.1. TEAP Server Grants Access . . . . . . . . . . . . . . . . 13
6.4. Out of Band Reenroll . . . . . . . . . . . . . . . . . . 17 6.2. TEAP Server Instructs Client to Perform BRSKI Flow . . . 14
7. TEAP TLV Formats . . . . . . . . . . . . . . . . . . . . . . 18 6.3. TEAP Server Instructs Client to Reenroll . . . . . . . . 18
7.1. BRSKI TLVs . . . . . . . . . . . . . . . . . . . . . . . 18 6.4. Out of Band Reenroll . . . . . . . . . . . . . . . . . . 20
7.1.1. BRSKI-RequestVoucher TLV . . . . . . . . . . . . . . 18 7. TEAP TLV Formats . . . . . . . . . . . . . . . . . . . . . . 20
7.1.2. BRSKI-Voucher TLV . . . . . . . . . . . . . . . . . . 19 7.1. BRSKI TLVs . . . . . . . . . . . . . . . . . . . . . . . 20
7.1.3. CSR-Attributes TLV . . . . . . . . . . . . . . . . . 19 7.1.1. BRSKI-RequestVoucher TLV . . . . . . . . . . . . . . 20
7.2. Existing TEAP TLV Specifications . . . . . . . . . . . . 20 7.1.2. BRSKI-Voucher TLV . . . . . . . . . . . . . . . . . . 21
7.2.1. PKCS#10 TLV . . . . . . . . . . . . . . . . . . . . . 20 7.1.3. CSR-Attributes TLV . . . . . . . . . . . . . . . . . 22
8. Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . 20 7.2. Existing TEAP TLV Specifications . . . . . . . . . . . . 22
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 7.2.1. PKCS#10 TLV . . . . . . . . . . . . . . . . . . . . . 22
10. Security Considerations . . . . . . . . . . . . . . . . . . . 21 7.3. TLV Rules . . . . . . . . . . . . . . . . . . . . . . . . 23
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 8. Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . 23
12. Informative References . . . . . . . . . . . . . . . . . . . 21 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
Appendix A. Changes from Earlier Versions . . . . . . . . . . . 22 10. Security Considerations . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 10.1. Issues with Provisionally Authenticated TEAP . . . . . . 24
10.2. Attack Against Discovery . . . . . . . . . . . . . . . . 25
10.3. TEAP Server as Registration Authority . . . . . . . . . 25
10.4. Trust of Registrar . . . . . . . . . . . . . . . . . . . 26
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26
12. Normative References . . . . . . . . . . . . . . . . . . . . 26
Appendix A. Changes from Earlier Versions . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
[I-D.ietf-anima-bootstrapping-keyinfra] (BRSKI) specifies a means to [I-D.ietf-anima-bootstrapping-keyinfra] (BRSKI) specifies a means to
provision credentials to be used as credentials to operationally provision credentials to be used as credentials to operationally
access networks. It was designed as a standalone means where some access networks. It was designed as a standalone means where some
limited access to an IP network is already available. This is not limited access to an IP network is already available. This is not
always the case. For example, IEEE 802.11 networks generally require always the case. For example, IEEE 802.11 networks generally require
authentication prior to any form of address assignment. While it is authentication prior to any form of address assignment. While it is
possible to assign an IP address to a device on some form of an open possible to assign an IP address to a device on some form of an open
skipping to change at page 3, line 43 skipping to change at page 4, line 8
in [I-D.ietf-anima-bootstrapping-keyinfra]. The term is also used in [I-D.ietf-anima-bootstrapping-keyinfra]. The term is also used
to refer to the flow described in that document. to refer to the flow described in that document.
o EST: Enrollment over Secure Transport, as defined in [RFC7030]. o EST: Enrollment over Secure Transport, as defined in [RFC7030].
o Voucher: a signed JSON object as defined in [RFC8366]. o Voucher: a signed JSON object as defined in [RFC8366].
2. TEAP BRSKI Architecture 2. TEAP BRSKI Architecture
The TEAP BRSKI architecture is illustrated in Section 3. The device The TEAP BRSKI architecture is illustrated in Section 3. The device
talks to the TEAP server via the Authenticator as per any normal EAP talks to the TEAP server via the Authenticator using any compliant
exchange. There is no need for an inner EAP method server, and there transport such as [IEEE8021X]. The architecture illustrated shows an
is no explicit EAP method type defined for BRSKI. Authenticator distinct from the TEAP server. This is a deployment
optimization and when so deployed the communication between
Authenticator and TEAP server is a AAA protocol such as RADIUS or
DIAMETER.
The architecture illustrated shows the TEAP server and registrar The architecture illustrated shows a co-located TEAP server and BRSKI
function as being two logically separate entities, however the BRSKI registrar. Not only are these two functions co-located, they MUST be
registrar functionality may be integrated into the TEAP server. The the same entity. This ensures that the entity identified in the
device is not explicitly aware of where the registrar functionality device's voucher request (the TEAP server) is the same entity that
is deployed when executing BRSKI inside a TEAP tunnel. Note that the signs the voucher request (the registrar).
device may connect directly to the registrar for the purposes of
certificate reenrollment, but this happens outside the context to
801.1X and TEAP authentication.
The registrar in turn communicates with the BRSKI MASA service for The registrar communicates with the BRSKI MASA service for the
the purposes of getting signed vouchers. [[TODO: I guess we should purposes of getting signed vouchers.
mention TEAP server talking to vendor default registrar in the
cloud]]
The registrar also comunicates with a Certificate Authority in order The registrar also communicates with a Certificate Authority in order
to issue LDevIDs. The architecture shows the registrar and CA as to issue LDevIDs. The architecture shows the registrar and CA as
being two logically separate entities, however the CA may be being two logically separate entities, however the CA may be
integrated into the registrar. The device is not explicitly aware of integrated into the registrar. The device is not explicitly aware of
whether the CA and registrar functions are integrated. whether the CA and registrar functions are integrated.
+--------+ +---------+ +--------+ +---------+ +------+ +--------+ +---------+ +---------+ +------+
| | | | | | | |<--->| MASA | | | | | | TEAP |<--->| MASA |
| | | Authen- | | TEAP | | BRSKI | +------+ | | | Authen- | | server | +------+
| Device |<--->| ticator |<--->| server |<--->|Registrar| | Device |<--->| ticator |<--->| |
| | | | | | | | +------+ | | | | | BRSKI | +------+
| | | | | | | |<--->| CA | | | | | |Registrar|<--->| CA |
+--------+ +---------+ +--------+ +---------+ +------+ +--------+ +---------+ +---------+ +------+
3. BRSKI Bootstrap and Enroll Operation 3. BRSKI Bootstrap and Enroll Operation
This section summarises the current BRSKI operation. The BRSKI flow This section summarises the current BRSKI operation. The BRSKI flow
assumes the device has an IDevID and has a manufacturer installed assumes the device has an IDevID and has a manufacturer installed
trust anchor that can be used to validate the BRSKI voucher. The trust anchor that can be used to validate the BRSKI voucher. The
BRSKI flow compromises serveral main steps from the perspective of BRSKI flow compromises serveral main steps from the perspective of
the device: the device:
o Step 1: Device discovers the registrar o Step 1: Device discovers the registrar
skipping to change at page 4, line 47 skipping to change at page 5, line 10
o Step 2: Device establishes provisional TLS connection to registrar o Step 2: Device establishes provisional TLS connection to registrar
o Step 3: Device sends voucher request message and receives signed o Step 3: Device sends voucher request message and receives signed
voucher response voucher response
o Step 4: Device validates voucher and validates provisional TLS o Step 4: Device validates voucher and validates provisional TLS
connection to registrar connection to registrar
o Step 5: Device downloads additional local domain CA information o Step 5: Device downloads additional local domain CA information
o Step 6: Device downloads Certificate Signing Reqeust (CSR) o Step 6: Device downloads Certificate Signing Request (CSR)
attributes attributes
o Step 7: Device does an EST enroll to obtain an LDevID o Step 7: Device does a certificate enroll to obtain an LDevID
o Step 8: Device periodically reenrolls via EST to refresh its o Step 8: Device periodically reenrolls via EST to refresh its
LDevID LDevID
Most of the operational steps require the device, and thus its Most of the operational steps require the device, and thus its
internal state machine, to automatically complete the next step internal state machine, to automatically complete the next step
without being explicitly instructed to do so by the registrar. For without being explicitly instructed to do so by the registrar. For
example, the registrar does not explicitly tell the device to example, the registrar does not explicitly tell the device to
download additional local domain CA information, or to do an EST download additional local domain CA information, or to do an EST
enroll to obtain an LDevID. enroll to obtain an LDevID.
3.1. Executing BRSKI in a TEAP Tunnel 3.1. Discovery of Trusted MASA
BRSKI section 2.8 outlines how the Registrar discovers the correct
MASA to connect with. BRSKI section 5.3 outlines how the Registrar
can make policy decisions about which devices to trust.
Similar approaches are applicable for TEAP servers executing BRSKI.
For example, the TEAP server may be configured with a list of trusted
manufacturing CAs. During device bootstrap, only devices with an
IDevID signed by a trusted manufacturing CA may be allowed to
etablishes a TLS connection with the TEAP server, and the TEAP server
could then extract the MASA URI from the device's IDevID.
3.2. Executing BRSKI in a TEAP Tunnel
This section outlines how the main BRSKI steps outlined above map to This section outlines how the main BRSKI steps outlined above map to
TEAP, and how BRSKI and enrollment can be accomplished inside a TEAP TEAP, and how BRSKI and enrollment can be accomplished inside a TEAP
TLS tunnel. The following new TEAP TLVs are introduced: TLS tunnel. The following new TEAP TLVs are introduced:
o BRSKI-VoucherRequest o BRSKI-VoucherRequest
o BRSKI-Voucher o BRSKI-Voucher
o CSR-Attributes o CSR-Attributes
skipping to change at page 5, line 40 skipping to change at page 6, line 14
When BRSKI is executed in a TEAP tunnel, the device exchanges BRSKI When BRSKI is executed in a TEAP tunnel, the device exchanges BRSKI
TLVs with the TEAP server. The discovery process for devices is TLVs with the TEAP server. The discovery process for devices is
therefore the standard wired or wireless LAN EAP server discovery therefore the standard wired or wireless LAN EAP server discovery
process. The discovery processes outlined in section 4 of process. The discovery processes outlined in section 4 of
[I-D.ietf-anima-bootstrapping-keyinfra] are not required for initial [I-D.ietf-anima-bootstrapping-keyinfra] are not required for initial
discovery of the registrar. discovery of the registrar.
o Step 2: Device establishes provisional TLS connection to registrar o Step 2: Device establishes provisional TLS connection to registrar
The device establishes an outer TEAP tunnel with the TEAP server and The device establishes an outer TEAP tunnel with the TEAP server and
does not validate the server certificate. Similarly, at this does not validate the server certificate. The device presents its
provisioning stage, the server does not validate the certificate of LDevID as its identity certificate if it has a valid LDevID,
the device. The device presents its LDevID as its identity otherwise it presents its IDevID. The TEAP server validates the
certificate if it has a valid LDevID, otherwise it presents its device's certificate using its implicit or explicit trust anchor
IDevID. Server policy may also be used to control which certificate database. If the device presents an IDevID it is verified against a
the device is allowed present, as described in section Section 4. database of trusted manufacturer certificates. Server policy may
also be used to control which certificate the device is allowed
present, as described in section {pki-certificate-authority-
considerations}.
If the presented credential is sufficient to grant access, the TEAP If the presented credential is sufficient to grant access, the TEAP
server can return an EAP-Success immediately. The device may still server can return a TEAP Result TLV indicating success immediately.
send a BRSKI-RequestVoucher TLV in response to the EAP-Success if it The device may still send a Request-Action TLV including a BRSKI-
does not have, but requires, trust anchors for validating the TEAP VoucherRequest TLV in response to the TEAP Result TLV if it does not
server certificate. have, but requires, provisioning of trust anchors for validating the
TEAP server certificate. Note that no inner EAP method is required
for this, only an exchange of TEAP TLVs.
If the TEAP server requires that the device execute a BRSKI flow, it [todo] Question: as the device wants the server to reply with a
sends a Request-Action TLV that includes a BRSKI-VoucherRequest TLV. BRSKI-Voucher TLV, does it really send a Request-Action TLV
For example, if the device presented its IDevID but the TEAP server containing a BRSKI-VoucherRequest TLV, or does it send a Request-
requires an LDevID. Action TLV containing a BRSKI-Voucher TLV?? The TEAP draft is a bit
ambiguous here. Normally, if one end sends a Request-Action
including XXX-TLV, it means it wants the far end ot send an XXX-
TLV...
[todo] Question: general TEAP protocol question: does the device have
to send a Request-Action w/BRSKI-VoucherRequest or can it send a
BRSKI-VoucherRequest on its own? I'm not clear on this.
If the TEAP server requires that the device execute a BRSKI flow, the
server sends a Request-Action TLV that includes a BRSKI-
VoucherRequest TLV. For example, if the device presented its IDevID
but the TEAP server requires an LDevID.
[todo] Question: to nit pick, the server should send a Request-Action
TLV including a PKCS#10 TLV to tell the client to enroll. How does
the server really know that the client has the correct trust
established (as previously received by a BRSKI-Voucher)? If the
client sends an IDevID, does server always send a Request-Action
including both BRSKI-VoucherRequest and PKCS#10 TLVs? Whats the
client behaviour? I assume client can spontaneously send BRSKI-
VoucherRequest and/or PCSK#10 without being explicitly instructed to.
Just need to get the language correct here.
The TEAP server may also require the device to reenroll, for example, The TEAP server may also require the device to reenroll, for example,
if the device presented a valid LDevID that is very closed to if the device presented a valid LDevID that is very closed to
expiration. The server may instruct a device to reenroll by sending expiration. The server may instruct a device to reenroll by sending
a Request-Action TLV that includes a zero byte length PKCS#10 TLV. a Request-Action TLV that includes a zero byte length PKCS#10 TLV.
o Step 3: Device sends voucher request message and receives signed o Step 3: Device sends voucher request message and receives signed
voucher response voucher response
The device sends a BRSKI-RequestVoucher TLV to the TEAP server. The The device sends a BRSKI-RequestVoucher TLV to the TEAP server. The
skipping to change at page 6, line 38 skipping to change at page 7, line 39
a particular registrar. In this sense, success indicates that the a particular registrar. In this sense, success indicates that the
device is on the correct network, while failure indicates the device device is on the correct network, while failure indicates the device
should try to provision itself within wireless networks (e.g, go to should try to provision itself within wireless networks (e.g, go to
the next SSID). the next SSID).
o Step 4: Device validates voucher and validates provisional TLS o Step 4: Device validates voucher and validates provisional TLS
connection to registrar connection to registrar
The device validates the signed voucher using its manufacturer The device validates the signed voucher using its manufacturer
installed trust anchor, and uses the CA information in the voucher to installed trust anchor, and uses the CA information in the voucher to
validate the outer TEAP TLS connection to the TEAP server. validate the TLS connection to the TEAP server.
If the device fails to validate the voucher, or fails to validate the If the device fails to validate the voucher, then it sends a TEAP-
outer TEAP TLS connection, then it sends a TEAP-Error TLV indicating Error TLV indicating failiure to the TEAP server.
failure to the TEAP server.
Similarly, if the device validates the voucher, but fails to validate
the provisional TLS connection, then it sends a TEAP-Error TLV
indicating failure to the TEAP server. Note that the outer TLS
tunnel has already been established, thus allowing the client to send
a TEAP-Error TLV to the server inside that tunnel to indicate that it
failed to verify the provisionally accepted outer TLS tunnel server
identity.
o Step 5: Device downloads additional local domain CA information o Step 5: Device downloads additional local domain CA information
On completion of the BRSKI flow, the device SHOULD send a Trusted- On completion of the BRSKI flow, the device SHOULD send a Trusted-
Server-Root TLV to the TEAP server in order to discover additional Server-Root TLV to the TEAP server in order to discover additional
local domain CAs. local domain CAs. This is equivalent to section [todo] from
[I-D.ietf-anima-bootstrapping-keyinfra].
o Step 6: Device downloads CSR attributes o Step 6: Device downloads CSR attributes
No later than the completion of step 5, server MUST send a CSR- No later than the completion of step 5, server MUST send a CSR-
Attributes TLV to peer server in order to discover the correct fields Attributes TLV to peer server in order to discover the correct fields
to include when it enrolls to get an LDevID. to include when it enrolls to get an LDevID.
o Step 7: Device does an EST enroll to obtain an LDevID o Step 7: Device does a certificate enroll to obtain an LDevID
When executing the BRSKI flow inside a TEAP tunnel, the device does When executing the BRSKI flow inside a TEAP tunnel, the device does
not directly leverage EST when doing its initial enroll. Instead, not directly leverage EST when doing its initial enroll. Instead,
the device uses the existing TEAP PKCS#10 and PCKS#7 TEAP mechanisms. the device uses the existing TEAP PKCS#10 and PCKS#7 TEAP mechanisms.
Once the BRSKI flow is complete, the device can now send a PKCS#10 Once the BRSKI flow is complete, the device can now send a PKCS#10
TLV to enroll and request an LDevID. If the TEAP server instructed TLV to enroll and request an LDevID. If the TEAP server instructed
the device to start the BRSKI flow via a Request-Action TLV that the device to start the BRSKI flow via a Request-Action TLV that
includes a BRSKI-RequestVoucher TLV, then the device MUST send a includes a BRSKI-RequestVoucher TLV, then the device MUST send a
PKCS#10 in order to start the enroll process. The TEAP server will PKCS#10 in order to start the enroll process. The TEAP server will
skipping to change at page 7, line 41 skipping to change at page 8, line 51
When a device's LDevID is close to expiration, there are two options When a device's LDevID is close to expiration, there are two options
for re-enrollment in order to obtain a fresh LDevID. As outlined in for re-enrollment in order to obtain a fresh LDevID. As outlined in
Step 2 above, the TEAP server may instruct the device to reenroll by Step 2 above, the TEAP server may instruct the device to reenroll by
sending a Request-Action TLV including a PKCS#10 TLV. If the TEAP sending a Request-Action TLV including a PKCS#10 TLV. If the TEAP
server explicilty instructs the device to reenroll via these TLV server explicilty instructs the device to reenroll via these TLV
exchange, then the device MUST send a PKCS#10 to reenroll and request exchange, then the device MUST send a PKCS#10 to reenroll and request
a fresh LDevID. a fresh LDevID.
However, the device SHOULD reenroll if it determines that its LDevID However, the device SHOULD reenroll if it determines that its LDevID
is close to expiration wihtout waiting for explicit instruction from is close to expiration without waiting for explicit instruction from
the TEAP server. There are two options to do this. the TEAP server. There are two options to do this.
Option 1: The device reenrolls for a new LDevID directly with the EST Option 1: The device reenrolls for a new LDevID directly with the EST
CA outside the context of the 802.1X TEAP flow. The device uses the CA outside the context of the 802.1X TEAP flow. The device uses the
registrar discovery mechanisms oulined in registrar discovery mechanisms oulined in
[I-D.ietf-anima-bootstrapping-keyinfra] to discover the registrar and [I-D.ietf-anima-bootstrapping-keyinfra] to discover the registrar and
the device sends the EST reenroll messages to the discovered the device sends the EST reenroll messages to the discovered
registrar endpoint. No new TEAP TLVs are defined to facilitate registrar endpoint. No new TEAP TLVs are defined to facilitate
discover of the registrar or EST endpoints inside the context of the discover of the registrar or EST endpoints inside the context of the
TEAP tunnel. TEAP tunnel.
Option 2: When the device is performing a periodic 802.1X Option 2: When the device is performing a periodic 802.1X
authentication using its current LDevID, it reenrolls for a new authentication using its current LDevID, it reenrolls for a new
LDevID by sending a PKCS#10 TLV inside the TEAP TLS tunnel. LDevID by sending a PKCS#10 TLV inside the TEAP TLS tunnel.
4. PKI Certificate Authority Considerations 4. PKI Certificate Considerations
Careful consideration must be given to PKI certificate authority Careful consideration must be given to PKI certificate authority
handling when: handling when:
o Establishing the TEAP tunnel o Establishing the TEAP tunnel
o Establishing trust using BRSKI o Establishing trust using BRSKI
Additionally, consideration must be given to IDevID and LDevID
expiration times.
These are described in more detail here. These are described in more detail here.
4.1. TEAP Tunnel Establishment 4.1. TEAP Tunnel Establishment
Because this method establishes a client identity, and for purposes Because this method establishes a client identity, and for purposes
of partioning of responsibility, the peer uses a generic identity of partioning of responsibility, the peer uses a generic identity
string of teap-brsk@TBD1 as its network access identifier (NAI). string of teap-brsk@TBD1 as its network access identifier (NAI).
The client sends its ClientHello to initiate TLS tunnel BRSKI section 5.3 outlines the policy decisions a Registrar may make
establishment. It is possible for the TEAP server to restrict the when deciding whether to accept connections from clients. Similarly,
the TEAP server operator may configure a set of trusted CAs for
validating incoming TLS connections from clients. The operator may
want to 'allow any device from a specific vendor', or from a set of
vendors, to access the network. Network operators may do this by
restricting network access to clients that have a certificate signed
by one of a small set of trusted manufacturer/supplier CAs.
When the client sends its ClientHello to initiate TLS tunnel
establishment, it is possible for the TEAP server to restrict the
certificates that the client can use for tunnel establishment by certificates that the client can use for tunnel establishment by
including a list of CA distinguished names in the including a list of CA distinguished names in the
certificate_authorities field in the CertificateRequest message. certificate_authorities field in the CertificateRequest message. The
Network operators may want to do this in order to restrict netwok client should only continue with the handshake if it has a
access to clients that have a certificate signed by one of a small certificate signed by one of the indicated CAs.
set of trusted manufacturer/supplier CAs. If the client has both an
IDevID and an LDevID, the client should present the LDevID in
preference to its IDevID if allowed by server policy.
In practice, network operators will likely want to onboard devices In practice, network operators will likely want to onboard devices
from a large number of device manufacturers, with each manufacturer from a large number of device manufacturers, with each manufacturer
using a different root CA when issuing IDevIDs. If the number of using a different root CA when issuing IDevIDs. If the number of
different manufacturer root CAs is large, this could result in very different manufacturer root CAs is large, this could result in very
large TLS handshake messages. Operators may prefer to include no CAs large TLS handshake messages. Therefore, the TEAP server may send a
in the certificate_authorities field thus allowing devices to present CertificateRequest message and not specify any
IDevIDs signed by any CA when establishing the TEAP tunnel, and certificate_authorities, thus allowing the client present a
instead enforce policy at LDevID enrollment time. certificate signed by any authority in its Certificate message.
If the client has both an IDevID and an LDevID, the client should
present the LDevID in preference to its IDevID, if allowed by server
policy.
Once the client has sent its TLS Finished message, the TEAP server
can make a policy decision, based on the CA used to sign the client's
certificate, on whether to establish the outer TLS tunnel or not.
The TEAP server may delegate policy decisions to the MASA or CA
function. For example, the TEAP server may declare EAP success and
grant network access if the client presents a valid LDevID signed by
a trusted domain CA. However, if the client presents an IDevID
signed by a trusted manufacturer CA, the TEAP server may establish
the TLS tunnel but not declare EAP success and grant network access
until the client successfully completes a BRSKI Voucher exchange and
PKCS#10/PKCS#7 exchange inside that tunnel.
It is recommended that the client validate the certificate presented It is recommended that the client validate the certificate presented
by the server in the server's Certificate message, but this may not by the server in the server's Certificate message, but this may not
be possible for clients that have not yet provisioned appropriate be possible for clients that have not yet provisioned appropriate
trust anchors. If the client is in the provisioning phase and has trust anchors. If the client is in the provisioning phase and has
not yet completed a BRSKI flow, it will not have trust anchors not yet completed a BRSKI flow, it will not have trust anchors
installed yet, and thus will not be able to validate the server's installed yet, and thus will not be able to validate the server's
certificate. The client must however note the certificate presented certificate. The client must however note the certificate presented
by the server for (i) inclusion in the BRSKI-RequestVoucher TLV and by the server for (i) inclusion in the BRSKI-RequestVoucher TLV and
for (ii) validation once the client has discovered the local domain for (ii) validation once the client has discovered the local domain
trust anchors. trust anchors.
If the client does not present a suitable certificate to the server, If the client does not present a suitable certificate to the server,
the server MUST terminate the connection and fail the EAP request. the server MUST terminate the connection and fail the EAP request.
If the TEAP server is unable to validate the client's certificate
using its implicit or explicit trust anchor database it MUST fail the
EAP request.
On establishment of the outer TLS tunnel, the TEAP server will make a On establishment of the outer TLS tunnel, the TEAP server will make a
policy decision on next steps. Possible policy decisions include: policy decision on next steps. Possible policy decisions include:
o Option 1: Server grants client full network access and returns o Option 1: Server grants client full network access and returns
EAP-Success. This will typically happen when the client presents EAP-Success. This will typically happen when the client presents
a valid LDevID. Network policy may grant client network access a valid LDevID. Network policy may grant client network access
based on IDevID without requiring the device to enroll to obtain based on IDevID without requiring the device to enroll to obtain
an LDevID. an LDevID.
skipping to change at page 10, line 22 skipping to change at page 12, line 11
signature using its built in trust anchor list, and extracts the signature using its built in trust anchor list, and extracts the
pinned-domain-cert field. The client must use the CA included in the pinned-domain-cert field. The client must use the CA included in the
pinned-domain-cert to validate the certificate that was presented by pinned-domain-cert to validate the certificate that was presented by
the server when establishing the outer TLS tunnel. If this the server when establishing the outer TLS tunnel. If this
certificate validation fails, the client must fail the TEAP request certificate validation fails, the client must fail the TEAP request
and not connect to the network. and not connect to the network.
[TBD- based on client responses, the registrar sends a status update [TBD- based on client responses, the registrar sends a status update
to the MASA] to the MASA]
4.3. Certificate Expiration Times
[IEEE8021AR] section 7.2.7.2 states:
notAfter: The latest time a DevID is expected to be used. Devices
possessing an IDevID are expected to operate indefinitely into the
future and should use the value 99991231235959Z. Solutions
verifying an IDevID are expected to accept this value
indefinitely.
TEAP servers SHOULD follow the 802.1AR standard when validating
IDevIDs.
TEAP servers SHOULD reject LDevIDs with expired certificates and
SHOULD NOT allow clients to connect with recently expired LDevIDs.
If a client presents a recently expired LDevID it SHOULD be forced to
authenticate using its IDevID and then reenroll to obtain a valid
LDevID.
5. Channel and Crypto Binding 5. Channel and Crypto Binding
As the TEAP BRSKI flow does not define or require an inner EAP As the TEAP BRSKI flow does not define or require an inner EAP
method, there is no explicit need for exchange of Channel-Binding method, there is no explicit need for exchange of Channel-Binding
TLVs between the device and the TEAP server. TLVs between the device and the TEAP server.
The TEAP BRSKI TLVs are expected to occur at the beginning of the The TEAP BRSKI TLVs are expected to occur at the beginning of the
TEAP Phase 2 and MUST occur before the final Crypto-Binding TLV. TEAP Phase 2 and MUST occur before the final Crypto-Binding TLV.
This draft does not exclude the possibility of having other EAP This draft does not exclude the possibility of having other EAP
methods occur following the TEAP BRSKI TLVs and as such, the Crypto- methods occur following the TEAP BRSKI TLVs and as such, the Crypto-
Binding TLV process rules as defined in [RFC7170] apply. Binding TLV process rules as defined in [RFC7170] apply.
6. Protocol Flows 6. Protocol Flows
This section outlines protocol flows that map to the 3 server policy This section outlines protocol flows that map to the three server
options described in section Section 4.1. The protocol flows policy options described in section Section 4.1. The protocol flows
illustrate a TLS1.2 exchange. Pertinent notes are outlined in the illustrate a TLS1.2 exchange. Pertinent notes are outlined in the
protocol flows. protocol flows.
6.1. TEAP Server Grants Access 6.1. TEAP Server Grants Access
In this flow, the server grants access as server policy allows the In this flow, the server grants access as server policy allows the
client to access the network based on the identity certificate that client to access the network based on the identity certificate that
the client presented. This means that either (i) the client has the client presented. This means that either (i) the client has
previously completed BRSKI and has presented a valid LDevID or (ii) previously completed BRSKI and has presented a valid LDevID or (ii)
the client presents an IDevID and network policy allows access based the client presents an IDevID and network policy allows access based
purely on IDevID. purely on IDevID.
+--------+ +-------------+ +------+ +----------------+
| Client | | TEAP-Server | | MASA | +--------+ | Authenticator/ | +------+
+--------+ +-------------+ +------+ | Client | | TEAP-Server | | MASA |
+--------+ +----------------+ +------+
| EAP-Request/ | | | EAP-Request/ | |
| Type=Identity | | | Type=Identity | |
|<------------------------| | |<------------------------| |
| | | | | |
| EAP-Response/ | | | EAP-Response/ | |
| Type=Identity | | | Type=Identity | |
|------------------------>| | |------------------------>| |
| | | | | |
| EAP-Request/ | | | EAP-Request/ | |
| Type=TEAP, | | | Type=TEAP, | |
skipping to change at page 12, line 35 skipping to change at page 14, line 46
certificates that the device is allowed present. certificates that the device is allowed present.
(3) The device will present its LDevID, if it has one, in preference (3) The device will present its LDevID, if it has one, in preference
to its IDevID, if allowed by server policy. to its IDevID, if allowed by server policy.
6.2. TEAP Server Instructs Client to Perform BRSKI Flow 6.2. TEAP Server Instructs Client to Perform BRSKI Flow
In this flow, the server instructs the client to perform a BRSKI flow In this flow, the server instructs the client to perform a BRSKI flow
by exchanging TLVs once the outer TLS tunnel is established. by exchanging TLVs once the outer TLS tunnel is established.
+--------+ +-------------+ +------+ +----------------+
| Client | | TEAP-Server | | MASA | +--------+ | Authenticator/ | +------+ +----+
+--------+ +-------------+ +------+ | Client | | TEAP-Server | | MASA | | CA |
| EAP-Request/ | | +--------+ +----------------+ +------+ +----+
| Type=Identity | | | EAP-Request/ | | |
|<----------------------------| | | Type=Identity | | |
| | | |<----------------------------| | |
| EAP-Response/ | | | | | |
| Type=Identity | | | EAP-Response/ | | |
|---------------------------->| | | Type=Identity | | |
| | | |---------------------------->| | |
| EAP-Request/ | | | | | |
| Type=TEAP, | | | EAP-Request/ | | |
| TEAP Start, | | | Type=TEAP, | | |
| Authority-ID TLV | | | TEAP Start, | | |
|<----------------------------| | | Authority-ID TLV | | |
| | | |<----------------------------| | |
| EAP-Response/ | | | | | |
| Type=TEAP, | | | EAP-Response/ | | |
| TLS(ClientHello) | | | Type=TEAP, | | |
|---------------------------->| | | TLS(ClientHello) | | |
| | | |---------------------------->| | |
| EAP-Request/ | | | | | |
| Type=TEAP, | | | EAP-Request/ | | |
| TLS(ServerHello, | | | Type=TEAP, | | |
(1)| Certificate, | | | TLS(ServerHello, | | |
| ServerKeyExchange, | | (1)| Certificate, | | |
| CertificateRequest, | | | ServerKeyExchange, | | |
| ServerHelloDone) | | | CertificateRequest, | | |
|<----------------------------| | | ServerHelloDone) | | |
| | | |<----------------------------| | |
| EAP-Response/ | | | | | |
| Type=TEAP, | | | EAP-Response/ | | |
| TLS(Certificate | | | Type=TEAP, | | |
| ClientKeyExchange, | | | TLS(Certificate | | |
| CertificateVerify, | | | ClientKeyExchange, | | |
| ChangeCipherSpec, | | | CertificateVerify, | | |
| Finished) | | | ChangeCipherSpec, | | |
|---------------------------->| | | Finished) | | |
| | | |---------------------------->| | |
| EAP-Request/ | | | | | |
| Type=TEAP, | | | EAP-Request/ | | |
| TLS(ChangeCipherSpec, | | | Type=TEAP, | | |
| Finished), | | | TLS(ChangeCipherSpec, | | |
| {Crypto-Binding TLV, | | | Finished), | | |
| Result TLV=Success} | | | {Crypto-Binding TLV, | | |
|<----------------------------| | | Result TLV=Success} | | |
| | | |<----------------------------| | |
| EAP-Response/ | | | | | |
| Type=TEAP, | | | EAP-Response/ | | |
| {Crypto-Binding TLV, | | | Type=TEAP, | | |
| Result TLV=Success} | | | {Crypto-Binding TLV, | | |
|---------------------------->| | | Result TLV=Success} | | |
| | | |---------------------------->| | |
| | | |
** At this stage the outer TLS tunnel is established ** ** At this stage the outer TLS tunnel is established **
** The following message exchanges are for BRSKI ** ** The following message exchanges are for BRSKI **
| | | | | | |
| EAP-Request/ | | | EAP-Request/ | | |
| Type=TEAP, | | | Type=TEAP, | | |
(2)| {Request-Action TLV: | | (2)| {Request-Action TLV: | | |
| Status=Failure, | | | Status=Failure, | | |
| Action=Process-TLV, | | | Action=Process-TLV, | | |
| TLV=Request-Voucher, | | | TLV=Request-Voucher, | | |
| TLV=Trusted-Server-Root,| | | TLV=Trusted-Server-Root,| | |
| TLV=CSR-Attributes, | | | TLV=CSR-Attributes, | | |
| TLV=PKCS#10} | | | TLV=PKCS#10} | | |
|<----------------------------| | |<----------------------------| | |
| | | | | | |
| EAP-Response/ | | | EAP-Response/ | | |
| Type=TEAP, | | | Type=TEAP, | | |
(3)| {Request-Voucher TLV} | | (3)| {Request-Voucher TLV} | | |
|---------------------------->| RequestVoucher | |---------------------------->| RequestVoucher | |
| |--------------->| | |--------------->| |
| | Voucher | | | Voucher | |
| |<---------------| | |<---------------| |
| EAP-Request/ | | | EAP-Request/ | | |
| Type=TEAP, | | | Type=TEAP, | | |
(4)| {Voucher TLV} | | (4)| {Voucher TLV} | | |
|<----------------------------| | |<----------------------------| | |
| | | | | | |
| EAP-Response/ | | | EAP-Response/ | | |
| Type=TEAP, | | | Type=TEAP, | | |
(5)| {Trusted-Server-Root TLV} | | (5)| {Trusted-Server-Root TLV} | | |
|---------------------------->| | |---------------------------->| | |
| | | | | | |
| EAP-Request/ | | | EAP-Request/ | | |
| Type=TEAP, | | | Type=TEAP, | | |
| {Trusted-Server-Root TLV} | | | {Trusted-Server-Root TLV} | | |
|<----------------------------| | |<----------------------------| | |
| | | | | | |
| EAP-Response/ | | | EAP-Response/ | | |
| Type=TEAP, | | | Type=TEAP, | | |
| {CSR-Attributes TLV} | | | {CSR-Attributes TLV} | | |
|---------------------------->| | |---------------------------->| | |
| | | | | | |
| EAP-Request/ | | | EAP-Request/ | | |
| Type=TEAP, | | | Type=TEAP, | | |
| {CSR-Attributes TLV} | | | {CSR-Attributes TLV} | | |
|<----------------------------| | |<----------------------------| | |
| | | | | | |
| EAP-Response/ | | | EAP-Response/ | | |
| Type=TEAP, | | | Type=TEAP, | | |
| {PKCS#10 TLV} | | | {PKCS#10 TLV} | | |
|---------------------------->| | |---------------------------->| | |
| | | | | PKCS#10 | |
| EAP-Request/ | | | EAP-Request/ |--------------/ | \----->|
| Type=TEAP, | | | Type=TEAP, | | |
| {PKCS#7 TLV, | | | {PKCS#7 TLV, | PKCS#7 | |
(6)| Result TLV=Success} | | (6)| Result TLV=Success} |<-------------/ | \------|
|<----------------------------| | |<----------------------------| | |
| | | | | | |
| EAP-Response/ | | | EAP-Response/ | | |
| Type=TEAP, | | | Type=TEAP, | | |
| {Result TLV=Success} | | | {Result TLV=Success} | | |
|---------------------------->| | |---------------------------->| | |
| | | | | | |
| EAP-Success | | | EAP-Success | | |
|<----------------------------| | |<----------------------------| | |
Figure 2: TEAP Server Instructs Client to Perform BRSKI Flow Figure 2: TEAP Server Instructs Client to Perform BRSKI Flow
Notes: Notes:
(1) If the client has not yet completed the BRSKI flow, then it (1) If the client has not yet completed the BRSKI flow, then it
provisionally accepts the server certificate and must validate it provisionally accepts the server certificate and must validate it
later once BRSKI is complete. later once BRSKI is complete. The server validates the client
certificate using its trust anchor database.
(2) The server instructs the client to start the BRSKI flow by (2) The server instructs the client to start the BRSKI flow by
sending a Request-Action TLV that includes a BRSKI-RequestVoucher sending a Request-Action TLV that includes a BRSKI-RequestVoucher
TLV. The server also instructs the client to request trust anchors, TLV. The server also instructs the client to request trust anchors,
to request CSR Attrites, and to initiate a PKCS certificate to request CSR Attrites, and to initiate a PKCS certificate
enrolment. As outlined in [RFC7170], the Request-Action TLV is sent enrolment. As outlined in [RFC7170], the Request-Action TLV is sent
after the Crypto-Binding TLV and Result TLV exchange. after the Crypto-Binding TLV and Result TLV exchange.
(3) The client includes the certificate it received from the server (3) The client includes the certificate it received from the server
in the RequestVoucher message. in the RequestVoucher message.
(4) Once the client receives and validates the voucher signed by the (4) Once the client receives and validates the voucher signed by the
MASA, it must verify the certificate it previously received from the MASA, it must verify the certificate it previously received from the
server. server.
(5) As outlined in [RFC7170], the Trusted-Server-Root TLV is (5) As outlined in [RFC7170], the Trusted-Server-Root TLV is
exchanged after the Crypto-Binding TLV exchange, and after the client exchanged after the Crypto-Binding TLV exchange, and after the client
has used the Voucher to authenticate the TEAP server identity. has used the Voucher to authenticate the TEAP server identity. This
is equivalent to section [todo] from
[I-D.ietf-anima-bootstrapping-keyinfra].
(6) There is not need for an additional Crypto-Binding TLV exchange (6) There is no need for an additional Crypto-Binding TLV exchange as
as there is no inner EAP method. All BRSKI exchanges are simply TLVs there is no inner EAP method. All BRSKI exchanges are simply TLVs
exchanged inside the outer TLS tunnel. exchanged inside the outer TLS tunnel.
6.3. TEAP Server Instructs Client to Reenroll 6.3. TEAP Server Instructs Client to Reenroll
In this flow, the server instructs the client to reenroll and get a In this flow, the server instructs the client to reenroll and get a
new LDevID by exchanging TLVs once the outer TLS tunnel is new LDevID by exchanging TLVs once the outer TLS tunnel is
established. established.
+--------+ +-------------+ +------+ +----------------+
| Client | | TEAP-Server | | MASA | +--------+ | Authenticator/ | +------+ +----+
+--------+ +-------------+ +------+ | Client | | TEAP-Server | | MASA | | CA |
| EAP-Request/ | | +--------+ +----------------+ +------+ +----+
| Type=Identity | | | EAP-Request/ | | |
|<------------------------| | | Type=Identity | | |
| | | |<------------------------| | |
| EAP-Response/ | | | | | |
| Type=Identity | | | EAP-Response/ | | |
|------------------------>| | | Type=Identity | | |
| | | |------------------------>| | |
| EAP-Request/ | | | | | |
| Type=TEAP, | | | EAP-Request/ | | |
| TEAP Start, | | | Type=TEAP, | | |
| Authority-ID TLV | | | TEAP Start, | | |
|<------------------------| | | Authority-ID TLV | | |
| | | |<------------------------| | |
| EAP-Response/ | | | | | |
| Type=TEAP, | | | EAP-Response/ | | |
| TLS(ClientHello) | | | Type=TEAP, | | |
|------------------------>| | | TLS(ClientHello) | | |
| | | |------------------------>| | |
| EAP-Request/ | | | | | |
| Type=TEAP, | | | EAP-Request/ | | |
| TLS(ServerHello, | | | Type=TEAP, | | |
| Certificate, | | | TLS(ServerHello, | | |
| ServerKeyExchange, | | | Certificate, | | |
| CertificateRequest, | | | ServerKeyExchange, | | |
| ServerHelloDone) | | | CertificateRequest, | | |
|<------------------------| | | ServerHelloDone) | | |
| | | |<------------------------| | |
| EAP-Response/ | | | | | |
| Type=TEAP, | | | EAP-Response/ | | |
| TLS(Certificate, | | | Type=TEAP, | | |
| ClientKeyExchange, | | | TLS(Certificate, | | |
| CertificateVerify, | | | ClientKeyExchange, | | |
| ChangeCipherSpec, | | | CertificateVerify, | | |
| Finished) | | | ChangeCipherSpec, | | |
|------------------------>| | | Finished) | | |
| | | |------------------------>| | |
| EAP-Request/ | | | | | |
| Type=TEAP, | | | EAP-Request/ | | |
| TLS(ChangeCipherSpec, | | | Type=TEAP, | | |
| Finished), | | | TLS(ChangeCipherSpec, | | |
| {Crypto-Binding TLV, | | | Finished), | | |
| Result TLV=Success} | | | {Crypto-Binding TLV, | | |
|<------------------------| | | Result TLV=Success} | | |
| | | |<------------------------| | |
| EAP-Response/ | | | | | |
| Type=TEAP, | | | EAP-Response/ | | |
| {Crypto-Binding TLV, | | | Type=TEAP, | | |
| Result TLV=Success} | | | {Crypto-Binding TLV, | | |
|------------------------>| | | Result TLV=Success} | | |
| | | |------------------------>| | |
| EAP-Request/ | | | | | |
| Type=TEAP, | | | EAP-Request/ | | |
(1)| {Request-Action TLV: | | | Type=TEAP, | | |
| Status=Failure, | | (1)| {Request-Action TLV: | | |
| Action=Process-TLV, | | | Status=Failure, | | |
| TLV=PKCS#10} | | | Action=Process-TLV, | | |
|<------------------------| | | TLV=PKCS#10} | | |
| | | |<------------------------| | |
| EAP-Response/ | | | | | |
| Type=TEAP, | | | EAP-Response/ | | |
| {PKCS#10 TLV} | | | Type=TEAP, | | |
|------------------------>| | | {PKCS#10 TLV} | | |
| | | |------------------------>| | |
| EAP-Request/ | | | | PKCS#10 | |
| Type=TEAP, | | | EAP-Request/ |--------------/ | \----->|
| {PKCS#7 TLV, | | | Type=TEAP, | | |
| Result TLV=Success} | | | {PKCS#7 TLV, | PKCS#7 | |
|<------------------------| | | Result TLV=Success} |<-------------/ | \------|
| | | |<------------------------| | |
| EAP-Response/ | | | | | |
| Type=TEAP, | | | EAP-Response/ | | |
| {Result TLV=Success} | | | Type=TEAP, | | |
|------------------------>| | | {Result TLV=Success} | | |
| | | |------------------------>| | |
| EAP-Success | | | | | |
|<------------------------| | | EAP-Success | | |
|<------------------------| | |
Figure 3: TEAP Server Instructs Client to Reenroll Figure 3: TEAP Server Instructs Client to Reenroll
(1) The server instructs the client to reenroll by sending a Request- (1) The server instructs the client to reenroll by sending a Request-
Action TLV that includes a PKCS#10 TLV. Action TLV that includes a PKCS#10 TLV.
6.4. Out of Band Reenroll 6.4. Out of Band Reenroll
This section shows how the device does a reenroll to refresh its This section shows how the device does a reenroll to refresh its
LDEvID directly against the registrar outside the context of the TEAP LDEvID directly against the registrar outside the context of the TEAP
tunnel. tunnel.
skipping to change at page 18, line 25 skipping to change at page 20, line 35
+------------------------+----------+ +------------------------+----------+
| BRSKI-VoucherRequest | Response | | BRSKI-VoucherRequest | Response |
| BRSKI-Voucher | Request | | BRSKI-Voucher | Request |
| CSR-Attributes | Response | | CSR-Attributes | Response |
+------------------------+----------+ +------------------------+----------+
These new TLVs are detailed in this section. These new TLVs are detailed in this section.
7.1.1. BRSKI-RequestVoucher TLV 7.1.1. BRSKI-RequestVoucher TLV
This TLV is used by the server as part of an Action-Request to This TLV is used by the server as part of a Request-Action TLV to
request from the peer that it initiate a voucher request. When used request from the peer that it initiate a voucher request. When used
in this fashion, the length of this TLV will be set to zero. in this fashion, the length of this TLV will be set to zero. The
Status field of the Request-Action TLV MUST be set to Failure.
It is also used by the peer to initiate the voucher request. When It is also used by the peer to initiate the voucher request. When
used in this fashion, the length of the TLV will be set to that of used in this fashion, the length of the TLV will be set to that of
the voucher request, as encoded and described in Section 3.3 in the voucher request, as encoded and described in Section 3.3 in
[I-D.ietf-anima-bootstrapping-keyinfra]. [I-D.ietf-anima-bootstrapping-keyinfra].
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV=TBD1-VoucherRequest | Length | |M|R| TLV=TBD1-VoucherRequest | Length |
skipping to change at page 19, line 11 skipping to change at page 21, line 26
and then return a voucher in a BRSKI-Voucher TLV as described below. and then return a voucher in a BRSKI-Voucher TLV as described below.
If it is unable to do so, it returns an TEAP Error TLV with one of If it is unable to do so, it returns an TEAP Error TLV with one of
the defined errors or the following: the defined errors or the following:
TBD2-MASA-Notavailable MASA unavailable TBD2-MASA-Notavailable MASA unavailable
TBD3-MASA-Refused MASA refuses to sign the voucher TBD3-MASA-Refused MASA refuses to sign the voucher
The peer terminates the TEAP connection, but may retry at some later The peer terminates the TEAP connection, but may retry at some later
point. The backoff mechanism for such retries should be appropriate point. The backoff mechanism for such retries should be appropriate
for the device. Retries MUST occur no more frequently than once for the device. Retries MUST occur no more frequently than once
every two (XXX) minutes. every two (TBD) minutes.
7.1.2. BRSKI-Voucher TLV 7.1.2. BRSKI-Voucher TLV
This TLV is transmitted from the server to the peer. It contains a This TLV is transmitted from the server to the peer. It contains a
signed voucher, as describe in [RFC8366]. signed voucher, as describe in [RFC8366].
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV=TBD4-Voucher | Length | |M|R| TLV=TBD4-Voucher | Length |
skipping to change at page 20, line 44 skipping to change at page 23, line 20
| PKCS#10 Data... | PKCS#10 Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
[RFC7170] does not explicitly allow a Length value of zero. [RFC7170] does not explicitly allow a Length value of zero.
A Length value of zero is allowed for this TLV when the TEAP server A Length value of zero is allowed for this TLV when the TEAP server
sends a Request-Action TLV with a child PKCS#10 TLV to the client. sends a Request-Action TLV with a child PKCS#10 TLV to the client.
In this scenario, there is no PKCS#10 Data included in the TLV. In this scenario, there is no PKCS#10 Data included in the TLV.
Clients MUST NOT send a zero length PKCS#10 TLV to the server. Clients MUST NOT send a zero length PKCS#10 TLV to the server.
7.3. TLV Rules
BRSKI TLVs can only be transported inside the TLS tunnel. The
following table provides a guide to which TLVs may be encapsulated in
which kind of packets, and in what quantity. The messages are as
follows: Request is a TEAP Request, Response is a TEAP Response,
Success is a message containing a successful Result TLV, and Failure
is a message containing a failed Result TLV.
The following define the meaning of the table entries in the sections
below:
0 This TLV MUST NOT be present in the message.
0+ Zero or more instances of this TLV MAY be present in the message.
0-1 Zero or one instance of this TLV MAY be present in the message.
1 Exactly one instance of this TLV MUST be present in the message.
Request Response Success Failure TLVs 0 0-1 0 0 BRSKI-VoucherRequest
0-1 0 0 0 BRSKI-Voucher 0 0-1 0 0 CSR-Attributes
8. Fragmentation 8. Fragmentation
TLS is expected to provide fragmentation support. Thus EAP-TEAP- TEAP is expected to provide fragmentation support. Thus EAP-TEAP-
BRSKI does not specifically provide any, as it is only expected to be BRSKI does not specifically provide any, as it is only expected to be
used as an inner method to TEAP. used as an inner method to TEAP.
9. IANA Considerations 9. IANA Considerations
The IANA is requested to add entries into the following tables: The IANA is requested to add entries into the following tables:
The following new TEAP TLVs are defined: The following new TEAP TLVs are defined:
TBD1-VoucherRequest Described in this document. TBD1-VoucherRequest Described in this document.
skipping to change at page 21, line 28 skipping to change at page 24, line 28
TBD2-MASA-Notavailable MASA unavailable TBD2-MASA-Notavailable MASA unavailable
TBD3-MASA-Refused MASA refuses to sign the voucher TBD3-MASA-Refused MASA refuses to sign the voucher
TBD5-Invalid-Signature The signature of the voucher signer is invalid TBD5-Invalid-Signature The signature of the voucher signer is invalid
TBD6-Invalid-Voucher The form or content of the voucher is not valid TBD6-Invalid-Voucher The form or content of the voucher is not valid
TBD7-Invalid-TLS-Signer The certificate used for the TLS connection TBD7-Invalid-TLS-Signer The certificate used for the TLS connection
could not be validated. could not be validated.
TBD9-CSR-Attribute-Fail Unable to supply the requested attributes. TBD9-CSR-Attribute-Fail Unable to supply the requested attributes.
10. Security Considerations 10. Security Considerations
There will be many. BRSKI [I-D.ietf-anima-bootstrapping-keyinfra] provides a zero touch
way for devices to enroll in a certification authority (CA). It
assumes the device has IP connectivity. For networks that will not
grant IP connectivitiy before authenticating (with a local
credential) this poses a Catch-22- can't get on the network without a
credential and can't get a credential without getting on the network.
This protocol provides a way for BRSKI to be in an EAP method which
allows the BRSKI conversation to happen as part of EAP authentication
and prior to obtaining IP connectivity.
The security considerations of
[I-D.ietf-anima-bootstrapping-keyinfra] apply to this protocol.
Running BRSKI through EAP introduces some additional areas of concern
though.
10.1. Issues with Provisionally Authenticated TEAP
This protocol establishes an unauthenticated TLS connection and
passes data through it. Provided that the only messages passed in
this state are self-protected BRSKI messages this does not present a
problem. Passing any other messages or TLVs prior to authentication
of the provisional TLS connection could potentially introduce
security issues.
While the TLS connection is unauthenticated, it must still be
validated to the fullest extent possible. It is critical that the
device and the TEAP server perform all steps in TLS- checking the
validity of the presented certificate, validating the signature using
the public key of the certificate, etc- except ensuring the trust of
the presented certificate.
10.2. Attack Against Discovery
The device discovery technique specified in this protocol is the
standard EAP server discovery process. Since it is trivial to set up
an 802.11 wireless access point and advertise any network, an
attacker can impersonate a legitimate wireless network and attract
unprovisioned pledges. Given that an unprovisioned device will not
know the legitimate network to connect to, it will probably attempt
the first network it finds, making the attack that much easier. This
allows for a "rogue registrar" to provision and take control of the
device.
If the MASA verifies ownership prior to issuance of a voucher, this
attack can be thwarted. But if the MASA is in reduced security mode
and does not verify ownership this attack cannot be prevented.
Registrars SHOULD use the audit log of a MASA when deploying newly
purchased equipment in order to mitigate this attack.
Another way to mitigate this attack is through normal "rogue AP"
detection and prevention.
10.3. TEAP Server as Registration Authority
If the TEAP server is logically separate from the Certification
Authority (CA) (see Section 2) it will be acting as a Registration
Authority (RA) when it obtains the PKCS#10 TLV and replies with a
PKCS#7 TLV (see [RFC7170], Sections 4.2.16 and 4.2.17, respectively).
The assurance a RA makes to a CA is that the public key in the
presented CSR is bound to an authenticated identity in way that will
assure non-repudiation.
To make such an assurance, the TEAP server MUST authenticate the
provisional TLS connection with the device by validating the voucher
response received from the MASA. In addition, it is RECOMMENDED that
the TEAP server indicate that proof-of-possession (see [RFC7170],
Section 3.8.2) is required by including the challengePassword OID in
the CSR Attributes TLV.
10.4. Trust of Registrar
The device accepts a trusted server (CA) certificate and installs it
in its trust anchor database during step 5 (see Section 3.2). This
can happen only after the provisional TLS connection has been
authenticated using the voucher and the Crypto-Binding TLV has been
validated.
11. Acknowledgments 11. Acknowledgments
The authors would like to thank Brian Weis for his assistance, and The authors would like to thank Brian Weis for his assistance, and
Alan Dakok for improving language consistency. In addition, with Alan Dakok for improving language consistency. In addition, with
ruthlessly "borrowed" the concept around NAI handling from Tuomas ruthlessly "borrowed" the concept around NAI handling from Tuomas
Aura and Mohit Sethi. Aura and Mohit Sethi.
12. Informative References 12. Normative References
[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.
[IEEE8021AR]
Institute for Electrical and Electronics Engineers,
"Secure Device Identity", 1998.
[IEEE8021X]
Institute for Electrical and Electronics Engineers, "IEEE
Standard for Local and metropolitan area networks--Port-
Based Network Access Control", 2010.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, Ed., "Extensible Authentication Protocol Levkowetz, Ed., "Extensible Authentication Protocol
(EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004,
<https://www.rfc-editor.org/info/rfc3748>. <https://www.rfc-editor.org/info/rfc3748>.
[RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
"Enrollment over Secure Transport", RFC 7030, "Enrollment over Secure Transport", RFC 7030,
DOI 10.17487/RFC7030, October 2013, DOI 10.17487/RFC7030, October 2013,
<https://www.rfc-editor.org/info/rfc7030>. <https://www.rfc-editor.org/info/rfc7030>.
skipping to change at page 22, line 22 skipping to change at page 27, line 12
1", RFC 7170, DOI 10.17487/RFC7170, May 2014, 1", RFC 7170, DOI 10.17487/RFC7170, May 2014,
<https://www.rfc-editor.org/info/rfc7170>. <https://www.rfc-editor.org/info/rfc7170>.
[RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert,
"A Voucher Artifact for Bootstrapping Protocols", "A Voucher Artifact for Bootstrapping Protocols",
RFC 8366, DOI 10.17487/RFC8366, May 2018, RFC 8366, DOI 10.17487/RFC8366, May 2018,
<https://www.rfc-editor.org/info/rfc8366>. <https://www.rfc-editor.org/info/rfc8366>.
Appendix A. Changes from Earlier Versions Appendix A. Changes from Earlier Versions
Draft -03: * Merge EAP server and Registrar * Security considerations
* References improvements * Add Dan Harkins as co-author
Draft -02: * Flow corrections
Draft -01: * Add packet descriptions, IANA considerations, smooth out Draft -01: * Add packet descriptions, IANA considerations, smooth out
language. language.
Draft -00: Draft -00:
o Initial revision o Initial revision
Authors' Addresses Authors' Addresses
Eliot Lear Eliot Lear
skipping to change at page 23, line 4 skipping to change at page 27, line 42
Phone: +41 44 878 9200 Phone: +41 44 878 9200
Email: lear@cisco.com Email: lear@cisco.com
Owen Friel Owen Friel
Cisco Systems Cisco Systems
170 W. Tasman Dr. 170 W. Tasman Dr.
San Jose, CA 95134 San Jose, CA 95134
United States United States
Email: ofriel@cisco.com Email: ofriel@cisco.com
Nancy Cam-Winget Nancy Cam-Winget
Cisco Systems Cisco Systems
170 W. Tasman Dr. 170 W. Tasman Dr.
San Jose, CA 95134 San Jose, CA 95134
United States United States
Email: ncamwing@cisco.com Email: ncamwing@cisco.com
Dan Harkins
HP Enterprise
3333 Scott Boulevard
Santa Clara, CA 95054
United States
Email: dharkins@arubanetworks.com
 End of changes. 49 change blocks. 
303 lines changed or deleted 529 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/