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) |
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
- They have a state, has a components of
-
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