[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Rescert] Notes from RPKI security review
Thanks for these notes Rob. Here at APNIC we've thought about the points
you've raised here are have the following response.
Rob Austein wrote:
Notes from the RPKI security review we had at NANOG last week.
...
Our security experts told us that our replay protection mechanism was
the first step towards reinventing TLS, that there were further
pitfalls we hadn't thought about, and that we really should just use
TLS and have done with it.
We agree that the potential upside of channel protection is well worth
the TLS overhead, so we agree with the use of TLS here.
- msg_ref can go away entirely now, since replay protection is now
handled by TLS.
agreed - we'll alter the XML schema and the protocol specification
document accordingly
- We want to keep CMS for audit (see discussion December last), but
we're not relying on CMS timestamps for protocol freshness anymore.
Given an understanding that CMS timestamps are optional in CMS is the
timestamp field still a MUST in this instance?
- So the new message format is TLS wrapping HTTP (aka HTTPS) wrapping
CMS wrapping XML.
agreed.
- We need to be just as careful checking TLS certs as we are with CMS
certs. This includes using TLS client certs when building access
control lists. Since I was planning to trace CMS certs all the way
back to the biz trust anchor anyway, this is not a big deal, but we
were cautioned that since the traditional check for client certs is
on the subject name of the client cert (or subjectAltName or
whatever) and that we should be careful about that, particularly
when reusing existing code (eg, Apache).
The CMS certs are the "Business" certs that are exchanged as part of the
establishement of a business relationship between the parent and child.
Can you elaborate on the TLS certs here?
- Using HTTPS means that we should also comply with the HTTPS spec
regarding things like subjectAltName matching DNS name of server
even if they don't buy us anything because of all the other checking
we were doing.
This appears to have some slight implication in terms of hosted
services. If a client, acme.com, wants rpki-hosting.com to host their
rpki engine, then this would be from the HTTPS service point
"service.rpkihosting.com" and this would be the subjectaltname of the
associated https-related certificate.
Russ Houseley and Steve Bellovin both dislike having the sender and
recipient fields in the XML because the real sender and recipient IDs
are the crypto keys used to sign the messages. Russ and Steve are ok
with us saying that the sender and recipient fields are just database
lookup keys that we will use to look up the crypto keys/certs we're
going to check against (ie, mandate tight binding between the XML
identification and the crypto identification) but really want to see
this written in the spec somewhere.
I had thought that that was already the case (written in the spec
somewhere, but we'll review the text. We prefer to retain the sender and
recipient fields int he XML messages.
Everybody at this meeting agreed that the error codes must be
completely nailed down in the protocol spec and that changing the
error codes requires updating the spec. Most people at this meeting
thought that the error codes should be nailed down in the XML schema;
remaining attendees don't much care where the nail is so long as the
error codes are nailed but would want the error codes in the schema if
leaving them out implies that they're in any way not nailed down.
We are in favour of documenting the error codes. We are not in favor of
placing them in the schema. The comment RobL made in our review of this
was: "I believe that placing them in the schema, will make the schema
less useful in production, particularly for the client/child. For
pragmatic purposes, you would have to use a cut down version of the
schema that omitted the error codes."
All three security experts (Russ and both Steves) want all the stuff
in the XML portion of the list_class_response that just duplicates
stuff that's already in the ASN.1 removed. Reason for this is that if
it's in two places it either (a) has to be cross-checked right away or
(b) one has to do same checking later with state to remember the stuff
one was supposed to check. In either case, one has to commit the
layering violation that this duplication was intended to avoid, so
there's really no point in the duplication.
It may not be a "layering violation", but it certainly was duplication
of information, and the case where the information differs was intended
to be an error condition. We can live with this stripped out of the XML.
Steve Bellovin wants a document on how one rebuilds repositories after
a catastophe (eg, are there operations involving multiple parties that
can only be performed in a particular order?)
We recognise the situation, but we are not putting our hand up to write
this anytime soon. Is anyone else willing to do so?
Russ and Steve Kent really want preaggregated cache service available
from somebody; RIRs are obvious candidates. The ARIN folks at this
meeting said that ARIN intends to offer one, dunno about any of the
other RIRs.
This has been in APNIC's plans for over a year now!
Russ would like a picture corresponding to the "entity decompose"
picture (the one Randy put on the t-shirt) but showing the boxes from
the relying party's point of view.
But the relying party is performing validation operations. This request
is unclear to us. It would appear to be a sequence of certificate
retrieval operations culminating in a recognition of a trust anchor.
Steve Kent says that the route-origin in my object model (and
left-to-right protocol, and Tim's SQL) doesn't need to support ranges,
only prefixes, because that's the way ROAs are going. ROAs need to
map to routing, which does prefixes. Much rejoicing from Tim.
This may well be the case for ROAs as defined in the context of the IETF
SIDR WG standadization activity. In the more general case of signing a
document with a resource certificate the full capability of expressions
in RFC3779 is envisaged here.
Russ noted that there's an optional seconds-since-epoch representation
for timestamps in CMS which we might prefer over the default, but it
may not be implemented in OpenSSL yet. I may implement it if it's not
a lot of work but it doesn't look like anything that's on our critical
path. The new timestamp format is in RFC 4049.
Given an understanding that in CMS the timestamp is optional and the CMS
timestamp is not used for any particular purpose, then its hard to
understand the context of this.
Questions APNIC asked us to ask, with answers:
At Fri, 11 May 2007 17:24:01 +1000, Geoff Huston wrote:
Regarding the proposed meeting on aspects of attack and protocol aspects of
resilience of attack with Steve Bellovin and Russ Housley at NANOG early
next month. Yesterday Randy asked us for any issues that we thought should
be covered from our (APNIC's) perspective in this meeting.
There are a number of items (most of which we suspect that you are already
well across!):
a) is msg_ref + CMS timestamp 'good enough' for replay attack protection?
No. Use TLS.
understood
b) is preserving strict order of processing important? (we believe it is,
but we could be off track here!)
Yes, preserving ordering is important.
yes.
c) is visible disruption of the message exchange harmful?
Yes. Use TLS.
Given that the disuption would be visible to one or the other parties
then its not clear what damage could occur that would not be noticed by
the paries, but in the light of TLS this is uninportant.
d) is parallelizing of requests by the child "unwise", "extremely unwise"
or "DON'T"?
DON'T.
Evidently then we need to note in this in the protocol specification.
If we have an old idle connection and get a new connection, we can
probably just kill the old one (but define "idle", and don't kill the
old connection until the new one has passed authorization checks (see
"use TLS")).
noted
e) channel security: APNIC has this current model of the up/down protocol
that uses https, using same key/cert as CMS inside object. This
probably isn't good (or is it acceptable practice?). It appears to us
that the other choices lead to key/cert explosion in business key/cert
space. Is it ACCEPTABLE to use a single key for both
Security guys says this is acceptable. Might require multiple
subjectAltNames (one for each context) but that's ok.
noted
f) the replies are CMS encrypted. What is the key and cert in the response?
s/encrypted/signed/. Other than that, it's just the responder's
business key/cert.
noted
g) is channel security necessarily two-way protected, or (using https as
the model) is it acceptable to have only server-side keying?
HTTPS spec does not require client certs, but our usage does require
both client and server certs.
So this is 2-way certs - noted.
thanks for this Rob
Geoff, George, Rob L and Byron.
