Subject: Re: [http-auth] WGLC for draft-ietf-httpauth-hoba-04

From: Yoav Nir <[email-masked]>
Date: Mon, 6 Oct 2014 11:04:40 +0300

On Sep 22, 2014, at 8:48 AM, Yoav Nir <[email-masked]> wrote:

> Hi all
> 
> Stephen, Paul, and Michael submitted version -04 about a month ago, and it has received no discussion so far.  The authors are of the opinion that the document is ready for publication, and it’s time for the group to weigh in on this subject.
> 
> This mail begins working group last call for this document. Please take the time to read the draft and send comments to the list about its security, applicability, usefulness, and any other aspect you wish to discuss. For guidance on what to look for, let me quote the following from our charter:
>   The httpauth WG will be a short-lived working group that will document
>   a small number of HTTP user authentication schemes that might offer
>   security benefits, and that could, following experimentation, be
>   widely adopted as standards-track schemes for HTTP user
>   authentication. Each of these RFCs will be Informational or
>   Experimental, and should include a description of when use of its
>   mechanism is appropriate, via a use-case or other distinguishing
>   characteristics. 
> The WGLC is two weeks long, and ends on October 6th. Please send your reviews as replies to this message.
> 
> Thanks,
> 
> Yoav & Matt

Hi.

This concludes WGLC for the HOBA draft. We’ve had quite a few comments (thanks to Michael, Amos, Julian and Benjamin), most are editorial, but at least Amos’s is substantial.

For convenience, I’ve submitted tickets to cover the issues raised: http://trac.tools.ietf.org/wg/httpauth/trac/query?component=hoba

We’ll leave it to the authors to work through the LC comments, and whatever needs discussion can be covered here on the mailing list, and if needed - in Honolulu.

Thanks again to everyone for taking the time to review this.

Yoav & Matt

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 06 Oct 2014 14:22:09 +0100

Hi Michael,

Thanks for the detailed review. Reactions below and the changes
I've made can be seen at [1]. (Note [1] has changes from all the
various WGLC reviews. [2] is the diff vs. -04.)

   [1] https://down.dsg.cs.tcd.ie/misc/draft-ietf-httpauth-hoba-05.txt
   [2]
https://tools.ietf.org/rfcdiff?url1=draft-ietf-httpauth-hoba-04.txt&url2=https://down.dsg.cs.tcd.ie/misc/draft-ietf-httpauth-hoba-05.txt

I'll post the -05 once I figure we're closed out on WGLC comments
or after a day or two's silence or as instructed by the chairs.

On 22/09/14 23:26, Michael Sweet wrote:
> Comments for:
> 
> https://tools.ietf.org/html/draft-ietf-httpauth-hoba-04
> 
> - In section 1 (introduction), the following text is awkward to
> read:
> 
> Current HTTP authentication methods (Basic and Digest), as well as 
> username/password authentication using web forms, have been in use 
> for many years, but being based on passwords, are susceptible to 
> theft of server-side databases.
> 
> The following is my suggested rewording:
> 
> Current username/password authentication methods such as HTTP Basic, 
> HTTP Digest, and web forms have been in use for many years but are 
> susceptible to theft of server-side password databases.

Done.

> 
> - Also in section 1:
> 
> Session management with HOBA is identical to username/password 
> session management.  Typically, the session management tool (such as 
> PHP, Python CGI, and so on) inserts a session cookie into the output 
> to the browser.  HOBA does nothing to help or hurt session cookie 
> hijacking; TLS is still required for that.  If the authentication is 
> not bound to HTTP sessions, even TLS cannot help against all
> attacks.
> 
> might read better as:
> 
> HOBA session management is identical to username/password session 
> management, with a server-side session management tool or script 
> inserting a session cookie into the output to the browser.  HOBA 
> still requires TLS to prevent session cookie hijacking.

Also done.

> 
> - And here in section 1 aren't you talking about revoking keys?
> 
> o  Users are also likely to lose a private key, or the client's 
> memory of which key pair is associated with which origin, such as 
> when a user loses the computer or mobile device in which state is 
> stored.  HOBA allows for clients to tell servers to delete the 
> association between an existing CPK and an account.

Not really, but it's similar I suppose. The difference is that since
HOBA is origin-bound, a UA just needs to tell one server about that
public key so its more like a de-register rather than a revocation as
would be the case with PGP or X.509. That said, we didn't actually
define a de-register message so I've changed it thusly:

OLD:

   HOBA allows for clients to tell servers to delete the
   association between an existing CPK and an account.

