rfc9255.original   rfc9255.txt 
Network Working Group R. Bush Internet Engineering Task Force (IETF) R. Bush
Internet-Draft Arrcus & Internet Initiative Japan Request for Comments: 9255 Arrcus & IIJ Research
Intended status: Standards Track R. Housley Category: Standards Track R. Housley
Expires: 21 October 2022 Vigil Security ISSN: 2070-1721 Vigil Security
19 April 2022 June 2022
The I in RPKI does not stand for Identity The 'I' in RPKI Does Not Stand for Identity
draft-ietf-sidrops-rpki-has-no-identity-07
Abstract Abstract
There is a false notion that Internet Number Resources (INRs) in the There is a false notion that Internet Number Resources (INRs) in the
RPKI can be associated with the real-world identity of the 'holder' RPKI can be associated with the real-world identity of the 'holder'
of an INR. This document specifies that RPKI does not associate to of an INR. This document specifies that RPKI does not associate to
the INR holder. the INR holder.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 21 October 2022. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9255.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. The RPKI is for Authorization . . . . . . . . . . . . . . . . 3 1.1. Requirements Language
3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. The RPKI is for Authorization
4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 3. Discussion
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 4. Security Considerations
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. References
7.1. Normative References . . . . . . . . . . . . . . . . . . 6 6.1. Normative References
7.2. Informative References . . . . . . . . . . . . . . . . . 6 6.2. Informative References
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 Acknowledgments
Authors' Addresses
1. Introduction 1. Introduction
The Resource Public Key Infrastructure (RPKI), see [RFC6480], The Resource Public Key Infrastructure (RPKI), see [RFC6480],
"Represents the allocation hierarchy of IP address space and "represents the allocation hierarchy of IP address space and
Autonomous System (AS) numbers," which are collectively known as Autonomous System (AS) numbers," which are collectively known as
Internet Number Resources (INRs). Since initial deployment, the RPKI Internet Number Resources (INRs). Since initial deployment, the RPKI
has grown to include other similar resource and routing data, e.g. has grown to include other similar resource and routing data, e.g.,
Router Keying for BGPsec, [RFC8635]. Router Keying for BGPsec [RFC8635].
In security terms, the phrase "Public Key" implies there is also a In security terms, the phrase "Public Key" implies there is also a
corresponding private key [RFC5280]. The RPKI provides strong corresponding private key [RFC5280]. The RPKI provides strong
authority to the current holder of INRs; however, some people a have authority to the current holder of INRs; however, some people have a
a desire to use RPKI private keys to sign arbitrary documents as the desire to use RPKI private keys to sign arbitrary documents as the
INR 'holder' of those resources with the inappropriate expectation INR 'holder' of those resources with the inappropriate expectation
that the signature will be considered an attestation to the that the signature will be considered an attestation to the
authenticity of the document content. But in reality, the RPKI authenticity of the document content. But, in reality, the RPKI
certificate is only an authorization to speak for the explicitly certificate is only an authorization to speak for the explicitly
identified INRs; it is explicitly not intended for authentication of identified INRs; it is explicitly not intended for authentication of
the 'holders' of the INRs. This situation is emphasized in the 'holders' of the INRs. This situation is emphasized in
Section 2.1 of [RFC6480]. Section 2.1 of [RFC6480].
It has been suggested that one could authenticate real-world business It has been suggested that one could authenticate real-world business
transactions with the signatures of INR holders. E.g. Bill's Bait transactions with the signatures of INR holders. For example, Bill's
and Sushi (BB&S) could use the private key attesting to that they are Bait and Sushi (BB&S) could use the private key attesting to that
the holder of their AS in the RPKI to sign a Letter of Authorization they are the holder of their AS in the RPKI to sign a Letter of
(LOA) for some other party to rack and stack hardware owned by BB&S. Authorization (LOA) for some other party to rack and stack hardware
Unfortunately, while this may be technically possible, it is neither owned by BB&S. Unfortunately, while this may be technically
appropriate nor meaningful. possible, it is neither appropriate nor meaningful.
The I in RPKI actually stands for "Infrastructure," as in Resource The 'I' in RPKI actually stands for "Infrastructure," as in Resource
Public Key Infrastructure, not for "Identity". In fact, the RPKI Public Key Infrastructure, not for "Identity". In fact, the RPKI
does not provide any association between INRs and the real world does not provide any association between INRs and the real-world
holder(s) of those INRs. The RPKI provides authorization to make holder(s) of those INRs. The RPKI provides authorization to make
assertions only regarding Internet Number Resources, such as IP assertions only regarding Internet Number Resources, such as IP
prefixes or AS numbers, and data such as ASPA prefixes or AS numbers, and data such as Autonomous System Provider
[I-D.ietf-sidrops-aspa-profile]records. Authorization (ASPA) records [ASPA-PROFILE].
In short, avoid the desire to use RPKI certificates for any purpose In short, avoid the desire to use RPKI certificates for any purpose
other than the verification of authorizations associated with the other than the verification of authorizations associated with the
delegation of INRs or attestations related to INRs. Instead, delegation of INRs or attestations related to INRs. Instead,
recognize that these authorizations and attestations take place recognize that these authorizations and attestations take place
irrespective of the identity of a RPKI private key holder. irrespective of the identity of an RPKI private key holder.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. The RPKI is for Authorization 2. The RPKI is for Authorization
The RPKI was designed and specified to sign certificates for use The RPKI was designed and specified to sign certificates for use
within the RPKI itself and to generate Route Origin Authorizations within the RPKI itself and to generate Route Origin Authorizations
(ROAs), [RFC6480], for use in routing. Its design intentionally (ROAs) [RFC6480] for use in routing. Its design intentionally
precluded use for attesting to real-world identity as, among other precluded use for attesting to real-world identity as, among other
issues, it would expose the Certification Authority (CA) to issues, it would expose the Certification Authority (CA) to
liability. liability.
That the RPKI does not authenticate real-world identity is by design. That the RPKI does not authenticate real-world identity is by design.
If it tried to do so, aside from the liability, it would end in a If it tried to do so, aside from the liability, it would end in a
world of complexity with no proof of termination. world of complexity with no proof of termination.
Registries such as the Regional Internet Registries (RIRs) provide Registries such as the Regional Internet Registries (RIRs) provide
INR to real-world identity mapping through WHOIS, [RFC3912], and INR to real-world identity mapping through WHOIS [RFC3912] and
similar services. They claim to be authoritative, at least for the similar services. They claim to be authoritative, at least for the
INRs which they allocate. INRs that they allocate.
That is, RPKI-based credentials of INRs MUST NOT be used to That is, RPKI-based credentials of INRs MUST NOT be used to
authenticate real-world documents or transactions. That might be authenticate real-world documents or transactions. That might be
done with some formal external authentication of authority allowing done with some formal external authentication of authority allowing
an otherwise anonymous INR holder to authenticate the particular an otherwise anonymous INR holder to authenticate the particular
document or transaction. Given such external, i.e. non-RPKI, document or transaction. Given such external, i.e. non-RPKI,
verification of authority, the use of RPKI-based credentials adds no verification of authority, the use of RPKI-based credentials adds no
authenticity. authenticity.
3. Discussion 3. Discussion
The RPKI base document, [RFC6480], Section 2.1 says explicitly "An Section 2.1 of the RPKI base document [RFC6480] says explicitly "An
important property of this PKI is that certificates do not attest to important property of this PKI is that certificates do not attest to
the identity of the subject." the identity of the subject."
The Template for a Certification Practice Statement (CPS) for the Section 3.1 of "Template for a Certification Practice Statement (CPS)
Resource PKI (RPKI) [RFC7382] Section 3.1, Naming, makes very clear for the Resource PKI (RPKI)" [RFC7382] states that the Subject name
that "The Subject name in each certificate SHOULD NOT be meaningful;" in each certificate SHOULD NOT be meaningful and goes on to explain
and goes on to do so at some length. this at some length.
Normally, the INR holder does not hold the private key attesting to Normally, the INR holder does not hold the private key attesting to
their resources; the Certification Authority (CA) does. The INR their resources; the CA does. The INR holder has a real-world
holder has a real-world business relationship with the CA for which business relationship with the CA for which they have likely signed
they have likely signed real-world documents. real-world documents.
As the INR holder does not have the keying material, they rely on the As the INR holder does not have the keying material, they rely on the
CA, to which they presumably present credentials, to manipulate their CA, to which they presumably present credentials, to manipulate their
INRs. These credentials may be userid/password (with two factor INRs. These credentials may be user ID and password (with two-factor
authentication one hopes), a hardware token, client browser authentication one hopes), a hardware token, client browser
certificates, etc. certificates, etc.
Hence schemes such as [I-D.ietf-sidrops-rpki-rta] and Hence schemes such as Resource Tagged Attestations [RPKI-RTA] and
[I-D.ietf-sidrops-rpki-rsc] must go to great lengths to extract the Signed Checklists [RPKI-RSC] must go to great lengths to extract the
supposedly relevant keys from the CA. supposedly relevant keys from the CA.
For some particular INR, say Bill's Bait and Sushi's Autonomous For some particular INR, say, Bill's Bait and Sushi's Autonomous
System (AS) number, someone out on the net probably has the System (AS) number, someone out on the net probably has the
credentials to the CA account in which BB&S's INRs are registered. credentials to the CA account in which BB&S's INRs are registered.
That could be the owner of BB&S, Roberto's Taco Stand, an IT vendor, That could be the owner of BB&S, Randy's Taco Stand, an IT vendor, or
or the Government of Elbonia. One simply can not know. the Government of Elbonia. One simply can not know.
In large organizations, INR management is often compartmentalized In large organizations, INR management is often compartmentalized
with no authority over anything beyond dealing with INR registration. with no authority over anything beyond dealing with INR registration.
The INR manager for Bill's Bait and Sushi is unlikely to be The INR manager for Bill's Bait and Sushi is unlikely to be
authorized to conduct bank transactions for BB&S, or even to authorized to conduct bank transactions for BB&S, or even to
authorize access to BB&S's servers in some colocation facility. authorize access to BB&S's servers in some colocation facility.
Then there is the temporal issue. The holder of that AS may be BB&S Then there is the temporal issue. The holder of that AS may be BB&S
today when some document was signed, and could be the Government of today when some document was signed, and could be the Government of
Elbonia tomorrow. Or the resource could have been administratively Elbonia tomorrow. Or the resource could have been administratively
skipping to change at page 5, line 4 skipping to change at line 181
The INR manager for Bill's Bait and Sushi is unlikely to be The INR manager for Bill's Bait and Sushi is unlikely to be
authorized to conduct bank transactions for BB&S, or even to authorized to conduct bank transactions for BB&S, or even to
authorize access to BB&S's servers in some colocation facility. authorize access to BB&S's servers in some colocation facility.
Then there is the temporal issue. The holder of that AS may be BB&S Then there is the temporal issue. The holder of that AS may be BB&S
today when some document was signed, and could be the Government of today when some document was signed, and could be the Government of
Elbonia tomorrow. Or the resource could have been administratively Elbonia tomorrow. Or the resource could have been administratively
moved from one CA to another, likely requiring a change of keys. If moved from one CA to another, likely requiring a change of keys. If
so, how does one determine if the signature on the real-world so, how does one determine if the signature on the real-world
document is still valid? document is still valid?
While Ghostbuster Records [RFC6493] may seem to identify real-world While Ghostbuster Records [RFC6493] may seem to identify real-world
entities, their semantic content is completely arbitrary, and does entities, their semantic content is completely arbitrary and does not
not attest to holding of any INRs. They are merely clues for attest to holding of any INRs. They are merely clues for operational
operational support contact in case of technical RPKI problems. support contact in case of technical RPKI problems.
Usually, before registering INRs, CAs require proof of an INR holding Usually, before registering INRs, CAs require proof of an INR holding
via external documentation and authorities. It is somewhat droll via external documentation and authorities. It is somewhat droll
that the CPS Template, [RFC7382], does not mention any diligence the that the CPS Template [RFC7382] does not mention any diligence the CA
CA must, or even might, conduct to assure the INRs are in fact owned must, or even might, conduct to assure the INRs are in fact owned by
by a registrant. a registrant.
That someone can provide 'proof of possession' of the private key That someone can provide 'proof of possession' of the private key
signing over a particular INR should not be taken to imply that they signing over a particular INR should not be taken to imply that they
are a valid legal representative of the organization in possession of are a valid legal representative of the organization in possession of
that INR. They could be just an INR administrative person. that INR. They could be in an INR administrative role, and not be a
formal representative of the organization.
Autonomous System Numbers do not identify real-world entities. They Autonomous System Numbers do not identify real-world entities. They
are identifiers some network operators 'own' and are only used for are identifiers some network operators 'own' and are only used for
loop detection in routing. They have no inherent semantics other loop detection in routing. They have no inherent semantics other
than uniqueness. than uniqueness.
4. Security Considerations 4. Security Considerations
Attempts to use RPKI data to authenticate real-world documents or Attempts to use RPKI data to authenticate real-world documents or
other artifacts requiring identity, while possibly cryptographically other artifacts requiring identity, while possibly cryptographically
valid within the RPKI, are misleading as to any authenticity. valid within the RPKI, are misleading as to any authenticity.
When a document is signed with the private key associated with an When a document is signed with the private key associated with an
RPKI certificate, the signer is speaking for the INRs, the IP address RPKI certificate, the signer is speaking for the INRs (the IP address
space and Autonomous System (AS) numbers, in the certificate. This space and AS numbers) in the certificate. This is not an identity;
is not an identity; this is an authorization. In schemes such as this is an authorization. In schemes such as Resource Tagged
[I-D.ietf-sidrops-rpki-rta] and [I-D.ietf-sidrops-rpki-rsc] the Attestations [RPKI-RTA] and Signed Checklists [RPKI-RSC], the signed
signed message further narrows this scope of INRs. The INRs in the message further narrows this scope of INRs. The INRs in the message
message are a subset of the INRs in the certificate. If the are a subset of the INRs in the certificate. If the signature is
signature is valid, the message content comes from a party that is valid, the message content comes from a party that is authorized to
authorized to speak for that subset of INRs. speak for that subset of INRs.
Control of INRs for an entity could be used to falsely authorize Control of INRs for an entity could be used to falsely authorize
transactions or documents for which the INR manager has no authority. transactions or documents for which the INR manager has no authority.
5. IANA Considerations 5. IANA Considerations
This document has no IANA Considerations. This document has no IANA actions.
6. Acknowledgments
The authors thank George Michaelson and Job Snijders for lively
discussion, Geoff Huston for some more formal text, Ties de Kock for
useful suggestions, many directorate and IESG reviewers, and last but
not least, Biff for the loan of Bill's Bait and Sushi.
7. References 6. References
7.1. Normative References 6.1. Normative References
[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,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
skipping to change at page 6, line 44 skipping to change at line 259
April 2015, <https://www.rfc-editor.org/info/rfc7382>. April 2015, <https://www.rfc-editor.org/info/rfc7382>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8635] Bush, R., Turner, S., and K. Patel, "Router Keying for [RFC8635] Bush, R., Turner, S., and K. Patel, "Router Keying for
BGPsec", RFC 8635, DOI 10.17487/RFC8635, August 2019, BGPsec", RFC 8635, DOI 10.17487/RFC8635, August 2019,
<https://www.rfc-editor.org/info/rfc8635>. <https://www.rfc-editor.org/info/rfc8635>.
7.2. Informative References 6.2. Informative References
[I-D.ietf-sidrops-aspa-profile] [ASPA-PROFILE]
Azimov, A., Uskov, E., Bush, R., Patel, K., Snijders, J., Azimov, A., Uskov, E., Bush, R., Patel, K., Snijders, J.,
and R. Housley, "A Profile for Autonomous System Provider and R. Housley, "A Profile for Autonomous System Provider
Authorization", Work in Progress, Internet-Draft, draft- Authorization", Work in Progress, Internet-Draft, draft-
ietf-sidrops-aspa-profile-07, 31 January 2022, ietf-sidrops-aspa-profile-07, 31 January 2022,
<https://www.ietf.org/archive/id/draft-ietf-sidrops-aspa- <https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
profile-07.txt>. aspa-profile-07>.
[I-D.ietf-sidrops-rpki-rsc]
Snijders, J., Harrison, T., and B. Maddison, "Resource
Public Key Infrastructure (RPKI) object profile for Signed
Checklist (RSC)", Work in Progress, Internet-Draft, draft-
ietf-sidrops-rpki-rsc-06, 12 February 2022,
<https://www.ietf.org/archive/id/draft-ietf-sidrops-rpki-
rsc-06.txt>.
[I-D.ietf-sidrops-rpki-rta]
Michaelson, G. G., Huston, G., Harrison, T., Bruijnzeels,
T., and M. Hoffmann, "A profile for Resource Tagged
Attestations (RTAs)", Work in Progress, Internet-Draft,
draft-ietf-sidrops-rpki-rta-00, 21 January 2021,
<https://www.ietf.org/archive/id/draft-ietf-sidrops-rpki-
rta-00.txt>.
[RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, [RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912,
DOI 10.17487/RFC3912, September 2004, DOI 10.17487/RFC3912, September 2004,
<https://www.rfc-editor.org/info/rfc3912>. <https://www.rfc-editor.org/info/rfc3912>.
[RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI) [RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI)
Ghostbusters Record", RFC 6493, DOI 10.17487/RFC6493, Ghostbusters Record", RFC 6493, DOI 10.17487/RFC6493,
February 2012, <https://www.rfc-editor.org/info/rfc6493>. February 2012, <https://www.rfc-editor.org/info/rfc6493>.
[RPKI-RSC] Snijders, J., Harrison, T., and B. Maddison, "A profile
for Resource Public Key Infrastructure (RPKI) Signed
Checklists (RSC)", Work in Progress, Internet-Draft,
draft-ietf-sidrops-rpki-rsc-08, 26 May 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
rpki-rsc-08>.
[RPKI-RTA] Michaelson, G., Huston, G., Harrison, T., Bruijnzeels, T.,
and M. Hoffmann, "A profile for Resource Tagged
Attestations (RTAs)", Work in Progress, Internet-Draft,
draft-ietf-sidrops-rpki-rta-00, 21 January 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
rpki-rta-00>.
Acknowledgments
The authors thank George Michaelson and Job Snijders for lively
discussion, Geoff Huston for some more formal text, Ties de Kock for
useful suggestions, many directorate and IESG reviewers, and last but
not least, Biff for the loan of Bill's Bait and Sushi.
Authors' Addresses Authors' Addresses
Randy Bush Randy Bush
Arrcus & Internet Initiative Japan Arrcus & Internet Initiative Japan Research
5147 Crystal Springs 5147 Crystal Springs
Bainbridge Island, WA 98110 Bainbridge Island, WA 98110
United States of America United States of America
Email: randy@psg.com Email: randy@psg.com
Russ Housley Russ Housley
Vigil Security, LLC Vigil Security, LLC
516 Dranesville Road 516 Dranesville Road
Herndon, VA, 20170 Herndon, VA 20170
United States of America United States of America
Email: housley@vigilsec.com Email: housley@vigilsec.com
 End of changes. 41 change blocks. 
125 lines changed or deleted 123 lines changed or added

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