Skip to main content

A Publication Protocol for the Resource Public Key Infrastructure (RPKI)
RFC 8181

Document Type RFC - Proposed Standard (July 2017)
Authors Samuel Weiler , Anuja Sonalker , Rob Austein
Last updated 2017-07-26
RFC stream Internet Engineering Task Force (IETF)
Formats
Additional resources Mailing list discussion
IESG Responsible AD Alvaro Retana
Send notices to (None)
RFC 8181

MIMI Prague

Richard Barnes - Archicture Overview

Explanation of CSSC

  • Each room in hosted at hub server
  • All comms go through the hub
  • Not every server wants to talk to others
  • "error_code" attribute. The value of this attribute is a token indicating the specific error that occurred. The body of the <report_error/> element contains two sub-elements: 1. An optional text element <error_text/>, which, if present, contains a text string with debugging information intended for human consumption. 2. An optional element <failed_pdu/>, which, if present, contains a verbatim copy of the query PDU whose failure triggered the <report_error/> PDU. The quoted element must be syntactically valid. See Section 3.7 for examples of a multi-element query and responses. 2.5. Error Codes These are the defined error codes as well as some discussion of each. Text similar to these descriptions may be sent in an <error_text/> element to help explain the error encountered. xml_error: Encountered an XML problem. Note that some XML errors may be severe enough to require error reporting at the HTTP layer, instead. Implementations MAY choose to report any or all XML errors at the HTTP layer. permission_failure: Client does not have permission to update this URI. bad_cms_signature: Bad CMS signature. object_already_present: An object is already present at this URI, yet a "hash" attribute was not specified. A "hash" attribute must be specified when overwriting or deleting an object. Perhaps client and server are out of sync? no_object_present: There is no object present at this URI, yet a "hash" attribute was specified. Perhaps client and server are out of sync? no_object_matching_hash: The "hash" attribute supplied does not match the "hash" attribute of the object at this URI. Perhaps client and server are out of sync? Weiler, et al. Standards Track [Page 9] RFC 8181 RPKI Publication Protocol July 2017 consistency_problem: Server detected an update that looks like it will cause a consistency problem (e.g., an object was deleted, but the manifest was not updated). Note that a server is not required to make such checks. Indeed, it may be unwise for a server to do so. This error code just provides a way for the server to explain its (in-)action. other_error: A meteor fell on the server. 2.6. XML Schema The following is a [RELAX-NG] compact form schema describing the publication protocol. This schema is normative: in the event of a disagreement between this schema and the document text above, this schema is authoritative. # RELAX NG schema for RPKI publication protocol. default namespace = "http://www.hactrn.net/uris/rpki/publication-spec/" # This is version 4 of the protocol. version = "4" # Top-level PDU is either a query or a reply. start |= element msg { attribute version { version }, attribute type { "query" }, query_elt } start |= element msg { attribute version { version }, attribute type { "reply" }, reply_elt } # Tag attributes for bulk operations. tag = attribute tag { xsd:token { maxLength="1024" } } # Base64-encoded DER stuff. base64 = xsd:base64Binary Weiler, et al. Standards Track [Page 10] RFC 8181 RPKI Publication Protocol July 2017 # Publication URIs. uri = attribute uri { xsd:anyURI { maxLength="4096" } } # Digest of an existing object (hexadecimal). hash = attribute hash { xsd:string { pattern = "[0-9a-fA-F]+" } } # Error codes. error |= "xml_error" error |= "permission_failure" error |= "bad_cms_signature" error |= "object_already_present" error |= "no_object_present" error |= "no_object_matching_hash" error |= "consistency_problem" error |= "other_error" # <publish/> and <withdraw/> query elements query_elt |= ( element publish { tag, uri, hash?, base64 } | element withdraw { tag, uri, hash } )* # <success/> reply reply_elt |= element success { empty } # <list/> query and reply query_elt |= element list { empty } reply_elt |= element list { uri, hash }* # <report_error/> reply reply_elt |= element report_error { tag?, attribute error_code { error }, element error_text { xsd:string { maxLength="512000" }}?, element failed_pdu { query_elt }? }* Weiler, et al. Standards Track [Page 11] RFC 8181 RPKI Publication Protocol July 2017 3. Examples Following are examples of various queries and the corresponding replies for the RPKI publication protocol. Note that the authors have taken liberties with the Base64, hash, and URI text in these examples in the interest of making the examples fit nicely into RFC text format. Similarly, these examples do not show the CMS signature wrapper around the XML, just the XML payload. 3.1. <publish/> Query, No Existing Object <msg type="query" version="4" xmlns="http://www.hactrn.net/uris/rpki/publication-spec/"> <!-- body is base64(new-object) --> <publish tag="" uri="rsync://wombat.example/Alice/01a97a70ac477f06.cer"> SGVsbG8sIG15IG5hbWUgaXMgQWxpY2U= </publish> </msg> 3.2. <publish/> Query, Overwriting Existing Object <msg type="query" version="4" xmlns="http://www.hactrn.net/uris/rpki/publication-spec/"> <!-- hash is hex(SHA-256(old-object)) --> <!-- body is base64(new-object) --> <publish hash="01a97a70ac477f06" tag="foo" uri="rsync://wombat.example/Alice/01a97a70ac477f06.cer"> SGVsbG8sIG15IG5hbWUgaXMgQWxpY2U= </publish> </msg> Weiler, et al. Standards Track [Page 12] RFC 8181 RPKI Publication Protocol July 2017 3.3. <withdraw/> Query <msg type="query" version="4" xmlns="http://www.hactrn.net/uris/rpki/publication-spec/"> <!-- hash is hex(SHA-256(old-object)) --> <withdraw hash="01a97a70ac477f06" tag="foo" uri="rsync://wombat.example/Alice/01a97a70ac477f06.cer"/> </msg> 3.4. <success/> Reply <msg type="reply" version="4" xmlns="http://www.hactrn.net/uris/rpki/publication-spec/"> <success/> </msg> 3.5. <report_error/> with Optional Elements <msg type="reply" version="4" xmlns="http://www.hactrn.net/uris/rpki/publication-spec/"> <report_error error_code="no_object_matching_hash" tag="foo"> <error_text> Can't delete an object I don't have &

