gmane.ietf.http-auth

Re: Session continuation and authentication

Ilari Liusvaara — 2013-05-17T20:44:09

Well, the idea I had was roughly:

Have an optional mode (server-initiated) where both sides do:

real_session_secret = HMAC-X(shared_secret_from_auth, session_secret_on_wire)

But perhaps this is a bad idea, simpler and sufficient being server being able
to signal implicit session secret (real_session_secret=shared_secret_from_auth).

Then various auth schemes specify how to derive shared_secret_from_auth.

Threat model obviously involves connection (TLS or not) being MITM'd...

Yeah, wouldn't amount to much with schemes like scram or digest, but HOBA or
mutual could do much better at this.

-Ilari

Re: Session continuation and authentication

Phillip Hallam-Baker — 2013-05-17T11:48:02

I don't see any reason for the session continuation mechanism to vary
across credential presentation mechanisms. The aim is to have one
continuation mechanism that all the authentication schemes can adopt rather
than proposing slightly different ones.

At root a session continuation mechanism is going to have two key pieces of
information, the session identifier and the secret key. The draft is
designed to support HTML Forms and other legacy mechanisms that don't know
about continuation and so it describes a mechanism to establish the tokens
in HTTP headers.

But there is no reason why HOBA or whatever can't generate the session
identifier and key by themselves. In fact that is exactly what I am doing
in Omnibroker where I generate the session identifier and key using a
connection maintenance Web Service. I'll try to spin that out as a separate
draft since it is a fairly general problem that could be re-used often.





On Thu, May 16, 2013 at 4:57 PM, Stephen Farrell
<stephen.farrell< at >cs.tcd.ie>wrote:

Re: I-D Action: draft-ietf-httpauth-basicauth-enc-00.txt

Martin J. Dürst — 2013-05-17T11:05:33



I don't have a problem. A slight alternative (and the way I seem to 
remember it having been done in a past case) is to have the first few 
new RFCs use the 'update' label, and the last one use the 'obsoletes' 
label. That allows to get rid of one IETF Last Call.

Regards,   Martin.

Re: I-D Action: draft-ietf-httpauth-basicauth-enc-00.txt

Stephen Farrell — 2013-05-17T10:48:32


On 05/17/2013 11:37 AM, Julian Reschke wrote:

Ok so the plan is something like, this, p7 and then a new
basic and a new digest all become RFCs that update 2617.
When those are all done, the we can do a no-I-D IETF LC
to obsolete 2617 and just get the RFC editor to change the
metadata. (Updates and obsoletes relationships are not part
of the RFC, but part of the metadata, and that latter can
change.)

I think that works. Doubtless someone'll have a problem
with it somewhere along the line, but we can worry about
that then:-)

Ta,
S.

Re: I-D Action: draft-ietf-httpauth-basicauth-enc-00.txt

Julian Reschke — 2013-05-17T10:37:31

HTTPbis P7 obsoletes the framework part of RFC 2617. We'll need two 
additional specs defining Basic and Digest to get rid of RFC 2617 
completely.

*This* draft just addresses the I18N issue of Basic. The reason why I 
don't want to do it in a new Basic spec is that this *really* is 
experimental. There's no point putting it into something that's 
replacing 2617 if we don't have any evidence that it works.


Ok.


Clients already send non-ASCII; the issue here is making the encoding 
reliable.


I can do that.


Feedback appreciated :-)


Ack.


Also, this WG actually is chartered to update Digest, so this needs work.


Thanks for the feedback!

Best regards, Julian

Re: I-D Action: draft-ietf-httpauth-basicauth-enc-00.txt

Stephen Farrell — 2013-05-17T09:20:31

Nice. This looks pretty baked to me. Some nitty comments
below, nothing major at all.

Cheers,
S.

- What's the story on updating/obsoleting 2617? I don't much
care but this'd be a good thing to work out before IETF LC as
otherwise we might end up doing multiple LC's to get it right.
Seems like httpbis-p7 doesn't obsolete 2617 and nor does this
and presumably nor would an updated digest. Somehow that seems
wrong;-) I can't recall if 3 RFCs can all obsolete 2617 or
not but maybe that'd be worth checking out with someone who
cares. I can find someone who cares and ask if that's what
the wg want - the chairs can tell me if so, or that might be
better as a thing the httpbis wg think about, or perhaps its
all been thought about already.

- An additional example or two would be good, maybe with
a username and password with asian characters or something.
If sticking with one Example, maybe change the title of
section 4:-)

- section 5: I wondered if there are any potential bad effects
if a UA sends an Authorizatio

Re: draft-ietf-httpauth-basicauth-enc-00 - a fewcomments

Julian Reschke — 2013-05-17T08:11:02

Fixed in <http://trac.tools.ietf.org/wg/httpauth/trac/changeset/4>.


Will do.


The example uses the POUND sign, which is not ASCII.


Because that's what RFC2617 could be read to say, and some UAs actually 
do that.

