Subject: Re: [sidr] Working Group Last Call - draft-ietf-sidr-rescerts-provisioning-05.txt

From: Rob Austein <[email-masked]>
Date: Sun, 01 Nov 2009 14:46:36 -0500

Terry,

General comments only, I'm not going to attempt a point by point
response on a beautiful autumn Sunday when my kids want to go play
minigolf.

The combination of TLS and CMS was the result of advice the design
group got from Steve Bellovin, Steve Kent, and Russ Housley when Randy
and I asked them to review this protocol, back in 2007.  The two
mechanisms serve different purposes.

We use CMS for authentication and authorization (is the entity
requesting this action authorized to do so? etc).  It's also intended
to allow for audit: if one is paranoid, one can archive a copy of
every CMS message and use it (along with archived PKI material) to
prove at some later date that the action was properly authorized.  So
I view CMS as the main security mechanism here, and the one that's
most closely aligned with the underlying semantics.

TLS is present mostly to protect against replay attacks and other
naughtiness.  Our advisors saw our initial attempts to include replay
protection in the CMS-signed XML messages and advised us to use
existing technology (ie, TLS) instead, which makes some sense.  TLS
also provides privacy (which it's not clear we need), and helps to
limit denial of service attacks to known entities.

At this point, having written my own HTTPS implementation and seeing
how weak (read: effectively nonexistant) the concept of a session is
in HTTPS, I'm not convinced that TLS is providing all that much in the
way of useful replay protection.  At this point, though, we do have
multiple interoperable implementations of this protocol using TLS, so
unless it's actively harmful I'd just as soon leave it alone for now.

FWIW, though, at least in my implementation, all the AAA logic is tied
to CMS, not TLS.

The PKI used for this (both CMS and TLS) is not the RPKI, it's a
separate PKI (which the design group has been calling the "BPKI",
because it mirrors the business relationships between
certificate-generating entities).  In the abstract, the BPKI can be
anything that both parties to a particular conversation are willing to
use, as this is only used in pairwise conversations and doesn't
transit to third parties.  The main thing is that the parent in a
parent-child relationship gets to dictate the BPKI model to be used:
this pretty much falls out of the hierarchical nature of the system.
So my implementation, at least, has a particular model that I use when
I'm the parent, and is (I hope) flexible enough to handle whatever
model my parent might be using when I'm the child.   I can go into
more detail on the model I'm using, but I'm not sure that the WG
really needs to sign off on that level of detail.

The protocol nesting is tedious but straightforward:

   IP(TCP(TLS(HTTP(CMS(XML(up-down))))))

As far as different security models between this and the rest of the
RPKI system: the difference is less extreme than it might at first
appear.  Other than the TLS wrapper discussed above, everything is
object security, using either CMS or X.509-derived objects which were
signed to begin with.

Hope this helps.

--Rob

---

From: Terry Manderson <[email-masked]>
Date: Sun, 1 Nov 2009 17:56:37 -0800

Hi Rob,

> requesting this action authorized to do so? etc).  It's also intended

Ack.

> most closely aligned with the underlying semantics.

Right, I also have a similar PoV. Although, and it may be an academic
distinction - my reading is that if the XML operations are not truly
idempotent then the 'CMS Signing Time' would have been a more pragmatic
implementation.

