< draft-ietf-sidrops-rpki-has-no-identity-03.txt   draft-ietf-sidrops-rpki-has-no-identity-04.txt >
Network Working Group R. Bush Network Working Group R. Bush
Internet-Draft Arrcus & Internet Initiative Japan Internet-Draft Arrcus & Internet Initiative Japan
Intended status: Standards Track R. Housley Intended status: Standards Track R. Housley
Expires: 10 July 2022 Vigil Security Expires: 4 September 2022 Vigil Security
6 January 2022 3 March 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-03 draft-ietf-sidrops-rpki-has-no-identity-04
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 'owner' of RPKI can be associated with the real-world identity of the 'owner' of
an INR. This document attempts to put that notion to rest. an INR. This document attempts to put that notion to rest.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 10 July 2022. This Internet-Draft will expire on 4 September 2022.
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 (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 32 skipping to change at page 2, line 32
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Normative References . . . . . . . . . . . . . . . . . . 6 7.1. Normative References . . . . . . . . . . . . . . . . . . 6
7.2. Informative References . . . . . . . . . . . . . . . . . 6 7.2. Informative References . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
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). Though since, it has grown to Internet Number Resources (INRs). Since initial deployment, the RPKI
include other similar resource and routing data, e.g. Router Keying has grown to include other similar resource and routing data, e.g.
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's strong authority corresponding private key [RFC5280]. The RPKI's strong authority
over ownership of INRs has misled some people toward a desire to use over ownership of INRs has misled some people toward a desire to use
RPKI private keys to sign arbitrary documents attesting that the INR RPKI private keys to sign arbitrary documents attesting that the INR
'owner' of those resources has attested to the authenticity of the 'owner' of those resources has attested to the authenticity of the
document content. But in reality, the RPKI certificate is only an document content. But in reality, the RPKI certificate is only an
authorization to speak for for the explicitly identified INRs; it is authorization to speak for the explicitly identified INRs; it is
explicitly not intended for authentication of the 'owners' of the explicitly not intended for authentication of the 'owners' of the
INRs. This situation is emphasized in Section 2.1 of [RFC6480]. INRs. This situation is emphasized in 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. E.g. Bill's Bait
and Sushi could use their AS in the RPKI to sign a Letter of and Sushi could use their AS in the RPKI to sign a Letter of
Authorization (LOA) for some other party to rack and stack hardware Authorization (LOA) for some other party to rack and stack hardware
owned by BB&S. Unfortunately, this is not formally feasible. owned by BB&S. Unfortunately, this is not formally feasible.
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 speak holder(s) of those INRs. The RPKI provides authorization to speak
for the named IP address blocks and AS numbers. for the named IP address blocks and AS numbers.
skipping to change at page 3, line 22 skipping to change at page 3, line 22
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 a RPKI private key holder.
2. The Bottom Line 2. The Bottom Line
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 a feature That the RPKI does not authenticate real-world identity is a feature,
not a bug. If it tried to do so, aside from the liability, it would not a bug. If it tried to do so, aside from the liability, it would
end in a world of complexity with no proof of termination, as X.400 end in a world of complexity with no proof of termination, as X.400
learned. learned.
Registries such as the Regional Internet Resistries (RIRs) provide Registries such as the Regional Internet Registries (RIRs) provide
INR to real world identity mapping through whois and similar INR to real-world identity mapping through whois and similar
services. They claim to be authoritative, at least for the INRs services. They claim to be authoritative, at least for the INRs
which they allocate. which they allocate.
RPKI-based credentials of INRs MUST NOT be used to authenticate real RPKI-based credentials of INRs MUST NOT be used to authenticate real-
world documents or transactions without some formal external world documents or transactions without some formal external
authentication of the INR and the authority for the actually authentication of the INR and the authority for the actually
anonymous INR holder to authenticate the particular document or anonymous INR holder to authenticate the particular document or
transaction. transaction.
Note that, if there is sufficient external, i.e. non-RPKI, Given sufficient external, i.e. non-RPKI, verification of authority,
verifcation of authority, then use of RPKI-based credentials seems the use of RPKI-based credentials seems superfluous.
superfluous.
3. Discussion 3. Discussion
The RPKI base document, [RFC6480], Section 2.1 says explicitly "An The RPKI base document, [RFC6480], Section 2.1 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 The Template for a Certification Practice Statement (CPS) for the
Resource PKI (RPKI) [RFC7382] Section 3.1, Naming, makes very clear Resource PKI (RPKI) [RFC7382] Section 3.1, Naming, makes very clear
that "The Subject name in each certificate SHOULD NOT be meaningful;" that "The Subject name in each certificate SHOULD NOT be meaningful;"
and goes on to do so at some length. and goes on to do so 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 Certification Authority (CA) does. The INR
holder has a real world business relationship with the CA for which holder has a real-world business relationship with the CA for which
they have likely signed real world documents. they have likely signed real-world documents.
As the INR owner does not have the keying material, they rely on the As the INR owner 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 userid/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 [I-D.ietf-sidrops-rpki-rta] and
[I-D.ietf-sidrops-rpki-rsc] must go to great lengths to extract the [I-D.ietf-sidrops-rpki-rsc] must go to great lengths to extract the
supposedly relevant keys from the CA. supposedly relevant keys from the CA.
skipping to change at page 4, line 40 skipping to change at page 4, line 40
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 owner of that AS may be BB&S Then there is the temporal issue. The owner 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 attest to INR ownership. They are merely clues for operational not attest to INR ownership. They are merely clues for 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 INR ownership Usually, before registering INRs, CAs require proof of INR ownership
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 must, or even might, conduct to assure the INRs are in fact owned CA must, or even might, conduct to assure the INRs are in fact owned
by a registrant. by 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 just an INR administrative person.
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 are invalid and misleading. other artifacts requiring identity are invalid and misleading.
When a document is signed with the private key associated with a RPKI When a document is signed with the private key associated with an
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 Autonomous System (AS) numbers, in the certificate. This
is not an identity; this is an authorization. In schemes such as is not an identity; this is an authorization. In schemes such as
[I-D.ietf-sidrops-rpki-rta] and [I-D.ietf-sidrops-rpki-rsc] the [I-D.ietf-sidrops-rpki-rta] and [I-D.ietf-sidrops-rpki-rsc] the
signed message further narrows this scope of INRs. The INRs in the signed message further narrows this scope of INRs. The INRs in the
message are a subset of the INRs in the certificate. If the message are a subset of the INRs in the certificate. If the
signature is valid, the message content comes from a party that is signature is valid, the message content comes from a party that is
authorized to speak for that subset of INRs. authorized to 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.
RPKI-based credentials of INRs MUST NOT be used to authenticate real RPKI-based credentials of INRs MUST NOT be used to authenticate real-
world documents or transactions without some formal external world documents or transactions without some formal external
authentication of the INR and the authority for the actually authentication of the INR and the authority for the actually
anonymous INR holder to authenticate the particular document or anonymous INR holder to authenticate the particular document or
transaction. transaction.
5. IANA Considerations 5. IANA Considerations
This document has no IANA Considerations. This document has no IANA Considerations.
6. Acknowledgments 6. Acknowledgments
skipping to change at page 6, line 50 skipping to change at page 6, line 50
[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 7.2. Informative References
[I-D.ietf-sidrops-rpki-rsc] [I-D.ietf-sidrops-rpki-rsc]
Snijders, J., Harrison, T., and B. Maddison, "Resource Snijders, J., Harrison, T., and B. Maddison, "Resource
Public Key Infrastructure (RPKI) object profile for Signed Public Key Infrastructure (RPKI) object profile for Signed
Checklist (RSC)", Work in Progress, Internet-Draft, draft- Checklist (RSC)", Work in Progress, Internet-Draft, draft-
ietf-sidrops-rpki-rsc-05, 11 August 2021, ietf-sidrops-rpki-rsc-06, 12 February 2022,
<https://www.ietf.org/archive/id/draft-ietf-sidrops-rpki- <https://www.ietf.org/archive/id/draft-ietf-sidrops-rpki-
rsc-05.txt>. rsc-06.txt>.
[I-D.ietf-sidrops-rpki-rta] [I-D.ietf-sidrops-rpki-rta]
Michaelson, G. G., Huston, G., Harrison, T., Bruijnzeels, Michaelson, G. G., Huston, G., Harrison, T., Bruijnzeels,
T., and M. Hoffmann, "A profile for Resource Tagged T., and M. Hoffmann, "A profile for Resource Tagged
Attestations (RTAs)", Work in Progress, Internet-Draft, Attestations (RTAs)", Work in Progress, Internet-Draft,
draft-ietf-sidrops-rpki-rta-00, 21 January 2021, draft-ietf-sidrops-rpki-rta-00, 21 January 2021,
<https://www.ietf.org/archive/id/draft-ietf-sidrops-rpki- <https://www.ietf.org/archive/id/draft-ietf-sidrops-rpki-
rta-00.txt>. rta-00.txt>.
[RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI) [RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI)
 End of changes. 22 change blocks. 
30 lines changed or deleted 29 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/