Best regards, Julian

Re: Session continuation and authentication

Michael Thomas — 2013-05-16T21:07:53

More to the point, hoba isn't trying to do anything on the session
continuation front. It mentions cookies because they're pervasive
and HOBA ought to work with them -- or any other session continuation
technique.

Mike

Re: Session continuation and authentication

Stephen Farrell — 2013-05-16T20:57:43


On 05/16/2013 09:52 PM, Ilari Liusvaara wrote:

Yep. But that's because we're aiming to be an easy drop-in
replacement for Basic or web forms. If PHB's session
continuation thing or some equivalent took off, that'd be
great IMO. Bearer tokens are just dangerous.

Cheers,
S.

Session continuation and authentication

Ilari Liusvaara — 2013-05-16T20:52:24

 
Regarding session continuation, since many of the proposed authentication
schemes don't seem to have multi-request authentication, should there be
some mechanism to couple authentication into session?

Obviously, how to derive shared secret from authentication is method-
specific, and some methods (e.g. mutual) can yield stronger secrets than
others (e.g. SCRAM), and some can't yield one at all (e.g. Basic).

I note that HOBA spec calls to use cookies (blech). I haven't yet figured
out how mutual deals with concept of "session".

Oh, and I don't think "Just use TLS" really cuts it...

-Ilari

Re: draft-ietf-httpauth-basicauth-enc-00 - a fewcomments

Phillip Hallam-Baker — 2013-05-16T20:27:28

For Digest there are two separate changes that are frequently suggested

1) Character set internationalization
2) Algorithm agility

Seems to me that if we make any changes we should fix both.

Applications are required to accept additional parameters on
www-authenticate

   auth-param
     This directive allows for future extensions. Any unrecognized
     directive MUST be ignored.


Since we can use www-authenticate I propose that we solve the character set
issue by having the server add a flag to the response saying which charsets
it accepts. If the client understands the extension and sees the flag then
it MUST use one of the offered charsets (same registry as for BASIC) and
include the flag. Otherwise it does what it does today...

Note that with this approach we don't affect any existing code path so we
don't need to investigate. If people have found a way to make Digest work
internaltionalized that is not going to be affected. I really doubt that is
the case though.


Algorithm agility is really unnec

draft-ietf-httpauth-basicauth-enc-00 - a few comments

Yaron Sheffer — 2013-05-16T19:54:41

Hi, this draft is short and useful, but can still be improved :-)

- Nit: the word "lead" in the abstract and in the intro should be "led".

- Although this is clear from the example, please say explicitly that 
the explicit encoding is used for both the username and the password.

- It's funny that the example only uses ASCII. I will be happy to 
provide a non-ASCII example in Hebrew (although the author's city name 
would do just as well).

- In Sec. A.1.1, why is 8859-1 singled out? Seems to me the strategy 
should use the locally reasonable locale, e.g. ISO 8859-8 for the he_IL 
locale.

Thanks,
Yaron

I-D Action: draft-ietf-httpauth-basicauth-enc-00.txt

2013-05-16T19:18:11

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Hypertext Transfer Protocol Authentication Working Group of the IETF.

Title           : An Encoding Parameter for HTTP Basic Authentication
Author(s)       : Julian F. Reschke
Filename        : draft-ietf-httpauth-basicauth-enc-00.txt
Pages           : 10
Date            : 2013-05-16

Abstract:
   The "Basic" authentication scheme defined in RFC 2617 does not
   properly define how to treat non-ASCII characters.  This has lead to
   a situation where user agent implementations disagree, and servers
   make different assumptions based on the locales they are running in.
   There is little interoperability for the non-ASCII characters in the
   ISO-8859-1 character set, and even less interoperability for any
   characters beyond that.

   This document defines a backwards-compatible extension to "Basic",
   specifying the server's character encoding expectation, using a new
   authentication

Re: HOBA: registration & user interaction

Michael Thomas — 2013-05-16T15:39:32

I just checked around and it seems even worse than I guessed: it seems
you cannot get the HTTP status code programmatically in javascript for a
<img> tag, so a HOBA-401 would show up as a generic onerror just like a 404.
I guess you could overload the prototype of the onerror property and probe
your session connectivity any time you got an error of any kind but that doesn't
seem like the mostest of elegantests of solutions.

Mike

On 05/16/2013 08:12 AM, Michael Thomas wrote:

Re: HOBA: registration & user interaction

Michael Thomas — 2013-05-16T15:12:48

As I wrote to Paul and Stephen, the question in my mind is whether HOBA-http
ought to be thought of as reflexive like 401 is now. I'm thinking that way be dragons
because probably the singular glaring fail of the reflexive 401 is that the browser
owns the interaction and paints up a butt-ugly modal dialog. Modern web sites
MUST be able to control the login/join flow programmatically (= html/js).

James zeroed in on exactly the same thing I was thinking about though which
are <img>'s, say, when the session has expired. Obviously you can't flow a batch
of html back -- the best you could do is capture the problem with an onerror handler,
but that would be pretty ugly.