NEW:

   HOBA implementations can, and probably ought, provide mechanisms
   for clients to tell servers to delete the association between an
   existing CPK and an account, but that will typically be done at
   the application layer and not using HOBA-defined messages.

In case it helps, with my code I provide a way to associate a
string with each UA for an account (e.g. "my ipad", "ff on laptop")
and those (and the associated public key binding to the account
on that origin) can be deleted, but that's just done using a
form and has no HOBA-specific protocol. Not sure how much of that
to include to be honest. I think the above NEW text should be ok
for an experimental RFC.

> 
> - This text in section 1 is also awkward/confusing:
> 
> o  Since there are always devices and applications in which state of 
> the art digital signature mechanism runtimes are significant, and 
> since HTTP authentication in theory requires that every HTTP request
> to a given realm have a signature in an "Authorization" header field,
> and since HOBA is a challenge response scheme, we also define a way
> in which HTTP servers can indicate the duration for which they will
> consider a given challenge value to be valid. As a consequence we
> also define a way for UAs to fetch a fresh challenge.
> 
> Perhaps reword as:
> 
> o  Digital signatures can be expensive to compute, so HOBA defines a 
> way for HTTP servers to indicate how long a given challenge value is 
> valid, and a way for UAs to fetch a fresh challenge at any time.

Done.

> 
> - Section 1.1, drop "in which this can be done" from the third line.

Done.

> - Section 1.2 is a mix of styles, 

Well, >1 author => >1 style:-)

> consider making it "Term:
> definition" throughout, and separate HOBA-js and HOBA-http.

Fair point. Tried to do that.

> - Section 1.2 is missing a reference to HTTP authentication
> specification (which do you mean?)

It's there later but I added another here to 7235.

> 
> - Section 1.2: The statement "This specification uses the Augmented
> Backus-Naur Form (ABNF) notation of [RFC5234]" probably doesn't
> belong here, unless you want to define ABNF as a term (in which case
> make it ABNF: definition [RFC5234])