Terminology

  • Rooms are the unit of measurement:

    • They have a state, has a components of
      • auth policy,
      • users (participants),
      • MLS
  • Participants can be active/inactive

Preemption

  • A user may be a participant only if authed
  • THe client can only be a member of the MLS group if particpant

Confirmation
Different aspects of the state are managed via control sub protocols.
Each commit reflect the current room state.
All clients have a common understanding of the room state.

EKR: Same issue as last time. Imagine the ban use cas.
RB: The servers run a little bit ahead of the MLS group in the add case,
lags in the remove case, until the device is removed. You can set the
logic to make sure it happens.
EKR: Goes over a step by step. RB agrees.
RM: It's ok if there's inconsistency as we go through the process.

Lego Bricks Slide
New slide.
Maps documents to architecture

AC: Double checking for the documentation approach.
RB: Content and arch being separate is fine. Shouldn't confuse reading
too much, maybe a easier for the engineering.
DKG: Imagine EKR banned, how does the client know that we need to eject
him.
RB: Great protocol question. We have to work on that exact description.

RM: Architecture should be a separate document.
RR: To DKG, both in the protocol and DS
A good reason to keep the DS separate for a super clean interface, and
can be reused in a different context, on purpose because it handles
client to server, not just server to server, which is the scope of MIMI.

EKR: The question is that do we specify the semantic transitions in this
group?
RB: Yes, I think we cannot avoid it. Our building blocks have some
flexibility, but it's clear to all of us what playbook we are following.

AC: We want to specify, just haven't gotten it yet.
RR: Only has to be good enough for adoption, not last call.
RM: We need to have one way to do things, but we need to support the
actual stuff in the wild.
DKG: We are creating semantics that might eventually be surfaced by the
client. How is that going to change? AC: Conrad's the man, in his deck.

MIMI Content Format, Roan Mahy

