Subject: Re: [http-auth] rev'd charter-like text

From: Yaron Sheffer <[email-masked]>
Date: Tue, 13 Nov 2012 22:38:01 +0200

Hi Stephen,

I'm surprised that "authentication of devices or components of web 
services" is out of scope. Much of the world is not doing OAUTH for 
different reasons. And much of the world is using Basic Auth (over SSL) 
to authenticate web APIs. Just one example I came across today: the REST 
API into IBM's public cloud.

In fact I believe this is the only important use case for Basic Auth. 
For such services, an update to something more attractive (digest-SHA256 
with channel bindings, for example) could be simple and natural, and 
might even improve their security.

Also (and please don't take it personally...) any of the proposals that 
suggest cert-based authentication are primarily useful for device 
authentication, since people don't usually remember big numbers. So 
there's another reason to keep it in scope.

Thanks,
     Yaron

---

From: Nico Williams <[email-masked]>
Date: Tue, 13 Nov 2012 15:30:08 -0600

I agree with Yaron that we need to be more careful about what we rule
out of scope.  Some things to clarify:

 - What kinds of changes constitute "changes to HTTP".

   For example:

    - addition of a session ID header and/or MAC: in or out of scope?

    - addition of other headers?  (should be allowed, IMO)

    - addition of HTTP status codes?  (should at least be avoided)

    - use of HTTP verbs for authentication (POSTing of authen. msgs)?
      (should be allowed, IMO)

   Obviously we should not allow backwards-incompatible changes
   to, say, WWW-Authenticate.  But can we add new headers?  IMO it
   would be quite silly to say "no, you can't add new headers".

 - Authentication of devices seems silly to rule out.  Devices could
   easily be indistinguishable from humans in many cases.

 - Authentication of "components of web services" seems quite fair
   to leave out, if for no other reason than that that would require a
   new URI scheme, I think, and new URI schemes should be out
   of scope for this WG.

Nico
--

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 13 Nov 2012 22:43:11 +0000

On 11/13/2012 08:38 PM, Yaron Sheffer wrote:
> services" is out of scope. 

That text was in the previous round. I can't recall who
suggested it then. I agree its a bit vague. Not sure how to
make it better myself.

> Much of the world is not doing OAUTH for

Does that need changes to HTTP? If so, then that aspect ought
be out of scope I think, or we will not get done and whatever
limited chance exists for broad adoption would be lost.

> there's another reason to keep it in scope.

That's fine if you want to describe it that way, but even if
things like hoba are defined for user auth (and it is) they
can still be used by devices.

S.

> 
> Thanks,
>     Yaron
> 
> _______________________________________________
> http-auth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/http-auth
>

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 13 Nov 2012 22:49:26 +0000

Hiya,

Tricky questions.

>     - addition of a session ID header and/or MAC: in or out of scope?

Out I'd say. Overlaps with HTTP/2.0 discussion. GOTO httpbis.

>     - addition of other headers?  (should be allowed, IMO)

I'd have thought better not, if more is needed then evolving
part 7 as part of httpbis would seem better. But I dunno how
others view this. Maybe this is one where we need to suck it
and see, and if some change looks really needed then make
sure the httpbis folks also like it or at least don't have
a problem with it.

>     - addition of HTTP status codes?  (should at least be avoided)

Eh...dunno. 451 was a fun discussion but indicates that that
may not be trivial.

>     - use of HTTP verbs for authentication (POSTing of authen. msgs)?

I reckon so.

>    easily be indistinguishable from humans in many cases.

Text tries to rule out schemes that aren't aimed at authenticating
humans. I'll try clarify. (But do disagree if you disagree!)

>    new URI scheme, I think, and new URI schemes should be out

Right. I'll try put some of that in the draft text.

S.

---

From: Nico Williams <[email-masked]>
Date: Tue, 13 Nov 2012 17:22:42 -0600

> Out I'd say. Overlaps with HTTP/2.0 discussion. GOTO httpbis.

No solution that doesn't provide a concept of sessions, or tie into a
concept of sessions, will be successful.  Full stop.

Indeed, no solution that involves multi-round trip authentication
message exchanges can even work with HTTP without sessions unless it
is by binding authentication to a "connection", a concept that is
foreign to HTTP itself and which is the cause of problems with
HTTP/Negotiate (e.g., the need to re-authenticate every connection,
which can be quite heavyduty for some mechanisms).

We have to discuss where session-ness belongs, here or http-bis, but
we must have it.  PHB has a draft on sessions and MACs and has agreed
to add support for channel binding to it so my I-D can use it, so I
think I can manage to keep my I-D in scope by sub-contracting this
piece, as it were, to PHB and http-bis.  But at the very least I want
reliance on such work to not lead to out-of-scopeness here.

>>     - use of HTTP verbs for authentication (POSTing of authen. msgs)?

Good.

I think my proposal then remains in scope.

> humans. I'll try clarify. (But do disagree if you disagree!)

I do disagree.  I think it's silly to not allow proxies for humans.
Besides, that restriction strikes me as gratouitous and not justified.
 Please remove it.

> Right. I'll try put some of that in the draft text.

Yeah, these clarifications seem very much worthwhile.

Nico
--

---

From: Paul Leach <[email-masked]>
Date: Thu, 15 Nov 2012 15:14:14 -0800

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Nico Williams
Sent: Tuesday, November 13, 2012 3:23 PM
To: Stephen Farrell; Stephen Farrell
Cc: Yaron Sheffer; [email-masked]; Yaron Sheffer; [email-masked]
Subject: Re: [http-auth] rev'd charter-like text

>>  - What kinds of changes constitute "changes to HTTP".
[Paul Leach]  My definition would be that anything which proposes anything
more than a new scheme name for use on the WWW-Authenticate and
Authorization headers, and new directives and their syntax for use with that
scheme, is proposing a change to the HTTP authentication framework. 

That includes new headers, and actions that involve other HTTP requests.

Note: I like many of the schemes that want to change the HTTP auth
framework, so I'm _not_ trying to get them ruled them out of scope.  I just
want the charter to be explicit and accurate about what's in scope.

Paul