Was that analysis done? (apologies if it was, I quickly checked list
archives but couldn't see if the question had been asked)

> protection in the CMS-signed XML messages and advised us to use

o.k. BTW is the rescerts-provisioning-05 RFC4346 is specified. RFC4346 is
obsoleted by RFC5246.

So if you do authentication and authorisation in the CMS, why do you need 2
way identification at the HTTPS layer if it's just for privacy?

ie authentication of both parties versus server authentication with an
unauthenticated client? (RFC5246 App F.)

> existing technology (ie, TLS) instead, which makes some sense.

... I'm not sure why though.. :-( Maybe you can explain that to me over a
beer.

> TLS

ummm Does it? 

> unless it's actively harmful I'd just as soon leave it alone for now.

Maybe just a refocus on ''why'' TLS is used, and to what extent, given other
architecture parts.

> FWIW, though, at least in my implementation, all the AAA logic is tied

Yes.. and having run your code I see that, which is why I ask some of the
questions.

> separate PKI (which the design group has been calling the "BPKI",

Maybe a clarification then required so people don't start trying to plug
RPKI certs into provisioning engines for CMS?

> really needs to sign off on that level of detail.

I think something, at some stage, might need to be documented given that the
BPKI (as you put it) seems to be a first order layer for the conversation.

(although note my comments above about the necessity for 2-way
identification given the authentication/authorisation is done in CMS)

>    IP(TCP(TLS(HTTP(CMS(XML(up-down))))))

So, given that ASN.1 is fully capable of describing the data going back and
forth (up/down). Why add the extra XML blob?

btw, I think the draft needs to also reference the ITU' (nee CCITT)
Recommendation X.208: Specification of Abstract Syntax Notation One (ASN.1).

> object security, using either CMS or X.509-derived objects which were

thinking from a different point of view - noting that the draft is using
HTTPS with identification of server and client, for replay and privacy - why
not consider the W3Cs XML Signature Syntax?

> Hope this helps.

Sure does.

Hope you had fun playing mini-golf.

Terry

---

From: Stephen Kent <[email-masked]>
Date: Mon, 2 Nov 2009 11:07:40 -0500

Folks,

I want to add a few comments to Rob's message about use of CMS and 
TLS for the up/down protocol.

As Rob noted, Russ and I suggested this combination of protocols for 
use here. CMS provides the base security for transactions, affording 
integrity and authenticity via the signature applied to the CMS 
payload. TLS offers an opportunity to implement a coarse level of 
access control, and session-level integrity, authentication, and 
anti-replay, with confidentiality as a side-effect (that may or may 
not be needed).

I am not sure what motivates Rob to say that he is not convinced 
about the extent of the session security offered by HTTPS. (Is it 
related to the session resumption feature in TLS?) Anyway, by using 
TLS one can restrict access to repository serves to the set of 
entities to whom certs have been issued in the BPKI, which is 
potentially helpful.

Steve

---

From: Rob Austein <[email-masked]>
Date: Mon, 02 Nov 2009 11:49:55 -0500

> idempotent then the 'CMS Signing Time' would have been a more pragmatic

Don't think I follow.  CMS profile for this draft specifies use of
signing time (and, optionally, binary time).  You need a signature
that covers both the timestamp and the dated material to be audited,
which this profile provides.

Am I missing something?

> way identification at the HTTPS layer if it's just for privacy?

TLS without checking signatures gives you a secure channel to an
unknown entity.  Professor Moriarty speaks TLS too.

> forth (up/down). Why add the extra XML blob?

Primarily because there is running code using XML, secondarily because
XML is somewhat easier to code and debug.

> thinking from a different point of view - noting that the draft is
> using HTTPS with identification of server and client, for replay and
> privacy - why not consider the W3Cs XML Signature Syntax?

Considered and rejected, because it's broken.  The XML world doesn't
really have the concept of a single canonical format, and the attempt
to reconcile that world view with the requirements of digital
signatures resulted in a protocol in which otherwise valid signatures
can fail to validate because of disagreements about the canonical form
of the signed data.

---

From: Rob Austein <[email-masked]>
Date: Mon, 02 Nov 2009 12:19:24 -0500

At Mon, 2 Nov 2009 11:07:40 -0500, Steve Kent wrote:
> related to the session resumption feature in TLS?)

Nope.  It's related to HTTP not really having any such thing as a
session to protect.  It is of course possible that we all (or perhaps
just I) misunderstood your advice, in which case please expound.

---

From: Stephen Kent <[email-masked]>
Date: Mon, 2 Nov 2009 16:45:37 -0500

>just I) misunderstood your advice, in which case please expound.