So I'm thinking that it might be better for the client (= js in browser) to be proactive
to determine the session state. Maybe it wants to inspect the session cookie to see
if it's still valid, or whatever else kind of test it might want to perform before it
interacts with the server if it knows that a session needs to be valid. Since the overal

Re: First draft of HTTP Signatures published

Phillip Hallam-Baker — 2013-05-16T15:00:00

On Thu, May 16, 2013 at 10:39 AM, Michael Richardson
<mcr+ietf< at >sandelman.ca>wrote:


That might be useful. But right now I am focused on making sure that bad
things do not happen.

If an intermediary corrupts a message that is a Web Services transaction
message then my desired outcome is that the transaction is aborted. People
keep telling me that it is a requirement to allow random proxies that have
no idea what the Web Service is doing to make random changes to transaction
messages and that the protocol should still work.

If the intermediary is a party to the transaction, that is a totally
different situation.




Sorry, the scheme. The method is already in the request line.

Re: First draft of HTTP Signatures published

Michael Richardson — 2013-05-16T14:39:13

    Phillip> You will find a lot of objections being made of the form 'this will break
    Phillip> when intermediaries change content'. And they will continue to be made no
    Phillip> matter how many times you point out that detecting changes to the content
    Phillip> and rejecting that transaction is the whole objective. So there will need
    Phillip> to be some statement to the effect that the intended
    Phillip> behavior is to prevent 
    Phillip> all types of content modification.

And maybe we need to provide a way for intermediaries to signal their
existence, and for a transitive (but decentralized) trust model to
permit their inclusion.   My impression is that this has worked well in
SIP, although I am aware that it has also thwarted S/MIME-type security
solutions in SIP.

    Phillip> We don't yet know what the effect of intermediaries is on the request line
    Phillip> and I suspect that as we get into tests we are going to discover that we
    Phillip> have to do some form of canonicaliz

Re: HOBA: registration & user interaction

Stephen Farrell — 2013-05-16T14:27:36


On 05/16/2013 03:21 PM, Stephen Farrell wrote:

Oops - s/WWW-Authenticate/Authorization/ above sorry;-)

S.

Re: HOBA: registration & user interaction

Stephen Farrell — 2013-05-16T14:21:59

Hi James,

Good questions as always, thanks.

On 05/16/2013 02:29 PM, Manger, James H wrote:

To be honest, me neither:-) I've some code for the basic
crypto but haven't tried any UI stuff so far.

What I was thinking of was the the WWW-Authenticate with
the signature will also be part of the register POST message,
since the UA is responding to a 401.

In that case the server gets everything it needs and can
remember the key and that the signature was ok as it pushes
the user through the registration process. Once the server
is happy with that it can set cookies or whatever. And next
time the UA comes back it should be ok or not as the server
desires.

That'll also need to work as well if the user hits some
"register" button on the page before ever seeing a 401.
I suspect that the server would have to feed a 401 to the
UA at that point and then we go from there.


Yep. Mike brought that up too the other day in an offlist
mail. I guess there'll be all sorts of similar web things
with starting off inside a fr

Re: First draft of HTTP Signatures published

Phillip Hallam-Baker — 2013-05-16T13:57:11

HTTP Session Continuation is a separate spec but I would like to share as
much as possible between them.

http://www.ietf.org/id/draft-hallambaker-httpsession-01.txt

Early versions of the session continuation mechanism included header
signing. That is a real headache. The only way that I think it can be made
to work reliably is to duplicate the information that you want to sign into
the signing header which is the approach in DKIM.

For HTTP transactions, the only headers that I think should ever be signed
are content meta-data. The reason signing is hard in SMTP and HTTP is that
there is a huge confusion between headers used for routing and headers that
are properly part of the content. This is perhaps a change that could be
made in HTTP/2.

You will find a lot of objections being made of the form 'this will break
when intermediaries change content'. And they will continue to be made no
matter how many times you point out that detecting changes to the content
and rejecting that transaction is the whole obj

HOBA: registration & user interaction

Manger, James H — 2013-05-16T13:29:24

I’m not quite sure how registration and user interaction is intended to work in HOBA-http [draft-ietf-httpauth-hoba-00].

The core HOBA-http interaction looks simple enough:
1) client makes a request;
2) server wanting authentication responds with a 401 that includes "WWW-Authenticate: HOBA challenge=...";
3) client re-tries the request with "Authorization: HOBA result=kid.challenge.nonce.sig";
4) server verifies the signature using the client’s public key.

The core interaction only works if the server already has the client’s public key. The client can register a public key by POSTing it to https://origin/.well-known/hoba/register. It looks like this registration has to occur the first time the client gets a "WWW-Authenticate: HOBA" response from the server: between steps 2 & 3 above.

The spec implies that the server decides what sort of user interaction results from the registration POST. Perhaps a server would return an HTML form prompting for a name and email address to go with the new