Re: [secdir] [http-auth] secdir review of draft-ietf-httpauth-basicauth-update-06

Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Thu, 19 February 2015 22:35 UTC

Return-Path: <kathleen.moriarty.ietf@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 424421A19F6; Thu, 19 Feb 2015 14:35:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level:
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 77NUDb--0pPk; Thu, 19 Feb 2015 14:35:40 -0800 (PST)
Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7C1C1A19EF; Thu, 19 Feb 2015 14:35:39 -0800 (PST)
Received: by labhz20 with SMTP id hz20so2730101lab.0; Thu, 19 Feb 2015 14:35:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SjiFlI5FRJHXqrVp2B//4u/Um62s5AKQTEmwVWtFkU0=; b=snkj+tw1LpiX9/kV7+PSTEVtExGHRuDEUQRAwgXvOty4HQdEElIQASA1j0HjwtT8mQ 3PYKYJ9PHJIjoGKNpJOJpepCJiGeBp5Cil4BE22NEqmOyzVkWvZy5kIKfCAF9lgKfNoT MMbGtqJcaCvBO6nryYgGWwJOYloqYsfS9etEThnr+WVFqBvOydcQbHAOw+004W8zo5nT LIf3wMZRUv8QkuW10R48WhUn6R5B6QS60Mt3+QnDXJgr26ij1db8ie8HfFbaFLnJ+Mua WXSiLjMzlENT6FYF1981y08DCI4wbpHlwQtghsxt41Zcm6j9laSdYVGdQmA6L0/qGj8V o5Qw==
MIME-Version: 1.0
X-Received: by 10.152.8.229 with SMTP id u5mr6080432laa.4.1424385338299; Thu, 19 Feb 2015 14:35:38 -0800 (PST)
Received: by 10.112.167.101 with HTTP; Thu, 19 Feb 2015 14:35:38 -0800 (PST)
In-Reply-To: <54E648B9.6030606@gmx.de>
References: <874mqjd49v.fsf@alice.fifthhorseman.net> <54E50FC3.9080708@gmx.de> <871tllbw2c.fsf@alice.fifthhorseman.net> <54E6348A.3080606@gmx.de> <87mw49ac9h.fsf@alice.fifthhorseman.net> <54E648B9.6030606@gmx.de>
Date: Thu, 19 Feb 2015 17:35:38 -0500
Message-ID: <CAHbuEH7x1FkWPbAdZn7dk_BUv6mRrQtRrxsmtUE+vSAFMW-jiA@mail.gmail.com>
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
To: Julian Reschke <julian.reschke@gmx.de>
Content-Type: multipart/alternative; boundary=089e0158ab601cdabc050f788eab
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/DPvzInOFvCZxmGc6y6DBNxkavqY>
Cc: "http-auth@ietf.org" <http-auth@ietf.org>, draft-ietf-httpauth-basicauth-update.all@tools.ietf.org, "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] [http-auth] secdir review of draft-ietf-httpauth-basicauth-update-06
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Feb 2015 22:35:44 -0000

Daniel,

Thanks for much for the detailed review and discussion!  It may be helpful
to document some of these concerns in another draft and see what we can do
to improve going forward.  Would you be up for that?

Julian,

Thanks for the discussion.  I think we are close to addressing the concerns
raised and that we can let some slip for this draft since it was meant to
be an update to address internationalization concerns.  It does already say
this isn't a secure choice and this review adds more reasons for that
concern.

The rest is inline.

On Thu, Feb 19, 2015 at 3:34 PM, Julian Reschke <julian.reschke@gmx.de>
wrote:

> On 2015-02-19 21:15, Daniel Kahn Gillmor wrote:
>
>> On Thu 2015-02-19 14:07:54 -0500, Julian Reschke wrote:
>>
>>> The network exchange will be take milliseconds. The string comparison
>>> microseconds. /me not convinced there's a problem here.
>>>
>>
>> as long as the attacker can measure microseconds, and the network
>> exchange has small or regular-enough jitter to be accounted for with
>> statistical techniques, the size difference between these parts doesn't
>> matter to a timing attack.
>>
>>    http://www.cs.rice.edu/~dwallach/pub/crosby-timing2009.pdf
>>
>> says:
>>
>>     The resolution an attacker can time a remote host depends on how many
>>     measurements they can collect. Our simulated attacker using
>>     statistical hypothesis testing was able to reliably distinguish a
>>     processing time differences as low as 200ns and 30µs with 1,000
>>     measurements on the LAN and WAN respectively with. (See Section 6.)
>>
>> Note that salted, hashed passwords where the attacker doesn't know the
>> salt are resistant to using a timing oracle like this to do byte-by-byte
>> guessing.  I still think it's simpler to just recommend that the tests
>> should be constant time.
>>
>
> I'm sorry, I'm not convinced. What do others think?


I think it's okay to leave out mention of side channel attacks like this
timing attack.  It might be useful in a follow up draft or if this were
earlier in the process.

