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 <[email protected]> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