In the TLS context I think of a session as the set of traffic sent 
after the TLS handshake completes and before a new handshake occurs, 
between the same pair of IP addresses.  Yes, there is no explicit end 
of session message in TLS, which makes it hard to define the end of a 
session. However, if a server times out an inactive session, the 
client will need to perform a handshake to re-establish it, so there 
is an opportunity for the server to unilaterally end a session at any 
time. Since the goal of using TLS here is to help protect servers, 
this seems like a reasonable strategy. (And as I noted above, a 
session resumption request by a client can always be rejected by a 
server.) Any received traffic that is not protected under the keys 
established at the start of the session will be rejected. I assume 
that a new handshake should cause the old keys to be replaced. So the 
server is well-positioned to decide when a session has ended.

Is your point is that the handshake imposes a crypto processing 
burden on the server, and that this reduces the DoS benefits? Note 
that there there are a number of hardware options available to 
off-load the processing associated with the handshake.

Steve

---

From: Rob Austein <[email-masked]>
Date: Mon, 02 Nov 2009 17:23:31 -0500

> server is well-positioned to decide when a session has ended.

I think we are talking slightly past each other, and have been on this
topic all along.  I said "HTTP", you seem to have read "TLS".

HTTP has no real notion of a session.  Even with persistent HTTP
connections, the server is free to blow away the connection after the
first request/response cycle completes.  There's some attempt at
letting the server tell the client what timer value the server is
using, but between the mishmash of HTTP versions doing things
different ways and the ad hoc nature of early attempts to support
persistent connections, the advice I was able to find all said to
ignore that.  So all a client can really do is request a persistent
connection if for some reason it wants one, and hope for the best.

This means that a client can't rely on the server ever leaving the
connection open for more than one request/response cycle, so the
notion of insisting that a series of request/response cycles MUST
happen in the same "session" to avoid replay is a bad fit.  Wrapping
HTTP in TLS doesn't fix HTTP's weird semantics.

Most web-based protocols that implement sessions do so on top of this
entire mess, using cookies or URL tricks or application data.  At the
moment we're not doing any of that.

Remember that the reason we were originally told to use TLS here was
replay protection.  I know you keep saying server protection, but
that's not how we originally got here.  I'm not seeing much replay
protection in what we've implemented to date, which concerns me, as we
added a fairly heavyweight mechanism that as far as I can tell has not
solved the original problem.

My implementation uses OpenSSL's TLS code directly, thus I could, in
theory, peek at TLS session data structures and hook into OpenSSL's
TLS callbacks to figure out whether this is the same TLS session or
not, using your definition of "session" (above).  Sounds a bit
painful, but is probably doable.  Question is whether it's worth it,
or whether there's some better way to handle the threats.

I'll let APNIC speak to how much of a problem this would be for them.

---

From: Stephen Kent <[email-masked]>
Date: Mon, 2 Nov 2009 17:56:39 -0500

At 5:23 PM -0500 11/2/09, Rob Austein wrote:
>...

What Russ and I proposed was TLS, so that's why I am talking about TLS.
I'm not sure when the suggestion to use TLS was translated into HTTPS.

>...

My recollection differs somewhat. I think what Russ and I suggested 
was using TLS to enable session-level protection, which includes 
two-way authentication at
the time of session creation (as an input to access control for the 
server), session integrity (i.e., dropped or re-ordered packets are 
detectable), and session authentication (i.e., all packets belonging 
to the same session are verified as such). Anti-replay at the session 
level and within a session are two facets of this protection suite.

Steve

---

From: Rob Austein <[email-masked]>
Date: Mon, 02 Nov 2009 18:27:46 -0500

> I'm not sure when the suggestion to use TLS was translated into HTTPS.

The protocol you reviewed back in 2007 was already running over HTTP,
so when you started talking about TLS, everybody interpreted it in the
context of the existing HTTP-based protocol and heard it as HTTPS.

> two-way authentication at the time of session creation (as an input
> to access control for the server), session integrity (i.e., dropped
> or re-ordered packets are detectable), and session authentication
> (i.e., all packets belonging to the same session are verified as
> such). Anti-replay at the session level and within a session are two
> facets of this protection suite.