I think its useful to have a ref to 5234 but don't think we
need to define a term (we're not defining it anyway:-). I did
move that para up to just below the 2119 reference which may
help.

> 
> - Figure 1: Shouldn't the unreserved values actually be base64url
> values?
> 
> - Figure 2: Ditto here - base64url encoded?

Both are in the text, so its specified, but just not in the
ABNF. I'm not sure if putting it there would really be of
use though, but if someone wants to send me ABNF that does
that and if nobody has a problem with it, I'd be ok with
making that change. Personally, I prefer the ABNF as-is since
I'm guess its more readable now than it would be should we
try to define base64url encoded within the ABNF.

> 
> - Section 3: If this is a valid security concern, change to "the
> challenge MUST be unique for every HTTP 401 response ..."

That'd be fine with my code but I forget if we had a specific
reason for the SHOULD. I've made the change though since fewer
SHOULDs is better.

> 
> - Section 4, top of page 9: Something is missing betweem "from
> HTML5." and "is used".

Ah. The full stop shouldn't have been there;-)

I also added a note about IndexedDB as an alternative to localStorage
since the WebCrypto uses the latter.

> 
> - Section 4, not sure I like the raw URL references - better to make
> them informative or normative references (as appropriate). Also,
> since WebCrypto is not available I'm not sure it is appropriate to
> mention it here - maybe move this to an  appendix that outlines some
> potential future enhancements based on in-progress work.

I've started implementing with WebCrypto so it is available now
and shipping in chromium. I still have to turn it on via
about:config with FF, but its mostly there too. I think it's
better to leave that in.

> 
> - Section 3: Is it ".well-known/hoba/getChal" or
> ".well-known/hoba/getchal" (lowercase), as it appears in section
> 6.4?

Good catch. I've gone with getchal as that matches my code.

> - Section 8: If reuse of challenge values (section 3) stays a SHOULD
> NOT, then it should be added here in more detail as to why this can
> be problematic.

Fixed in section 3 now.

> 
> - Section 9.4: Extra "i" after "ok."

That's what I get for using vi:-)

> 
> - Section 10: Don't deleted sections go at the end to make the RFC
> Editor's job easier and to avoid broken references?

That's not a problem for them since we'll give them the xml.

Cheers,
S.

> 
> 
> 
>> On Sep 21, 2014, at 10:48 PM, Yoav Nir <[email-masked]>
>> wrote:
>> 
>> Hi all
>> 
>> Stephen, Paul, and Michael submitted version -04 about a month ago,
>> and it has received no discussion so far.  The authors are of the
>> opinion that the document is ready for publication, and it’s time
>> for the group to weigh in on this subject.
>> 
>> This mail begins working group last call for this document. Please
>> take the time to read the draft and send comments to the list about
>> its security, applicability, usefulness, and any other aspect you
>> wish to discuss. For guidance on what to look for, let me quote the
>> following from our charter: The httpauth WG will be a short-lived
>> working group that will document a small number of HTTP user
>> authentication schemes that might offer security benefits, and that
>> could, following experimentation, be widely adopted as
>> standards-track schemes for HTTP user authentication. Each of these
>> RFCs will be Informational or Experimental, and should include a
>> description of when use of its mechanism is appropriate, via a
>> use-case or other distinguishing characteristics.
>> 
>> Yoav & Matt _______________________________________________ 
>> http-auth mailing list [email-masked] 
>> https://www.ietf.org/mailman/listinfo/http-auth
> 
> _________________________________________________________ Michael
> Sweet, Senior Printing System Engineer, PWG Chair
> 
> _______________________________________________ http-auth mailing
> list [email-masked] 
> https://www.ietf.org/mailman/listinfo/http-auth
> 
>

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 06 Oct 2014 14:22:12 +0100

Hi Julian,

Thanks for the review.

As before an updated version is at [1], diff at [2].

On 23/09/14 08:10, Julian Reschke wrote:
> On 2014-09-22 07:48, Yoav Nir wrote:
>> ...
> 
> I had a look from an editorial and HTTP related angle (me no
> security person):
> 
> - it seems that the reference to RFC 7235 needs to be normative

Done.

> 
> - in the IANA sections, it would be helpful if the specification
> links would be more specific

Not sure what you mean there. I think "[[ this document ]]" is
fine for IANA and the RFC editor if that's what you mean, but if
you mean something else can you say?

> 
> - there's a "TBD" in Section 9.3

oops fixed - deleted the comment. I also added a requirement
that new entries here should already be used in some other
IETF standard - don't see any reason why HOBA should be
innovative in that respect.

> 
> - for the new IANA registries, I believe you ought to specify the
> actual format of the registry and/or provide a registration form

I don't think that's needed here really. If HOBA gets enough use
so that entries get added then I'd say that could be fixed when/if
the spec gets put on the standards track and I'm sure there'd be
more to fix then too.

> 
> - terminology confusion: Section 2 introduces the "authentication 
> scheme" (which seems to be about HOBA in general), but the actual
> HTTP authentication scheme is defined in Section 3.

I think that's ok, happy to correct if others feel its
confusing though (esp. if text changes suggested:-)

> - TODO in Acknowledgements: "[[ and any more to be added ]]"

Some more added now, I think I've added anyone who said
something technical;-)

> 
> Finally some comments on Section 3:
> 
> This describes behavior, but reads a bit strange as a formal
> definition of an auth scheme. For instance:
> 
>> If the "HOBA" scheme is listed, it MUST be followed by two or more 
>> auth-param values.
> 
> Replace by:
> 
> "The HOBA scheme has two REQUIRED attributes (...) and one OPTIONAL 
> attribute (realm) described below:"

Done.

> 
> Also, a full HTTP request/response exchange example might make this 
> simpler to understand.

I'll look at that later on, can probably generate it but don't have
time today. Noted it in the XML source.

Thanks again,
S.

> Best regards, Julian

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 06 Oct 2014 14:22:13 +0100

On 23/09/14 12:57, Julian Reschke wrote:
> On 2014-09-23 09:10, Julian Reschke wrote:
>> ...
> 
> Furthermore, Section 9.6 tries to IANA-register the header field
> "HOBAREG" which doesn't seem to be defined anywhere.

Oops again. Added text to section 6.1 for that. (I added it
late in response to Michael Sweet's good comment that something
like that was needed:-)

Just to check - in my code, once registration is successfully
completed, I add a HOBAREG header to the "last" HTTP response
that's part of registration with a value of "regok" but I think
we just need the presence of the header so that's all the spec
calls for right now. Happy to modify if folks think it better
to do something else or if there's a better way to write that
up.

Cheers,
S.

> 
> Best regards, Julian
> 
> _______________________________________________
> http-auth mailing list
> [email-masked]

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 06 Oct 2014 14:22:15 +0100

