Subject: [secdir] SECDIR review of draft-ietf-httpauth-hoba-08.txt

From: Donald Eastlake <[email-masked]>
Date: Sun, 28 Dec 2014 15:50:48 -0500

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  Document editors and WG chairs should treat these comments just
like any other last call comments.

This draft specifies an Experimental protocol to use digital
signatures in response to challenges for authentication to HTTP
servers as a replacement for passwords. There are a lot more details
than that and considerable effort has been put into making this fit
into existing web authentication so as to be easily deployable.
Overall, it looks like a good job. See comments below.

As a heavily security oriented draft, I recommend it be looked at by
the non-author Security AD :-)

> Security Comments <
---------------------

This draft is fairly clear about what happens when mandatory 2119
requirements are violated in strictly security contexts, such as a
signature not validating. But is generally doesn't say much about
what happens when mandatory formatting requirements are violated. I
guess if things don't parse, then authentication will fail. But, for
example, it says "The "realm" attribute MUST NOT appear more than
once." Whenever I see something like that, I say to myself, OK, so
what happens if the "MUST NOT" is violated? If the spec says nothing,
then I would expect that with some implementations authentication
would fail while others would use the first realm attribute and still
others would use the last realm attribute. Could that be a problem?

This draft uses "random" and "randomness" in various places without
any reference/definition.

Security Considerations:

Perhaps there should be a reference in the Security Considerations
section to Section 1.1.

Can some level of confusion/denial be caused by setting max-age to a
lower value than the server intended?

Appendix B: It is good that an example is provided it seems like some
things are missing. Shouldn't it specify the "alg" string and wouldn't
it be useful if it gave the TBS blob explicitly?

> Wording/Format Comments <
---------------------------

Abstract: I always worry about words like "all" (or, being recursive
to this sentence, "always" :-). I suggest deleting the one occurrence
of "all" in the Abstract.

Page 5, Section 1.2
OLD
   That will contain of at least one CPK and a web-origin;
                  ^^
NEW
   That will contain at least one CPK and a web-origin;

Page 6/7/13, Figure 1/2/3: I'm not sure that something that is
entirely textural is best called a "Figure". But in any case, since
the text is, or at least has, lines that are flush left, it looks like
part of the preceding text and there isn't a clear demarcation of the
start. I recommend that the body of the Figures be indented 3 or 4
spaces.

Page 6, Section 2:
- For "alg" inconsistently says it is "an ASCII character" and "ASCII
numbers" where perhaps it should say "an ASCII encoded one or two digit
non-negative integer" or something.
- For "origin" perhaps the example should note that it would be
prefixed by "28:" in the TBS blob.
- Delete one of the two sequential occurrences of "reduce the amount
of".

Page 10, Section 5:
I suggest rewording this sentence:
OLD
   This section also
   covers the actions that give HOBA similar user features as today's
   passwords have.
NEW
   This section also
   covers the actions that give HOBA user features similar to today's
   passwords.

Page 16, Section 6.4: duplicated word "response".

Page 18, Section 8.2: Is it a good idea to mention a particular
on-line service name here?

Page 19, IANA Considerations: It seems from
draft-leiba-coton-iana-5226bis that IANA would prefer IANA
Considerations to be written in the past tense as if the actions had
already been accomplished, presumably to minimize IANA re-writing
effort. Thus, I suggest that consideration be given to changing the
initial part, between the Section 9 heading and the Section 9.1
heading, to the following and making similar changes in the remainder
of the IANA Considerations Section:

   IANA has created the registries and made the registration specified
   below, placing the new registries in a new "HTTP Origin-Bound
   Authentication (HOBA) Parameters" category.

Page 20, Section 9.3: A better way to note the restriction on
potential values of Algorithm Name would be to add a third entry to
the registry something like the following (there should also be a
third Reference column):

 2-99        Unassigned        [this document]

Page 20, Section 9.4: Suggest the "Meaning" for 2 be "an unformatted
UTF8 string". There should probably be a Reference column. "a small
positive integer" is undefined.

Page 20, Section 9.5: Seems like this should say "UTF8 string" and I'm
not sure it needs "at the user's/UA's whim". There should also be a
"[this document]" entry in a Reference column.

Maybe there should be ABNF for "kid" and "did" somewhere. Since "kid"
and "did" are ordinary English words, suggest globally replacing them
with "KID" and "DID" respectively.

Page 24, Appendix A
This is a nice appendix but there is no reference to it anywhere in the
body of the draft. Suggest adding such a reference to the
Introduction.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 30 Dec 2014 17:52:09 +0000

Hi Donald,

Thanks for the review.

> the non-author Security AD :-)

Reasonable plan:-) I'm sure Kathleen has it in hand.

>> Security Comments <

Well, we could add a generic sentence saying "if formatting is bad in
any way then servers MUST fail authentication" but I think that'd
just be repetition really.

> any reference/definition.

True. I'd argue that that's ok, but I suppose a reference to rfc4086
might be useful. If pressed, I'd not object to adding one.

> Perhaps there should be a reference in the Security Considerations

I think that'd just be repetitive though, the point is made in 1.1.

> lower value than the server intended?

I don't believe so.

> it be useful if it gave the TBS blob explicitly?

Yep - you're right that we ought say its rsa-sha256, though to be fair
the consumer of the example only has two values from which to guess;-)
But if there's any change made (almost inevitable:-) then I'll make
sure to include that in a -09.
>> Wording/Format Comments <

Ah crap - so I defo do need a -09, ah well, I'll make the chages
above as well so:-)

> start. I recommend that the body of the Figures be indented 3 or 4

I'd prefer let the RFC editor fix those if needed.

> non-negative integer" or something.

