[Anima] chain of redirections for Cloud Registrar

[Michael Richardson <[e-mail]>]

Owen, Rifaat, and WG,

In writing the Security Considerations section of draft-ietf-anima-brski-cloud,
I realized that there is a case we have been thinking about, but that we
didn't clearly write down.

We support two methods of redirect: 307 redirect and voucher based redirect.
The first method allows a Pledge to find a BRSKI capable Registrar at which
it starts the normal voucher-request/voucher process.
The second method allows the Cloud Registrar to process a voucher request
and then redirect the Pledge to an EST-only capable Registration Authority.

The questions are two:

1) do we allow multiple layers of 307 redirect?  This can be pretty powerful
   as it allows a manufacturer to just know which regional distributor they
   resold to, and the distributor knows which VAR, etc.

   If so, I guess we need to establish some limit to how many redirects we allow.
   BRSKI says some things at section 5.6 about limiting redirects to one.
   My opinion is that this restriction should not apply.

   I think that the section 5.6 which says:
      In order to avoid infinite redirect loops, which a malicious registrar
      might do in order to keep the pledge from discovering the correct
      registrar, the pledge MUST NOT follow more than one redirection (3xx
      code) to another web origin. EST supports redirection but requires user
      input; this change allows the pledge to follow a single redirection
      without a user interaction.

   "another web origin" --- I guess I don't know what this means.
   Does it mean redirecting from https://one.example/foo to https://two.example/bar,
   or does it refer to https://one.example/foo to https://one.example/bar    etc.
   In non-cloud enrollment, the join proxy forces the pledge to a particular
   destination, so the "one.example" can't meaningfully change to
   "two.example" (although both could be on the same TLS port.

   {actually, it occurs to me that we don't say what the pledge should put
   into the Host: header, and this issue hasn't come up for me, because I
   seldom get to test via a real join proxy.  The corollory is that actually
   Registrars can not use HTTP Host: virtual hosting, *or* SNI Virtual Hosting,
   because they must accept all values of Host:}

2) do we allow for one or more 307 redirect, followed by a voucher based
   est-domain redirect to an EST server?
   It seems like a good idea to me.

--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide