<div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Responses in no particular order:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">- in general the language in SSO encourages use of TLS (https) when sending senistive info but does not ban http</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">- I am probably to blame for that #BasicAA securityMethod in the first place (we started using a <a href="http://w3.org">w3.org</a> URL that ended in #BasicAA way back) and I think it has to be taken to mean basic and not digest. Do we need a #Digest? see below</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The paragraph at the end of section 3 (before 3.1) says that in general service endpoints should be using #Oauth, #cookie, #tls-with-certficate and/or allow anon. Special "login" endpoints where you get such tokens (oauth and cookie) should be using #tls-with-password, #tls-with-certifcate, and/or #saml2.0 -- you will note that #BasicAA doesn't appear anywhere in this recommendation! I think it is for all the same reasons that TAP-1.1 was hard and we had that meeting in Trieste :-)</div><div class="gmail_default" style="font-size:small">It could be because #BasicAA is inherently the opposite of SSO (!single : you sign in every time) but I think that paragraph is just somewhat more prescient about the way things would/should go.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">So, SSO also seems to leave #BasicAA off to the side as the thing that doesn't fit the big picture. That probably doesn't help client writers come up with a strategy but I would say to keep the concepts in that paragraph in SSO in mind as it captures the way things will work now and in future.<br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Aside: One thing that is seems missing is an actual spec for #tls-with-password. When I read section 7 it says the username and password are passed in the message body but doesn't specify exactly how (2 params? 2 parts with separator? simple doc format?). Now that I read it again, 7.2 really confuses me :-) Anyway, I have some ideas on what to do with this issue that are related to another email thread on standardising "login" to an SSO realm.<br></div><div class="gmail_default" style="font-size:small"><br clear="all"></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div>--<br></div><div>Patrick Dowler<br></div>Canadian Astronomy Data Centre<br></div>Victoria, BC, Canada<br></div></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 2 Apr 2019 at 03:45, Mark Taylor <<a href="mailto:M.B.Taylor@bristol.ac.uk">M.B.Taylor@bristol.ac.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi GWS.<br>
<br>
I'm looking at the SSO 2.0 standard, specifically section 4,<br>
"HTTP Basic Authentication", and there are some points I would like<br>
to have clarified. The text says this:<br>
<br>
"Services using HTTP basic authentication SHALL use the authentication<br>
mechanism described in the RFC7235 (Fielding, 2014) that updates<br>
RFC2617 (Franks and Hallam-Baker et al., 1999). Interfaces using this<br>
mechanism SHALL be registered with the security method<br>
ivo://<a href="http://ivoa.net/sso#BasicAA" rel="noreferrer" target="_blank">ivoa.net/sso#BasicAA</a>"<br>
<br>
But the RFCs referenced here don't really match the text.<br>
<br>
RFC 2617 defines approximately three things:<br>
<br>
[A]: challenge/response framework, i.e 401 HTTP response etc (section 1)<br>
[B]: Basic authentication scheme (section 2)<br>
[C]: Digest authentication scheme (section 3)<br>
<br>
RFC 7235 on the other hand really just talks about [A].<br>
RFC 2617 is obsoleted by more than one document, in particular:<br>
<br>
[A]: discussed in RFC 7235<br>
[B]: discussed in RFC 7617<br>
[C]: discussed in RFC 7616 (and maybe RFC 7615)<br>
<br>
The Commentary section 4.2 in SSO is not particularly clearly worded,<br>
but from the text:<br>
<br>
"The 'HTTP basic authentication' SHOULD be used with particular <br>
attention as sensible information (password) are sent over the <br>
wire in base64 encoding"<br>
<br>
it seems that it is talking specifically about [B]. At the least<br>
therefore, I think that SSO section 4 ought to include a reference<br>
to RFC 7617 instead of, or possibly as well as, RFC 7235.<br>
<br>
Even so however, I'm still not certain exactly what is required from<br>
a service that declares a SecurityMethod ivo://<a href="http://ivoa.net/sso#BasicAA" rel="noreferrer" target="_blank">ivoa.net/sso#BasicAA</a>.<br>
In particular, does it have to use the "Basic" authentication scheme <br>
([B]), or is it permitted to use "Digest" ([C]) or other non-standard<br>
authentication schemes permitted by the HTTP authentication <br>
framework ([A])? I'm guessing that [B] is required, but it would <br>
be nice to have this made explicit in the text.<br>
<br>
Thinking further along these lines: if BasicAA does indeed mandate [B],<br>
maybe we should add another SecurityMethod option for the Digest <br>
authentication scheme [C]. Although the authors of RFC 7616 are at<br>
pains to point out that Digest authentication is not a total solution <br>
to security over HTTP(S), it does provide user/password authentication <br>
without sending passwords over the wire, so it's a whole lot better <br>
than Basic, it likely provides security strong enough for the kind<br>
of thing astronomers (and maybe even data centers) care about, and<br>
it's probably a lot less effort than something like OAuth. I'm not<br>
necessarily advocating this, since another Auth option becomes another<br>
implementation burden for client authors, but it could be worth<br>
bearing in mind.<br>
<br>
While I'm griping about this section, some clarification about use of TLS<br>
would be nice too; it currently says "Connection secured with TLS are<br>
RECOMMENDED prior to exchanging any credentials." I *think* what it<br>
means is that if you're using BasicAA it's a good idea to do it over<br>
HTTPS rather than HTTP, but I'm not certain.<br>
<br>
Mark<br>
<br>
--<br>
Mark Taylor Astronomical Programmer Physics, Bristol University, UK<br>
<a href="mailto:m.b.taylor@bris.ac.uk" target="_blank">m.b.taylor@bris.ac.uk</a> +44-117-9288776 <a href="http://www.star.bris.ac.uk/~mbt/" rel="noreferrer" target="_blank">http://www.star.bris.ac.uk/~mbt/</a><br>
</blockquote></div>