Tweaked to remove a bit of repetition.

> prefixed by "28:" in the TBS blob.

That's the len all right, but that's just a per the abnf. I don't
think saying so would make it easier to code.

> - Delete one of the two sequential occurrences of "reduce the amount

Did that.

>    covers the actions that give HOBA user features similar to today's

Almost

> Page 16, Section 6.4: duplicated word "response".

Sigh, why do I keep doing that:-)

> on-line service name here?

I think its fair.

>    Authentication (HOBA) Parameters" category.

I'd rather not go there. I've also seen the opposite request
made so would prefer to not be involved in such bureaucratic
battles:-)

>  2-99        Unassigned        [this document]

I'm not convinced that's better tbh and as-is its fine so no
change there.

> positive integer" is undefined.

Oh come on. Small positive integer utterly clear as is unformatted
string in this context. UTF8 isn't needed here as this is not meant
to be seen by a user.

> "[this document]" entry in a Reference column.

I added UTF8 since this could be presented to a user. (Good catch
that.) I didn't make the other changes.

> with "KID" and "DID" respectively.

No thanks - it's clear enough and upper case wouldn't make it better
I think.

> body of the draft. Suggest adding such a reference to the

I think we had it earlier and were asked to take it out. And
I think that's fine as-is.

Thanks for the good catches.

I've a working copy of a -09 at [1], with the diff vs. -08
at [2]. I'll wait for Kathleen to say if she wants that posted
now or not, as almost all the changes are nit-fixes.

Cheers,
S.

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

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 30 Dec 2014 13:19:24 -0500

Thanks for the review, Donald and the quick response, Stephen.  Too posting, sorry.

Yes, please do go ahead and post the -09 version to correct the mostly editorial changes in case it helps any of the IESG reviews.  I'll add the ballot after that.

Thanks,
Kathleen

Sent from my iPhone

> On Dec 30, 2014, at 12:52 PM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hi Donald,
> 
> Thanks for the review.
>

---

From: Barry Leiba <[email-masked]>
Date: Tue, 30 Dec 2014 14:48:22 -0500

On just a couple of points...

> I'd prefer let the RFC editor fix those if needed.

I think that if we think a change in the formatting would make things
clearer, we should do that ourselves, and not defer it to the RFC
Editor.  *We* should be happy with the document before we send it
over.

>> of the IANA Considerations Section:

I'm with Stephen here: please leave this alone.  At this point, the
document is making a request, and that's a fine way to put it.

> string in this context. UTF8 isn't needed here as this is not meant

With this and all other strings, the question isn't whether users are
going to see it or not, but how implementors are supposed to know what
a "string" is and how to create it.  If it's an arbitrary sequence of
bytes, then it should say that, rather than "string".  If it's really
a string and is meant to represent characters in some encoding system,
then it needs to say either what encoding system that is (UTF-8,
US-ASCII, or whatever) or that it doesn't matter and that any encoding
can be used.  The latter only works if the string is never consumed by
an entity other than the one that created it.

Barry

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 30 Dec 2014 16:45:59 -0500

Hi Stephen,

> Editor.  *We* should be happy with the document before we send it

I agree with Barry here, especially since you are providing an -09 soon.

> document is making a request, and that's a fine way to put it.

I'm fine with leaving this as well.
> an entity other than the one that created it.

Thanks Donald & Barry.

Best regards,
Kathleen

-- 

Best regards,
Kathleen

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 30 Dec 2014 22:09:02 +0000

Hiya,

> Editor.  *We* should be happy with the document before we send it

I figure this is such a minor change that we are actually happy,
even if we might also like to nitpick ourselves unhappy from time
to time;-)

> a "string" is and how to create it.  

In these cases coders look @ the IANA registry to find the string
in question. If IANA, and some expert, manage to muck up that badly
then I suspect we have worse problems. I only agreed with the UTF8
addition in the did case as I could see that being presented to a
user as a "you last logged in from a &^%SS device on Tuesday" so
there's a chance that a non ASCII string might be worthwhile there.
For a kid type (not kid, but a kid type) that's just not worth even
these electrons, even if it appears to bear all the markings of a
good i18n bunfight:-)

Neither string is ever sent in the HOBA protocol itself.

S.

> If it's an arbitrary sequence of

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 30 Dec 2014 22:13:03 +0000

> I agree with Barry here, especially since you are providing an -09 soon.

It would not make things clearer IMO. It would shuffle the characters
to the right, and in a few cases off the rhs of the text area and
thereby be an editorial pain that is purely worthless.

Are we really saying that the figures in question (which are anbf)
are really hard to distinguish from the other text?

If you tell me they really really are then I'll move it to the right
but whilst also grinding my teeth at the crapology that we force
authors to endure at process-end and wishing that the IESG and others
were wiser about that. (Myself included from time to time no doubt;-)

S.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 30 Dec 2014 22:32:14 +0000

Sadly, it was probably quicker to take the pointless pain (of
arm wrestling xml2rfc's ideas of abnf and alignment) rather
than argue more against this pointless change. So I moved the
figure-text precisely 3 characters to the right. (It was not
hard though, but only because I got lucky in discovering that
a line of whitespace before the text worked somehow.)

Anyway -09 is posted with that pointless change. But also
with the other all very worthwhile changes Donald suggested.

S.

PS: Yes, I really do think we ought not foist this kind of
nonsense on authors.

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 30 Dec 2014 19:49:07 -0500

Thanks, Stephen.  I guess you caught the gap of time when I was out at dinner.  

Kathleen 

Sent from my iPhone

> On Dec 30, 2014, at 5:32 PM, Stephen Farrell <[email-masked]> wrote:
> 
>