On 24/09/14 12:53, Julian Reschke wrote:
> ...also:
> 
>>    o  An "expires" attribute MUST be included that specifies the number
>>       of seconds from the time the HTTP response is emitted for which
>>       responses to this challenge can be accepted.
> 
> HTTP caching (RFC 7235) knows the "Expires" header field (taking a
> date), and the "max-age" cache-control directive (taking seconds). Maybe
> it would make sense to rename this one to "max-age" for consistency.

That sounds like a good change so I made that change to the spec and
my code (the latter's not yet committed btw, will be later)

Cheers,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 06 Oct 2014 14:22:16 +0100

Hi Amos,

> Looks like the HTTP specific part is almost a duplicate of RFC
> 6750 OAuth 2.0 Bearer authentication.

Well, except that HOBA does not produce bearer tokens, as that term
is usually understood - you need to use a private key to make one
and each signature will be different. (It is true that with the
max-age/expires parameter there is a server-defined window during
which HOBA is not that different, but a server can set max-age to
zero.)

> 
> One could re-write this specification by doing:
> 
> * reference Bearer specification, * add expires= and challenge=
> (code=?) parameters on www-auth header, * add a scope parameter
> value "hoba:origin", * prohibit token re-use/replay, * prohibit
> URI-query and payload delivery mechanisms * define section 5 and
> section 6 using RFC 6749 credential management parameters and
> mechanisms.
> 
> Doing so would avoid both the need to register a new
> authentication scheme, and "well-known" URI space.

I don't see that there's that much benefit in avoiding those
registrations myself and do see a lot of downside in being
entangled with oauth here. There's nothing wrong with oauth
but I don't think HOBA and oauth need to be entangled that
way. (When/if an oauth holder-of-key scheme is defined then
that might look a lot like HOBA I guess but that's not yet
defined I believe.)

Also, in an offlist mail, Amos suggested that we look at the
security considerations of 6750 since many of those might
apply here (esp with max-age!=0). So I've added text saying:

"When the max-age parameter is not zero, then a HOBA
signature is very similar to a bearer token, as it can
be replayed for a server-selected duration. Similarly,
for HOBA-js, signatures might be replayable depending
on the specific implementation. The security considerations
of [RFC6750] therefore apply in any case where the
HOBA signature can be replayed."

Thanks for the review,
Cheers,
S.

PS: As for the other WGLC mails, an updated version is at [1], diff
at [2].

> Amos

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 06 Oct 2014 14:22:18 +0100

Hi Ben,

Thanks for the comments. Responses below.

As for the other WGLC mails, an updated version is at [1], diff
at [2].

On 29/09/14 19:54, Benjamin Kaduk wrote:
> On Mon, 22 Sep 2014, Yoav Nir wrote:
> 
>> Hi all
>>
>> Stephen, Paul, and Michael submitted version -04 about a month ago, and
>> it has received no discussion so far.  The authors are of the opinion
>> that the document is ready for publication, and it’s time for the group
>> to weigh in on this subject.
>>
> I see a few places that could be unclear, and have a handful of editorial
> comments.
> 
> 
> In section 2,
> 
>    On receipt of a challenge (and optional realm) from a server, the
>    client marshals an HOBA to-be-signed (TBS) blob that includes a
>    client generated nonce, the web-origin, the realm, an identifier for
>    the CPK and the challenge string; and signs that hashed blob with the
>    private key corresponding to the CPK for that web-origin.
> 
> The client is supposed to marshal a blob, but then signs a hashed blob.
> How does the hashing happen (or is it part of the signature)?

Yes, its part of the signature, but you're correct, the text
could be read to be doing two hashes I guess (as DKIM does,
but HOBA does not), so I changed to just say "sign the blob."

> 
> 
> Still in section 2,
> 
>    The value that is sent over the network is the HOBA "client result"
>    which we now define.
> 
> It might be good to explicitly say that this is sent over the network by
> the client.

Added "by the UA"

> 
> 
> In section 3, we hear that the HOBA scheme "MUST be followed by two or
> more auth-param values."  It might be useful to include here an example of
> how those attributes are encoded.

There's an example in Appendix B and I've an action to try make
that a full HTTP request/response example as suggested by Julian.
I'll do that but not today.

I also added an example "max-age: 10" the challenge already says
its base64url encoded.

> 
> And the editorial bits:
> 
> 
> In section 3,
> 
>    the client to authenticate with HOBA.  Note that the HOBA auth-scheme
>    might not be the only one that the server includes in a WWW-
>    Authenticate.
> 
> I think that "a WWW-Authenticate header" is better grammar, unless this is
> some usage I'm not familiar with.

Done

> 
> 
> Still in section 3,
> 
>    When the "client response" is created, the UA encodes the HOBA
>    client-result (a string matching the HOBA-RES production in Figure 2
>    as an auth-param with the name "result" and returns that in the
>    Authorization header.
> 
> There is no matching close parenthesis.

Fixed.

> In section 4,
> 
>    storage.  For example, an implementation would store a dictionary
>    account identifier, public key, private key tuples in the origin's
>    localStorage for subsequent authentication requests.
> 
> I don't think the grammar is correct in the specification of the contents
> of the tuples stored in localStorage.

s/,/ and / once there fixed it.

> Also in section 4,
> 
>    available: WebCrypto (see http://www.w3.org/TR/WebCryptoAPI).  In
>    lieu of WebCrypto, JavaScript crypto libraries can be employed with
>    the known deficiencies of PRNG, and the general immaturity of those
>    libraries.

Fixed.

> 
> The grammar is not correct in this sentence.
> 
> 
> In section 5.1,
> 
>    In the CPK preparation phase, the client determines if it already has
>    a CPK for the web-origin it is going to.
> 
> Reading this, I want to ask "what is the client going to do?", that is,
> the language feels informal to the point of causing confusion.

Tweaked.

> In section 9.3,
> 
>    TBD, hopefully re-use and existing registry
> 
> s/and/an/

Fixed differently as a result of another comment.

> 
> 
> In section 9.4,
> 
>    "1" means a URI, such as a mailto: or acct: URI, but anything
>    conforming to [RFC3986] is ok.i
> 
> The trailing 'i' was already mentioned, but I would consider expanding out
> "okay" or using less-informal terminology.

Just a typo. Fixed.

> Throughout section 9 in general, the list entries are inconsistent about
> whether they end with a period or not.

I constantly do that unfortunately:-) I think I fixed it so
that those with sentences have a full stop and those that are
not do not.

Thanks,
S.

> -Ben

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 06 Oct 2014 14:30:05 +0100

Hi Yoav,

On 06/10/14 09:04, Yoav Nir wrote:
> Hi.
> 
> This concludes WGLC for the HOBA draft. We’ve had quite a few
> comments (thanks to Michael, Amos, Julian and Benjamin), most are
> editorial, but at least Amos’s is substantial.
> 
> For convenience, I’ve submitted tickets to cover the issues raised:
> http://trac.tools.ietf.org/wg/httpauth/trac/query?component=hoba

I think the batch of mails I just sent out cover all of
those. Since I mostly took on board folks comments I hope
we can close all of those after I post the -05 officially,
but we'll see I guess.

> We’ll leave it to the authors to work through the LC comments, and
> whatever needs discussion can be covered here on the mailing list,
> and if needed - in Honolulu.

I'd hope we might not even need that f2f time if we're
already done.

> Thanks again to everyone for taking the time to review this.

Indeed, the reviews caught a few things and suggested some
good improvements.

Cheers,
S.

---

From: Julian Reschke <[email-masked]>
Date: Mon, 06 Oct 2014 15:39:00 +0200

> you mean something else can you say?

I think it should state the specific section that thing being referenced 
is defined in.

> the spec gets put on the standards track and I'm sure there'd be

Well, at least you need to say what format the registry has; for 
instance, is the key a string? An integer?

Best regards, Julian

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 06 Oct 2014 14:59:19 +0100

Hiya,

> I think it should state the specific section that thing being referenced

Fair enough. Done.

> instance, is the key a string? An integer?

Ah gotcha. So you mean more like [1,2] are now? I can
tart up the presentation before I post (if you've some
example xml that'd be appreciated.)

Cheers,
S.

---

From: Michael Sweet <[email-masked]>
Date: Mon, 06 Oct 2014 10:09:18 -0400

Stephen,

Changes look good.  A few follow-up comments below...

> On Oct 6, 2014, at 9:22 AM, Stephen Farrell <[email-masked]> wrote:
> ...

"and probably ought to" (add "to" on the end)?

But regardless, if HOBA doesn't define a mechanism then how can you claim it supports it?  Seems like you could define a well-known path for a POST that deletes the association on the server side, much as you already do for registration and challenges?

> to include to be honest. I think the above NEW text should be ok

I think I'd feel more comfortable with either defining something or being up front about it not being defined after the list of things that HOBA does, e.g.:

    HOBA currently does not define a mechanism for deleting the association
    between an existing CPK and an account.  Such a mechanism can be
    implemented at the application layer.

(I almost want to add "and may be defined by a future version of this document", but I dislike prognostication in these kinds of documents...)

> try to define base64url encoded within the ABNF.

This is fairly compact; values are just "1*base64urlchars":

    ; Characters for Base64URL encoding from Table 2 of RFC 4648
    base64urlchars = %x30-39             ; Digits
                     / %x41-5A           ; Uppercase letters
                     / %x61-7A           ; Lowercase letters
                     / "-" / "_" / "="   ; Special characters

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Julian Reschke <[email-masked]>
Date: Mon, 06 Oct 2014 16:19:37 +0200

> example xml that'd be appreciated.)

Looks good to me.

Best regards, Julian

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 06 Oct 2014 15:42:51 +0100

Hiya,

On 06/10/14 15:09, Michael Sweet wrote:
>> On Oct 6, 2014, at 9:22 AM, Stephen Farrell
>> <[email-masked]> wrote: ... Not really, but it's similar
>> I suppose. The difference is that since HOBA is origin-bound, a UA
>> just needs to tell one server about that public key so its more
>> like a de-register rather than a revocation as would be the case
>> with PGP or X.509. That said, we didn't actually define a
>> de-register message so I've changed it thusly:
>> 
>> OLD:
>> 
>> HOBA allows for clients to tell servers to delete the association
>> between an existing CPK and an account.
>> 
>> NEW:
>> 
>> existing CPK and an account, but that will typically be done at the
>> application layer and not using HOBA-defined messages.
>> 
> 

Actually no, in my local flavour of Béarla [1], I think the text
is correct, but the RFC editor will fix to their preferred taste
anyway:-)

  [1] http://www.translate-irish.com/en/dictionary-irish-english/b%C3%A9arla

> But regardless, if HOBA doesn't define a mechanism then how can you
> claim it supports it? 

Right. I don't think we should claim it supports it, but that
it allows implementations to.

> Seems like you could define a well-known path
> for a POST that deletes the association on the server side, much as
> you already do for registration and challenges?

Hmm. I don't think so really. We define a way to kick-off and
end registration but not really how to do the "middle" bits which
is where the meat of the work will be. I think de-registering
is likely not something you'd do normally from the UA concerned.
In my case, I provided an a/c management form [2] for that.

   [2] https://hoba.ie/account.html

OTOH, I did actually do a .well-known like thing too in my code
as it was handy for debugging - there's an un-register button
on [3] so it'd not be hard to add if it was wanted. And I suppose
if browsers did adopt HOBA (some hope:-) then having this could
be good if a user wants to "forget" about a site. But since
broswers are not interested for now, that's not a strong argument.
And we could add it later.

   [3] https://hoba.ie/tech.html

But I think [2] or similar makes more sense than [3] in real use
so I'd still say that we should leave this out for now.

>> string with each UA for an account (e.g. "my ipad", "ff on
>> laptop") and those (and the associated public key binding to the
>> account on that origin) can be deleted, but that's just done using
>> a form and has no HOBA-specific protocol. Not sure how much of
>> that to include to be honest. I think the above NEW text should be
>> ok for an experimental RFC.
> 
> I think I'd feel more comfortable with either defining something or
> being up front about it not being defined after the list of things
> that HOBA does, e.g.:
> 
> HOBA currently does not define a mechanism for deleting the
> association between an existing CPK and an account.  Such a mechanism
> can be implemented at the application layer.

I've no problem putting that in. (So I did:-)

> 
> (I almost want to add "and may be defined by a future version of this
> document", but I dislike prognostication in these kinds of
> documents...)
> 
>> ...
>>> 
>>> - Figure 1: Shouldn't the unreserved values actually be
>>> base64url values?
>>> 
>> Both are in the text, so its specified, but just not in the ABNF.
>> I'm not sure if putting it there would really be of use though, but
>> if someone wants to send me ABNF that does that and if nobody has a
>> problem with it, I'd be ok with making that change. Personally, I
>> prefer the ABNF as-is since I'm guess its more readable now than it
>> would be should we try to define base64url encoded within the
>> ABNF.
> 
> base64urlchars = %x30-39             ; Digits / %x41-5A           ;
> Uppercase letters / %x61-7A           ; Lowercase letters / "-" / "_"
> / "="   ; Special characters

Ah, ok, added that too so. Be great if someone can check that
that's ok. Also is unreserved correct for realm or something
better? (Not sure, having checked 7235.)

Usual -05-pre at [4], diff vs. -04 at [5]

Cheers,
S.

[4] https://down.dsg.cs.tcd.ie/misc/draft-ietf-httpauth-hoba-05.txt
[5]
https://tools.ietf.org/rfcdiff?url1=draft-ietf-httpauth-hoba-04.txt&url2=https://down.dsg.cs.tcd.ie/misc/draft-ietf-httpauth-hoba-05.txt

---

From: Julian Reschke <[email-masked]>
Date: Mon, 06 Oct 2014 17:04:53 +0200

> to do something else or if there's a better way to write that

Wait. You can't just introduce a new HTTP header field (not HTTP header) 
in passing.

If you need a new header field, please have a separate section with a 
precise definition of what it is about, and when writing that, please 
follow the guidance in 
<http://svn.tools.ietf.org/svn/wg/httpbis/specs/rfc7231.html#considerations.for.new.header.fields>.

That being said; are you sure you need an additional header field?

Best regards, Julian

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 06 Oct 2014 16:13:38 +0100

Hiya,

On 06/10/14 16:04, Julian Reschke wrote:
>> 
> 
> Wait. You can't just introduce a new HTTP header field (not HTTP
> header) in passing.

Heh, I figured the header (field) police would catch up with me
at some point:-) And that's ok, better to do it right.

Can you tell me the difference here between a HTTP header field
and a HTTP header?

> If you need a new header field, please have a separate section with
> a precise definition of what it is about, and when writing that,
> please follow the guidance in 

I'll look that over, but first...

> That being said; are you sure you need an additional header field?

I *think* we do. The issue is that the UA needs to know when
it can use HOBA which means it needs to know when it has succeeded
in registration. And since registration can be a multiple-exchange
application layer thing, we need a way to signal the successful end
of that back to the UA. So the earlier discussion with Michael ended
up with a header field that the server can put into the "last" HTTP
response that was needed for successful registration. If there's a
better/easier/more-correct way then to handle this then I'd be just
fine with that too, whatever it is.

Cheers,
S.

---

From: Julian Reschke <[email-masked]>
Date: Mon, 06 Oct 2014 17:32:44 +0200

> Can you tell me the difference here between a HTTP header field

The former is the terminology we use in the HTTP specs. The latter I 
don't know :-)

> fine with that too, whatever it is.

I believe it would be better not to return 2xx until authentication is 
finished; can't you just keep sending 403?

Best regards, Julian

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 06 Oct 2014 16:45:40 +0100

On 06/10/14 16:32, Julian Reschke wrote:
>> 
>> I *think* we do. The issue is that the UA needs to know when it can
>> use HOBA which means it needs to know when it has succeeded in
>> registration. And since registration can be a multiple-exchange 
>> application layer thing, we need a way to signal the successful
>> end of that back to the UA. So the earlier discussion with Michael
>> ended up with a header field that the server can put into the
>> "last" HTTP response that was needed for successful registration.
>> If there's a better/easier/more-correct way then to handle this
>> then I'd be just fine with that too, whatever it is. ...
> 
> I believe it would be better not to return 2xx until authentication
> is finished; can't you just keep sending 403?