I assume you mean PDUs throughout here, not IP packets.  Your
description makes some sense, but is not what I think we heard at the
time.  I think you're more concerned about channel-level access
control here than I am (as I said to Terry, the access control I care
about all hinges on the CMS signatures).  It is of course possible
that you're right about this and I'm wrong.  In any case, I agree that
if we had done what you describe here, replay protection would have
fallen out of it as one of the consequences.

But the real question now is where do we go from here, given that we
have interoperable implementations that didn't do it this way.

Do you agree with my concern that what we ended up doing does not
provide replay protection?

---

From: Stephen Kent <[email-masked]>
Date: Tue, 3 Nov 2009 11:51:09 -0500

>context of the existing HTTP-based protocol and heard it as HTTPS.

Fair enough.

>..

yes, I mean PDUs, since TLS runs on top of IP and TCP.

>provide replay protection?

Not sure that I do.

I understand your comment that HTTP per se has no real session 
flavor. Not surprising since it was designed to support stateless 
query/response exchanges.  That was changed as cookies were added to 
enable better support of state, without changing the base protocol in 
a fundamental way. I am not enough of
an HTTP guy to know what are appropriate ways to get the session 
flavor that we want, taking advantage of the TLS/HTTPS combination. 
I'm tempted to suggest use of IPsec, but I'm biased :-).

Steve

---

From: Byron Ellacott <[email-masked]>
Date: Mon, 30 Nov 2009 09:45:45 +1000

Hi Terry,

On 30/10/2009, at 2:00 PM, Terry Manderson wrote:

> Oppose..
> 
> Firstly, my initial observation is that the 'XML in ANS1 in CMS (signed)'
> transported in mutually validated and authenticated(*) HTTPS/TLS sessions
> appears somewhat weighty to cover MiTM/Repla given other parts of the entire
> RPKI system don't seem to have been given the same attention and remain
> untrusted?
> 
> (*) you mean cross-certified? or some other way of mutually authenticated?

I think this has already been sufficiently discussed by the WG, I won't add further to it here.

> Secondly, since this uses a PKI of some description, where is the
> description of the PKI (and CP?) for the signing of the CMS blobs and the
> PKI (and CP) for the TLS sessions. Are they the same? not the same? RPKI
> certs used? etc.

This is addressed in the final bullet point of section 2, which states that this is outside the
scope of this specification. I believe Rob also addressed this in his earlier response.

> Are there multiple fully interoperable server and client codebases based on
> this? Why I ask is the XML and the basic operations (list, issue, revoke) is
> simple enough - the killer space would be getting the multiple signing
> events right. ie which cert is used for the CMS, which is used for the TLS..
> and the ASN.1/CMS combo in order.

Again I believe Rob has talked about this.

> lastly, the draft suggests "the server MUST NOT accept a client's request
> unless it has generated and sent a response to the client's previous
> request" - it appeard the _assumption_ made is that the client deals with
> the resources of only one entity. What if it deals with more? What if the
> ISP is representative of multiple organisations and wishes to do multiple
> updates in parallel?

The terminology in section 1.1 defines a client as a unitary resource holder.  If one ISP is representative of multiple entities it will take the part of multiple clients.

> section 3.2:
> 
> Please specify here the version of XML schema that this draft in its common
> message format uses (not just describes) and the section (section 4) that
> contains the xml schema. I think that it needs to be done prior to the
> introduction of the template and template values.

The document notes in section 4 that this is a "RelaxNG compact form schema". For future note, should it become necessary to provide a reference to this schema, http://www.relaxng.org/compact-20021121.htmlis the syntax specification document for RNG-C.

> http://www.apnic.net/specs/rescerts/up-down/ responds with a 404 (a pretty
> 404, but a 404 nevertheless) So the namespace is invalid.

