Subject: [Anima] chain of redirections for Cloud Registrar

From: Michael Richardson <[email-masked]>
Date: Sat, 12 Jun 2021 22:22:28 -0400

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-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Michael Richardson <[email-masked]>
Date: Sat, 12 Jun 2021 22:32:20 -0400

> My opinion is that this restriction should not apply.

There is a second problem which I just thought about.
Let me past in the sequence diagram:

    |                                                 |
    | 1. Mutual-authenticated TLS                     |
    |<----------------------------------------------->|
    |                                                 |
    | 2. Voucher Request                              |
    |------------------------------------------------>|
    |                                                 |
    | 3. 307 Location: owner-ra.example.com           |
    |<------------------------------------------------|

    | 4. Provisional TLS   |                          |
    |<-------------------->|                          |

The first TLS connection (1) is to a burnt-in destination.
RFC6125 DNS-ID validatio may be done against an Implicit TA database must be
used to validate the server certificate.

After step 3, the Pledge does not know if it should start a Provisional TLS
connection to the intended Registrar (which would not be verified by Implicit
TA), or if it should attempt to validate owner-ra.example.com against it's
Implicit TA.

One possibility is that in the Cloud Registrar case, if the Pledge *can*
validate the given name against the Implicit TA database that it has, then it
should.   If it does manage to do that, then it can accept another 307
Redirect.  If it can't validate, then it can't accept another 307.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 13 Jun 2021 07:41:18 +0200

>  "another web origin" --- I guess I don't know what this means.

See RFC 6454 "The Web Origin Concept”.

In short, scheme + authority.

>   Does it mean redirecting from https://one.example/foo to https://two.example/bar,

Different origins https://one.example vs. https://two.example

>   or does it refer to https://one.example/foo to https://one.example/bar    etc.

Same origin https://one.example

I don’t like the term that much, but it is in wide use in the combination “Same origin principle”.
In RFC 7252, we use “Origin server” to identify the serving endpoint.
(Of course, “endpoint" has been hijacked as a needless synonym of “resource” in OAuth.)

Somebody should write a Web terminology glossary :-)

Grüße, Carsten

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 14 Jun 2021 18:02:12 +0200

Let me fork off a question:

AFAIK, a 307 redirect can redirect to any other location and not only
a different origin, e.g.:

GET https://mycloudreg.example.com/.well-known/brski/requestvoucher
  -> 307, Location: https://mycloudreg.example2.com/whatthecke/strangeurl

AFAIK, there is no text prohibiting this in rfc8995 (or for that
matter rfc7030).

I don't think such a redirect would work, because the pledge wouldn't know
what the URL for followup commands such as requestvoucher (or any EST
command) would be.

I can see how redirect to other URL prefies than .well-known might
be useful though, even without changing web origin, because some
more complex web server may be built that way, but effectively i
think EST and BRSKI can only work if the redirect location is
cnsistent in its last wo elements:

  GET https://mycloudreg.example.com/.well-known/brski/requestvoucher
  -> 307, Location: /<whatever>/brski/requestvoucher

In this case, the pledge would then extrapolate also
  GET https://mycloudreg.example.com/<whatever>/est/cacerts

Aka: assume both brski and es live under <whatever>

Yes/No/Maybe ?

Cheers
    toerless

On Sun, Jun 13, 2021 at 07:41:18AM +0200, Carsten Bormann wrote:
> See RFC 6454 "The Web Origin Concept???.
> 
> I don???t like the term that much, but it is in wide use in the combination ???Same origin principle???.
> In RFC 7252, we use ???Origin server??? to identify the serving endpoint.
> (Of course, ???endpoint" has been hijacked as a needless synonym of ???resource??? in OAuth.)
> 
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima

-- 
---
[email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 14 Jun 2021 18:09:42 +0200

I think multiple redirects can make a lot of sense, as Mcr said for resale chains for example.
I wouldn't be too bothered with DoS attacks an attepting to come up with a tiny number.
I'd rather go with a number larger than what i can think of being useful. 10 for example.
I could build a load-sharing ring with that ("I am busy, try next") of reasonable size.

I my pet topic of course is diagnostics of non-malicious misconfigs.

So, when a pledge is redirected from
https://domain3.com/.well-known/brski/requestvoucher
 https://domain4.com/.well-known/brski/requestvoucher

Could we make the pledge actually do the get with a breadcrump trail:

 On  https://domain4.com connection:
 GET /.well-known/brski/requestvoucher?brskiredirpath=domain3.com,domain2.com,domain.com

That way, domain4 would know wherer the pledge came from.

Cheers
    Toerless

---

From: Michael Richardson <[email-masked]>
Date: Mon, 14 Jun 2021 13:23:38 -0400

Toerless Eckert <[email-masked]> wrote:
    > AFAIK, a 307 redirect can redirect to any other location and not only a
    > different origin, e.g.:

    > AFAIK, there is no text prohibiting this in rfc8995 (or for that matter
    > rfc7030).

    > I don't think such a redirect would work, because the pledge wouldn't
    > know what the URL for followup commands such as requestvoucher (or any
    > EST command) would be.

For a RF8995-only pledge that was working through a proxy would be unable to
reach another web origin, because the TCP connection is forced to a
particular place.  The pledge can go from /.well-known/brski/requestvoucher
to /whatthecke/strangeurl, as long as the redirect was relative.

Cloud-brski assumes that the pledge has connectivity, so it can go "anywhere"

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Mon, 14 Jun 2021 13:26:00 -0400

Toerless Eckert <[email-masked]> wrote:
    > I think multiple redirects can make a lot of sense, as Mcr said for
    > resale chains for example.  I wouldn't be too bothered with DoS attacks
    > an attepting to come up with a tiny number.  I'd rather go with a
    > number larger than what i can think of being useful. 10 for example.  I
    > could build a load-sharing ring with that ("I am busy, try next") of
    > reasonable size.

I agree: a limit of 2-3 is silly. O(10) is correct.
O(100) is excessive.

    >  On https://domain4.com connection: GET
    > /.well-known/brski/requestvoucher?brskiredirpath=domain3.com,domain2.com,domain.com

Doesn't the HTTP header Referrer include this kind of thing?
Or if not, is there another header?