>
>
>  That's true, but padding the entire HTTP request to a standard blocksize
>>>> has different security properties than just padding this field to a
>>>> standard blocksize, because parts of the HTTP request could be under
>>>> control of the attacker.
>>>>
>>>> For example, if Alice can make Bob's user agent fetch arbitrary URLs
>>>> from https://example.com/, then she can pass steadily increasing URLs
>>>> to
>>>> Bob's user agent (e.g. https://example.com/a https://example.com/aa
>>>> https://example.com/aaa) and see at what point the size jumps a
>>>> quantum.
>>>> Restricting the padding to the field that is not under attacker control
>>>> in any part should prevent this attack.
>>>>
>>>
>>> How would the attacker be able to modify fields in the request?
>>>
>>
>> By changing the length of the requested URL (which is part of the
>> request), as described above.  For example, if you visit my website, i
>> can add new <img src="..."> elements trying to fetch whatever URLs i
>> want you to fetch.  If i can watch your traffic, i can compare the sizes
>> of those requests.
>>
>
> But the actual request is still under control of the browser.
>
>  I think it would be great to have a document that describes these
>>> threats and how to mitigate them; in particular comparing HTTP/1.1 and
>>> 2, but I seriously doubt this document would be the right place to do
>>> this.
>>>
>>> (It seems to be as relevant for cookies, no?)
>>>
>>
>> It does seem relevant for cookies, but this draft isn't about cookies :)
>> If there's no document to point to, we should still acknowledge the
>> concern here, no?
>>
>
> Well, I'm actually not concerned yet. If this was a problem in practice
> then we should have evidence, for instance, by finding padding code in user
> agents. I'm not saying there is none, but I do believe that if you are
> serious about this you ought to research yourself what the current state of
> implementations is.


I think it's okay to leave this out for now as well, may be material for
another draft.  Basic is used in lots of places still, so understanding all
the bad things about it may help inspire people to switch to something else
(says optimistic SecAD).


>
>
>  That being said, the heuristics are quite simple: try to decode the
>>> octets with a strict UTF-8 decoder, and if that doesn't fail the input
>>> was likely encoded in UTF-8.
>>>
>>
>> Some binary strings are valid in both character encodings, though,
>> right?  For example, "c3 a1 62 63" in UTF-8 is "ábc", but in ISO-8859-1,
>> it is "ábc" So if my password is non-ASCII in the first place, it could
>> very well match the UTF-8 encoding even though i've intended another
>> one.
>>
>
> Any octet sequence is valid in ISO-8859-1, true.
>
> If the server doesn't know whether a certain sequence is UTF-8 or
> ISO-8859-1, it simply could try both.
>
>  So maybe the heuristic should be: even if the UTF-8 decode succeeds, the
>> server could try its fallback decoding mechanism if the UTF-8 version of
>> the password doesn't match.  (fwiw, my understanding is that facebook
>> checks common accidental variations on the entered password during their
>> (non-basic-auth) login process.  so if my password is b4nanAs, but i
>> type B4NANaS or b5nanAs, facebook might let me in anyway)
>>
>> Is this advisable?  What are the risks of testing two variants of the
>> password against the password table?  I haven't thought this through
>> fully, but it seems like it would be a relevant consideration.
>>
>
> It might.
>
>  In the absence of a signal from the client about their choice of
>>
>
> ...which we can't have unless we switch to a new auth scheme...


Another draft might be good...

>
>
>  encoding, documenting these heuristics and recommending them seems like
>> a useful way to facilitate adoption and uniformity among servers
>> implementing this spec.
>>
>
> I'll think about what advice we can give here.
>
>  And sorry, one more question arises for me on re-read. i'm not sure i
>>>> understand what this means:
>>>>
>>>>      Server implementers SHOULD guard against the possibility of this
>>>> sort
>>>>      of counterfeiting by gateways or CGI scripts.  In particular it is
>>>>      very dangerous for a server to simply turn over a connection to a
>>>>      gateway.  That gateway can then use the persistent connection
>>>>      mechanism to engage in multiple transactions with the client while
>>>>      impersonating the original server in a way that is not detectable
>>>> by
>>>>      the client.
>>>>
>>>> How should the server guard against this attack?  what sort does it mean
>>>> to "turn over a connection to a gateway"?  does "gateway" mean
>>>> "transparent HTTP proxy" or does it refer to something else?  Sorry if
>>>> this is elementary stuff, but the term "gateway" only appears in this
>>>> paragraph.
>>>>
>>>
>>> That text is present in RFC 2617; I don't understand it completely
>>> either.
>>>
>>> Maybe just drop the second half of the paragraph and only mention the
>>> thread itself?
>>>
>>
>> If we drop the second half, i'd still like to know what kind of steps a
>> server should take to guard against the possibility of counterfeiting.
>> If we don't have any recommendations or external references, an
>> unactionable SHOULD seems troublesome.
>>
>
> I'd just say
>
> "Basic Authentication is also vulnerable to spoofing by counterfeit
> servers. If a user can be led to believe that he is connecting to a host
> containing information protected by Basic authentication when, in fact, he
> is connecting to a hostile server or gateway, then the attacker can request
> a password, store it for later use, and feign an error. This type of attack
> is not possible with other authentication schemes, such as Digest
> Authentication."
>
> and leave it at that.


The text proposal looks reasonable. I'll go back through the original
review to make sure nothing was missed.

Thanks again!!

Kathleen

>
>
> Best regards, Julian
>
> _______________________________________________
> http-auth mailing list
> http-auth@ietf.org
> https://www.ietf.org/mailman/listinfo/http-auth
>



-- 

Best regards,
Kathleen