What's new?

  • Abstract format for attachments, instead of message/external-body
  • Added discussion of encrypting external content
  • clarified difference between render and inline
  • created message_id and timestamp. Inner message encrypted, the
    exteral message as an envelope. Given our purview, we cannotlt;/error_text> <failed_pdu> <publish hash="01a97a70ac477f06" tag="foo" uri="rsync://wombat.example/Alice/01a97a70ac477f06.cer"> SGVsbG8sIG15IG5hbWUgaXMgQWxpY2U= </publish> </failed_pdu> </report_error> </msg> Weiler, et al. Standards Track [Page 13] RFC 8181 RPKI Publication Protocol July 2017 3.6. <report_error/> without Optional Elements <msg type="reply" version="4" xmlns="http://www.hactrn.net/uris/rpki/publication-spec/"> <report_error error_code="object_already_present" tag="foo"/> </msg> 3.7. Error Handling with Multi-Element Queries 3.7.1. Multi-Element Query <msg type="query" version="4" xmlns="http://www.hactrn.net/uris/rpki/publication-spec/"> <publish tag="Alice" uri="rsync://wombat.example/Alice/01a97a70ac477f06.cer"> SGVsbG8sIG15IG5hbWUgaXMgQWxpY2U= </publish> <withdraw hash="f46a4198efa3070e" tag="Bob" uri="rsync://wombat.example/Bob/f46a4198efa3070e.cer"/> <publish tag="Carol" uri="rsync://wombat.example/Carol/32e0544eeb510ec0.cer"> SGVsbG8sIG15IG5hbWUgaXMgQ2Fyb2w= </publish> <withdraw hash="421ee4ac65732d72" tag="Dave" uri="rsync://wombat.example/Dave/421ee4ac65732d72.cer"/> <publish tag="Eve" uri="rsync://wombat.example/Eve/9dd859b01e5c2ebd.cer"> SGVsbG8sIG15IG5hbWUgaXMgRXZl </publish> </msg> Weiler, et al. Standards Track [Page 14] RFC 8181 RPKI Publication Protocol July 2017 3.7.2. Successful Multi-Element Response <msg type="reply" version="4" xmlns="http://www.hactrn.net/uris/rpki/publication-spec/"> <success/> </msg> 3.7.3. Failure Multi-Element Response, First Error Only <msg type="reply" version="4" xmlns="http://www.hactrn.net/uris/rpki/publication-spec/"> <report_error error_code="no_object_matching_hash" tag="Dave&
    determine the inside. Looking for discussion around this.quot;
  • Expanded definition on mentions and confusion attacks
  • lastSeen field

Attachments via External Content
New binary format modeled on message/exernal-body RFC 4483
sending client encrypts and uploads
External content encryption
When external content is encrypted

  • with an ephemeral

EKR: They can do a man in the middle attack by replacing the body. It
breaks the end-to-end integrity of MLS
KK: Do you specify how we generate the message ID?
DKG: This is the webbug issue? You can easily discover privacy content
if we do this.
RM: What do you want it to do? It depends on what your client wants /
needs you to do.
DKG: We kick these issues all the time, finally to the user who knows
not much. We are recapitulate this.
CJ: Quotas a really key. DKG is right, and I hate that we kick things
down the road. The transfer of large files will make the RIA shut you
down. Either you need to solve the privacy problem or the large file
problem, but they cannot be simultaneously solved.
MH: Matrix has wrestled with this.
EKR: Blockchain was a joke. It's a problem, and we still have HTML, so
might be difficult to solve the entire problem. Three peopole: sender,
hub and the receiving provider. The more you push it away from sender,
the more you walk down the chain of who needs to know about it.
JL: What would happen if you give the option of receiving very large
message.
RM: This creates queing problems when you can catching up.
RR: You cannot have large messages in a messaging system. The mobile use
cases make this a non-starter
RB: I read jonathan's proposal differently.
Benjamin: Expresses privacy concerns

Sharing messageID and timestamp with providers

  • Content format has messageid and timestamp chosen by encrypting
    client
  • Expose a copy of this in the MLS AAD
  • Local or hub ID can reject on duplicate IDs
  • Message ID is a UUID

EKR: Why are we doing this?
RM: getting two messages simultaneous with the same message ID, because
we use them in replaces and reply-to fields, I can have a message that
refers to it. We need it for replaces.
DKG: Where do we need a non-hash message ID
RM: Clients do get confused and send the same content, at different
times. The timestamp is at encryption time. We do have a problem if they
don't know if they sent a message due to transactional problems.
EKR: Put a pin in this, we can solve that. What does the timestamp do?
RM: This is the time the client encrypted the message. We do need a way
for sort order
Jonathan: Is there a reason you aren't saying that wehave to use a key
commmiting AAD and the issues just go away?

Sort Order of Messages

  • Is consistent rendering of sort order

