Hi Mike, As the Pledge may be redirected to an Owner Registrar that follows the standard BRSKI guidelines, the guidance in https://datatracker.ietf.org/doc/html/rfc8995#section-5.6 applies
This is the PR that we believe clarifies behaviour: https://github.com/anima-wg/brski-cloud/pull/255 Thanks for the review. Owen From: Mike Bishop <[email protected]> Sent: Friday 22 August 2025 16:28 To: Michael Richardson <[email protected]> Cc: The IESG <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected] Subject: Re: [Anima] Mike Bishop's Discuss on draft-ietf-anima-brski-clou d-16: (with DISCUSS and COMMENT) Looking for that general guidance, which may well be a single sentence. You already have it for 4xx and 5xx responses (bootstrapping error, indicate and retry later). Doing some checking of your references, I see that EST has this language: HTTP redirections (3xx status codes) to the same web origin (see [RFC6454<https://www.rfc-editor.org/rfc/rfc6454>]) SHOULD be handled by the client without user input so long as all applicable security checks (Sections 3.3<https://www.rfc-editor.org/rfc/rfc7030.html#section-3.3> and 3.6<https://www.rfc-editor.org/rfc/rfc7030.html#section-3.6>) have been enforced on the initial connection. The client initiates a new TLS connection and performs all applicable security checks when redirected to other web origin servers. Redirections to other web origins require the EST client to obtain user input for non-GET or HEAD requests as specified in [RFC2616<https://www.rfc-editor.org/rfc/rfc2616>]. ...which is updated in BRSKI: 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. Your draft currently allows the pledge to follow multiple redirects so long as they don't loop and they're specifically 307 versus any other 3xx code; I'm just looking for something that says which of these behaviors applies to any other 3xx code should the pledge encounter one. Reasonable options I see are: · Registrars send 307 specifically, but pledges follow any number of redirects of any variety provided all the connections pass security checks · Only 307 has the special property of chasing multiple redirects, and any other redirect to a different origin is limited to one (per BRSKI) · Only 307 is a valid redirect for this scenario and any other 3xx code is a bootstrapping failure I lean slightly toward the first one, but they're all defensible. The draft just needs to pick one. ________________________________ From: Michael Richardson Sent: Wednesday, August 20, 2025 10:09 PM To: Mike Bishop Cc: The IESG; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: Re: [Anima] Mike Bishop's Discuss on draft-ietf-anima-brski-clou d-16: (with DISCUSS and COMMENT) Mike Bishop <[email protected]<mailto:[email protected]>> wrote: > Apologies - I think I dropped the ball on getting back to you about > this one. The PR looks good, modulo text about handling of other > redirect codes. > I'm used to 201+Location to refer to a *unique* place that should be polled > (GET,HEAD,If-*) to get the result. But, at each step, Cloud Register X does > not know what the unique URL for Cloud Register X+1 would be. > 307 seems the correct answer to me. Go *THERE* and do a POST. MB> Using 307 for your expected flow is fine. You still need to specify MB> what should happen with other status codes, since HTTP in general MB> (intermediaries, etc.) might still encounter them in the wild. It's HTTPS, so there are not really any unknown/authorized intermediaries. There is a concern with captive portals, but they do a forced proxy and certificate failure before they can send a 3xx. The rest of the 3xx redirects would mostly seem to be invalid. If they redirect within the same authority, I guess that's fine. If they redirect to another authority, it would be mostly wrong. Is a single sentence saying the above what you are looking for? >> { >> Note that we avoided 418. We really wanted to :-) >> Well, technically it would have been: "You are teapot" >> } MB> Maybe the pledge could use it from its management interface. One MB> of the few areas of the IETF that could realistically specify a use for MB> 418! > NO SIR! I can also Brew expresso-sized Cappacinos! > (as the machines in Madrid seemed to be...) Saw this video today on the TV during lunchtime. https://www.youtube.com/watch?v=aqsEa1P8iPQ Henk did not cover 451, which everyone felt he should have. -- Michael Richardson <[email protected]<mailto:[email protected]>> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
_______________________________________________ Anima mailing list -- [email protected] To unsubscribe send an email to [email protected]