The relevant observation here is that in XML the "namespace name, to serve its intended purpose, should have the characteristics of uniqueness and persistence. It is not a goal that it be directly usable for retrieval of a schema (if any exists)." [Section 3, "Declaring Namespaces", http://www.w3.org/TR/xml-names/]

> I think I would like to see a summary table of all of the HTTP response
> codes used by this protocol.

Its not clear how a reproduction of section 10 of RFC2616 would assist the reader of this document.

> Section 3.5.1
> 
> Looks like a wayward "]":
> 
>        ski="encoded hash of the subject public key]" />

Noted as a nit to be corrected in the next version.

Thanks,
  Byron

_____________________________________________________________________

Byron Ellacott                         email:           [email-masked]
Technical Area Manager, APNIC          sip:        [email-masked]
http://www.apnic.net                   phone:         +61 7 3858 3100

---

From: Terry Manderson <[email-masked]>
Date: Sun, 29 Nov 2009 19:27:24 -0800

Byron,

On 30/11/09 9:45 AM, "Byron Ellacott" <[email-masked]> wrote:

[..]
> The terminology in section 1.1 defines a client as a unitary resource holder.

I just re-read section 1.1 and I did not see the words you write above.

I note that it does say the ISP assumes the role of the client, and the ISP
is the subject of a resource certificate. I think that definition should be
made clearer that it is singular relationship. (ie I would much rather your
words above in the terminology)

> If one ISP is representative of multiple entities it will take the part of
> multiple clients.

What I _think_ you mean is if one ISP is representative, but not necessarily
the subject of, multiple resource certificates.

I highlight this as while you moot that the CA which drives the https/CMS
signing the client definition is bonded to the resource certificate -
efficiencies of issuing https/cms certs can be made.

> The document notes in section 4 that this is a "RelaxNG compact form schema".
> For future note, should it become necessary to provide a reference to this
> schema, http://www.relaxng.org/compact-20021121.htmlis the syntax
> specification document for RNG-C.

I think you missed my initial point. I'm after a brief intro at sections 3.2
telling me there is a complete schema v1 at section 4, of which of which
these templates are derived from. It seems disjointed to me to start
introducing XML templates without letting me know that a full schema exists
just 10 pages ahead.

Additionally, since you provide a reference for RelaxNG, no such reference
exists in the references section of the draft. Please correct.

> The relevant observation here is that in XML the "namespace name, to serve its
> intended purpose, should have the characteristics of uniqueness and
> persistence. It is not a goal that it be directly usable for retrieval of a
> schema (if any exists)." [Section 3, "Declaring Namespaces",
> http://www.w3.org/TR/xml-names/]

ack.. although people expect it. ie no-one cares if you do, it's just
irritating if you don't. (ie great, I can grab it from there with a wget and
not have to cut-n-paste with clean-up from the ID)

> Its not clear how a reproduction of section 10 of RFC2616 would assist the

Are you saying that all the current implementations of server and client use
all the HTTP error codes? including redirection? 206 partial content? (which
would invalid in the CMS structure??)

Why would the server generate a 502 bad gateway? Answer - it wouldn't /
shouldn't act as a gateway.. So to eliminate all those silly possibilities
you wouldn't need to reproduce the entire section 10. Just the ones that are
actually used in earnest.

The document mentions only one error code. "HTTP 400 Bad Data" .. Are you
intentionally diverging from RFC2616's "400 Bad Request"? ..

and in my mind by only seeing one http error code mentioned - it draws my
mind to the "is that it?" question. (hence why I asked for a summary)

My guess is that the response/error code list would be a small list and
worth the effort.

> Noted as a nit to be corrected in the next version.

Thanks

Terry

---

From: Randy Bush <[email-masked]>
Date: Mon, 30 Nov 2009 15:13:58 +0900

> is the subject of a resource certificate.

what is the client is not an isp, e.g. an RIR, NIR, end site, ...?

randy

---

From: Byron Ellacott <[email-masked]>
Date: Mon, 30 Nov 2009 16:28:48 +1000

Hi Randy,

> what is the client is not an isp, e.g. an RIR, NIR, end site, ...?

I'm using the current terminology of the document to discuss Terry's concerns, but we will be changing to the terminology of "Subject" and "Issuer" in the next version of the document.

This is noted at: http://trac.tools.ietf.org/wg/sidr/trac/ticket/5

  Byron