I don't think so. One of the (IMO) core ideas of HOBA is to
better separate the handling of identifiers/identity-information
from keying material and public keys. Any real account registration
is where the former should be gathered, validated or whatever and
is an application layer concern. While we can kick that off via a
POST to .well-known/hoba/register we can't tell when its done based
on the answer to that, because there could (and likely would) be
all sorts of processes used to handle account creation that would
I think need to get a 200 OK really. So, yeah, I think we need that.

Anyway, I've taken a stab at adding the section concerned. Would
really appreciate it if you could take a peek at the new 6.1.1
in [1] (diff vs. -04 at [2] as usual.)

Thanks,
S.

---

From: Julian Reschke <[email-masked]>
Date: Mon, 06 Oct 2014 17:56:45 +0200

> I think need to get a 200 OK really. So, yeah, I think we need that.

Why would these need a 200?

Anyway, I think this kind of shows that it would be good if the document 
actually contained a complete example of the message flow it's trying to 
describe.

>  HOBAREG-val = "reg-ok" | "in-work"	
> 		
> 			Figure 3: HOBAREG Header Field Definition	

It's "/", not "|". Are the values meant to be case-insensitive? The ABNF 
says yes. (BTW there's also a mismatch with the values in prose).

I'd also spell it "Hobareg"; field names are case-insensitive, but we 
usually uppercase only the starting characters in documentation.

> 			Section 8.3.1 of [RFC7231] calls for documenting the following	
> 			details for this new header field:	
> 				
> 			o Only one single value is allowed in a HOBAREG header field.	
> 			Should more than one (a list) be encountered, that should be	
> 			interpreted as being the same as "in-work."	
> 				
> 			o The HOBAREG header field can only be used in HTTP responses.	
> 				
> 			o Since HOBAREG is only meant for responses it ought not appear in a	
> 			PUT request.	

True. Just state once it's a response header field only, then you don't 
need to mention that here.
  				
> 			o The HTTP response code does affect the interpretation of HOBAREG.	
> 			Registration is only considered to have succeeded if the reg-ok	
> 			value is seen in a 2xx response. 4xx and other errors means that	
> 			registration has failed regardless of the value of HOBAREG seen.	
> 			The request method has no influence on the interpretation of	
> 			HOBAREG.	
> 				
> 			o Intermediaries should never insert, delete or modify a HOBAREG	
> 			header field.	
> 				
> 			o It is not appropriate to list a HOBAREG in a Vary response header	
> 			field.	

Why?
		
> 			o HOBAREG is not allowed in trailers	

Why?
				
> 			o HOBAREG should not be preserved across re-directs.	

...follows from being a response header field.
				
> 			o HOBAREG itself discloses little security or privacy sensitive	
> 			information. If an attacker can somehow detect that a HOBAREG	
> 			header field is being added, then that attacker would know that	
> 			the UA is in the process of registration which could be	
> 			significant. However, it is likely that the set of messages	
> 			between the UA and server would expose this information in many	
> 			cases, regardless of whether or not TLS is used. Using TLS is	
> 			still however a good plan.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Mon, 06 Oct 2014 17:58:05 +0200

>>             o It is not appropriate to list a HOBAREG in a Vary

Replying to myself: because it's not a request header field.

So...: just drop the considerations that apply to request header fields 
exclusively.

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 6 Oct 2014 17:39:22 +0100

Hi Stephen,

> try to define base64url encoded within the ABNF.

You can use ABNF prose:

base64url = <base-64 URL-safe encoded value, as defined in Section ...>

This preserves clarity, while avoiding the need to work on specific syntax.

I got confused by use of unreserved, just to discover later that a more specific syntax is actually used in several places.

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 6 Oct 2014 17:45:56 +0100

Hi,

> On 6 Oct 2014, at 14:39, Julian Reschke <[email-masked]> wrote:
> 
> I think it should state the specific section that thing being referenced is defined in.
> 
>> ...
> Well, at least you need to say what format the registry has; for instance, is the key a string? An integer?

Agreed. Syntaxes are described by various ABNF pieces, but I don't think this would be clear for IANA.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 06 Oct 2014 17:53:57 +0100

Thanks again for your help with this. Its mysterious stuff
for me;-)