CJ: Yes, of course you have to have a sort order that is consistent
MH: In matrix land, we go back and forth. We basically do not do this.
Opposite of CJ. We show in order of receipt.
CJ: Everyone needs to see the same thing. The mechanism of ordering is
whatever.
EKR: How do you resolve the partial ordering question?
RM: We have no way ot getting at stuff below MLS, how do we get it from
the client?
DKG: Either we are giving user interface requirements, or we give the
causal order and each client renders> <failed_pdu> <withdraw hash="421ee4ac65732d72" tag="Dave" uri="rsync://wombat.example/Dave/421ee4ac65732d72.cer"/> </failed_pdu> </report_error> </msg> Weiler, et al. Standards Track [Page 15] RFC 8181 RPKI Publication Protocol July 2017 3.7.4. Failure Multi-Element Response, All Errors <msg type="reply" version="4" xmlns="http://www.hactrn.net/uris/rpki/publication-spec/"> <report_error error_code="no_object_matching_hash" tag="Dave"> <failed_pdu> <withdraw hash="421ee4ac65732d72" tag="Dave" uri="rsync://wombat.example/Dave/421ee4ac65732d72.cer"/> </failed_pdu> </report_error> <report_error error_code="object_already_present" tag="Eve"> <failed_pdu> <publish tag="Eve" uri="rsync://wombat.example/Eve/9dd859b01e5c2ebd.cer"> SGVsbG8sIG15IG5hbWUgaXMgRXZl </publish> </failed_pdu> </report_error> </msg> 3.8. <list/> Query <msg type="query" version="4" xmlns="http://www.hactrn.net/uris/rpki/publication-spec/"> <list/> </msg> Weiler, et al. Standards Track [Page 16] RFC 8181 RPKI Publication Protocol July 2017 3.9. <list/> Reply <msg type="reply" version="4" xmlns="http://www.hactrn.net/uris/rpki/publication-spec/"> <list hash="eb719b72f0648cf4" uri="rsync://wombat.example/Fee/eb719b72f0648cf4.cer"/> <list hash="c7c50a68b7aa50bf" uri="rsync://wombat.example/Fie/c7c50a68b7aa50bf.cer"/> <list hash="f222481ded47445d" uri="rsync://wombat.example/Foe/f222481ded47445d.cer"/> <list hash="15b94e08713275bc" uri="rsync://wombat.example/Fum/15b94e08713275bc.cer"/> </msg> 4. IANA Considerations IANA has registered the "application/rpki-publication" media type as follows: Type name: application Subtype name: rpki-publication Required parameters: None Optional parameters: None Encoding considerations: binary Security considerations: Carries an RPKI publication protocol message, as defined in RFC 8181. Interoperability considerations: None Published specification: RFC 8181 Applications which use this media type: HTTP Additional information: Magic number(s): None File extension(s): None Macintosh File Type Code(s): None Person & email address to contact for further information: Rob Austein <sra@hactrn.net> Intended usage: COMMON Author/Change controller: IETF Weiler, et al. Standards Track [Page 17] RFC 8181 RPKI Publication Protocol July 2017 5. Security Considerations The RPKI publication protocol and the data it publishes use entirely separate PKIs for authentication. The published data is authenticated within the RPKI, and this protocol has nothing to do with that authentication, nor does it require that the published objects be valid in the RPKI. The publication protocol uses a separate BPKI to authenticate its messages. Each RPKI publication protocol message is wrapped in a signed CMS message, which provides message integrity protection and an auditable form of message authentication. Because of these protections at the application layer, and because all the data being published are intended to be public information in any case, this protocol does not, strictly speaking, require the use of HTTPS or other transport security mechanisms. There may, however, be circumstances in which a particular publication operator may prefer HTTPS over HTTP anyway, as a matter of (BPKI) CA policy. Use of HTTP versus HTTPS here is, essentially, a private matter between the repository operator and its clients. Note, however, that even if a client/server pair uses HTTPS for this protocol, message authentication for this protocol is still based on the CMS signatures, not HTTPS. Although the hashes used in the <publish/> and <withdraw/> PDUs are cryptographically strong, the digest algorithm was selected for convenience in comparing these hashes with the hashes that appear in RPKI manifests. The hashes used in the <publish/> and <withdraw/> PDUs are not particularly security sensitive because these PDUs are protected by the CMS signatures. Because of this, the most likely reason for a change to this digest algorithm would be to track a corresponding change in the digest algorithm used in RPKI manifests. If and when such a change happens, it will require incrementing the version number of this publication protocol, but given that the most likely implementation of a publication server uses these hashes as lookup keys in a database, bumping the protocol version number would be a relatively minor portion of the effort of changing the algorithm. Compromise of a publication server, perhaps through mismanagement of BPKI private keys, could lead to a denial-of-service attack on the RPKI. An attacker gaining access to BPKI private keys could use this protocol to delete (withdraw) RPKI objects, leading to routing changes or failures. Accordingly, as in most PKIs, good key management practices are important. Weiler, et al. Standards Track [Page 18] RFC 8181 RPKI Publication Protocol July 2017 6. References 6.1. Normative References [RELAX-NG] Clark, J., "RELAX NG Compact Syntax", OASIS Committee Specification, November 2002, <https://www.oasis-open.org/committees/relax-ng/ compact-20021121.html>. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>. [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <http://www.rfc-editor.org/info/rfc4648>. [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, <http://www.rfc-editor.org/info/rfc5652>. [RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI Scheme", RFC 5781, DOI 10.17487/RFC5781, February 2010, <http://www.rfc-editor.org/info/rfc5781>. [RFC6492] Huston, G., Loomans, R., Ellacott, B., and R. Austein, "A Protocol for Provisioning Resource Certificates&