>>             o HOBAREG is not allowed in trailers   

Dunno to be honest. But in looking at 4.1 of 7130 I guess
it seems better to say its allowed.

Think I've made the other changes you recommended.

Cheers,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 06 Oct 2014 18:49:09 +0100

Hi Alexey,

On 06/10/14 17:45, Alexey Melnikov wrote:
>>> On 2014-10-06 15:22, Stephen Farrell wrote: ...
>>>> - in the IANA sections, it would be helpful if the
>>>> specification links would be more specific
>>> 
>>>> - for the new IANA registries, I believe you ought to specify
>>>> the actual format of the registry and/or provide a registration
>>>> form
>>> 
>>> so that entries get added then I'd say that could be fixed
>>> when/if the spec gets put on the standards track and I'm sure
>>> there'd be more to fix then too. ...
>> 

As you said in your offlist mail, this is a bit OBE, so I hope
we're good to go on that part now.

Still wondering if unreserved is best for realm.

Cheers,
S.

---

From: Michael Sweet <[email-masked]>
Date: Tue, 07 Oct 2014 09:36:18 -0400

Stephen,

> On Oct 6, 2014, at 10:42 AM, Stephen Farrell <[email-masked]> wrote:
>> ...

OK, so my only remaining nit here is that it is still part of the list of things that HOBA provides.  I suggest just moving this bullet to be a paragraph following the list.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 07 Oct 2014 14:43:43 +0100

> OK, so my only remaining nit here is that it is still part of the list of things that HOBA provides.  I suggest just moving this bullet to be a paragraph following the list.

Fair point. Done at usual places.

S.

PS: Chairs - I plan to submit -05 late today my TZ if no
more stuff arises. Yell at me if that's a bad plan.