MIMI Design Team Report

Agreed upon previously:

  • signalling is crypto agnostic, but we focus on MLS
  • As few documents as possible
  • Alice and Bob

Four Documents

  • As described above by RM

MIMI Delivery Service

  • Goal: specify a relatively generic MLS delivery service
  • new Interface section with capabilities

    • Ordering of handshake
    • Membership management
    • Proposal-commit logic
    • MLS specific verification
    • Tracking public group state
    • Assistance for joiners
  • Removed specialized add/remove/update operations

  • Now: Propose and Commit operations
  • Simpler interface for use by MIMI procotol

MIMI Protocol

  • Room level operations

    • Signaling basedon events
    • room state changes based on MLS proposals
    • signaling proposals take immediate effect on room state
  • Makes use of MIMI DS

    • Commits anchor room state with

RB: This protocol has a stack of proposals, the delta between the
current state and the future state. These proposals must be committed
before client comes online to commit them.
EKR: I'm confused, you said they would first be removed from MLS, then
moved from the higher level state
MH: Room state includes participant room changes, should we be tracking
items like name or avatar of the room.
TR: We are focusing on messaging list.
DKG: We need to flesh out the states.

Events

  • m.room.user: change a participant list
  • m.room.info: get room info
  • ds.proposal: send MLS proposals
  • ds.commit: send MLS commits
quot;, RFC 6492, DOI 10.17487/RFC6492, February 2012, <http://www.rfc-editor.org/info/rfc6492>. [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <http://www.rfc-editor.org/info/rfc7230>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <http://www.rfc-editor.org/info/rfc8174>. Weiler, et al. Standards Track [Page 19] RFC 8181 RPKI Publication Protocol July 2017 [SHS] National Institute of Standards and Technology, "Secure Hash Standard (SHS)", FIPS PUB 180-4, DOI 10.6028/NIST.FIPS.180-4, August 2015, <http://nvlpubs.nist.gov/nistpubs/FIPS/ NIST.FIPS.180-4.pdf>. [XML] Cowan, J., "Extensible Markup Language (XML) 1.1", W3C Consortium Recommendation REC-xml11-20060816, October 2002, <http://www.w3.org/TR/2002/CR-xml11-20021015>. 6.2. Informative References [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, February 2012, <http://www.rfc-editor.org/info/rfc6480>. [RFC8182] Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein, "The RPKI Repository Delta Protocol (RRDP)", RFC 8182, DOI 10.17487/RFC8182, July 2017, <http://www.rfc-editor.org/info/rfc8182>. [RFC8183] Austein, R., "An Out-of-Band Setup Protocol for Resource Public Key Infrastructure (RPKI) Production Services", RFC 8183, DOI 10.17487/RFC8183, July 2017, <http://www.rfc-editor.org/info/rfc8183>. Weiler, et al. Standards Track [Page 20] RFC 8181 RPKI Publication Protocol July 2017 Acknowledgements The authors would like to thank: Geoff Huston, George Michaelson, Oleg Muravskiy, Paul Wouters, Randy Bush, Rob Loomans, Robert Kisteleki, Tim Bruijnzeels, Tom Petch, and anybody else who helped along the way but whose name(s) the authors have temporarily forgotten. Authors' Addresses Samuel Weiler W3C / MIT Email: weiler@csail.mit.edu Anuja Sonalker STEER Tech Email: anuja@steer-tech.com Rob Austein Dragon Research Labs Email: sra@hactrn.net Weiler, et al. Standards Track [Page 21]