Re: [http-auth] Review of draft-ietf-httpauth-hoba-05

[Kathleen Moriarty <[e-mail]>]

Hi,

On Fri, Dec 5, 2014 at 11:26 AM, Stephen Farrell
<[e-mail]> wrote:
>
> Sorry for being slow, travel and all that...

No worries.

>
> On 02/12/14 16:28, Kathleen Moriarty wrote:
>> Hello,
>>
>> As promised, I put together some additional information on phishing
>> attacks and feel strongly that their mention should not be included.
>> I'll answer a few other questions in line as well to clarify things
>> where I can.  Stephen is tied up in meetings today, so we may or may
>> not get a response until later in the day.
>>
>> On Mon, Dec 1, 2014 at 8:24 PM, Kathleen Moriarty
>> <[e-mail]> wrote:
>>> Hi,
>>>
>>> Sent from my iPhone
>>>
>>>> On Dec 1, 2014, at 7:52 PM, Stephen Farrell
>>>> <[e-mail]> wrote:
>>>>
>>>>
>>>> Hiya,
>>>>
>>>>> On 01/12/14 22:42, Kathleen Moriarty wrote: Hi Stephen, Paul, &
>>>>> Michael,
>>>>>
>>>>> I reviewed the latest version of the HOBA draft and it is much
>>>>> improved from earlier versions, thanks for your work on this
>>>>> draft. Hopefully it will help mitigate threats to end users
>>>>> with reduced use of passwords and associated attacks.
>>>>>
>>>>> Here are comments for you to consider:
>>>>
>>>> Cool. Thanks for the reivew. I'm not clear if you regard these as
>>>> things that need fixing before IETF LC or as things to handle
>>>> during/after IETF LC. I'm guessing the latter but not sure but
>>>> it'll be clear as we argue or you start the IETF LC I guess:-)
>>>
>>> Either is fine.  Nothing is too drastic in my review.
>>
>> It's simple enough to update with a few fixes and publish, so an -06
>> is appreciated prior to triggering last call.  It's better to avoid
>> the same discussions if possible and save some time.
>
> Okey dokey. I've put out a -06 with the changes described
> below.

Thank you.

>
>>
>>>>
>>>> (So far, I made one change below in my local copy that'd go into
>>>> a -06 whenever needed.)
>>>>
>>>>>
>>>>> Abstract - I'd remove the bit about phishing attacks and just
>>>>> state that it prevents password theft since there are no
>>>>> passwords to steal, which is covered nicely in the
>>>>> introduction.  Phishing is a bit more complicated, involves
>>>>> several steps that include social engineering to get users to
>>>>> click on links, down;pad of malware/trojans, which are
>>>>> difficult to defeat and may or may not be targeting
>>>>> credentials. Spear phishing attacks that install trojans have
>>>>> been around for
>>>>
>>>> Not all trojan installs are phishing though.
>>> No, but they are commonly part of the phishing and spear phishing
>>> attacks that has the financial sector worried.  I think you should
>>> just say what you mean instead if lumping in phishing
>>> unnecessarily.
>
> "lumping in" is purely rhetorical.
>
>>>>
>>>>> several years and are able to steal all types of credentials
>>>>> including PKI X.509 stored in PKCS#11 containers (Sykipot,
>>>>> Zeus, etc.).
>>>>> http://it.slashdot.org/story/12/01/13/2216218/sykipot-trojan-variant-stealing-dod-smartcard-credentials
>>>>>
>>>>>
> http://www.secureworks.com/cyber-threat-intelligence/threats/zeus/
>>>>
>>>> Hm. I don't consider theft of a private key via trojan to be a
>>>> phish. It is an attack of course, and with similar impact but not
>>>> a phish according to my definition. Happy to be corrected but I
>>>> believe my definition is ok tbh.
>>
>> I put together some information to help with an understanding on
>> current definitions of phishing that include really any method of
>> stealing credentials including crimeware, malware, and trojans.  As
>> such, my strong preference would be to remove mention of phishing
>> and directly state the attack description that HOBA protects a user
>> from and include what attacks to which it may be vulnerable.  It
>> adds unnecessary confusion and is not in line with current
>
> Fully disagree. I find nothing whatsoever confusing about the
> abstract and its mention of phishing.
>
>> terminology to keep the term phishing.  Attacks against HOBA are
>> inevitable and will be used in the phishing world (whatever those
>> attacks are - XXS, etc.), but in general, HOBA does provide improved
>> protection against password theft and reuse.  Stating that instead
>> would be clearer to the reader and accurate.
>>
>> Phishing attacks are broad and cover lots of ground.  They all start
>> with a social engineering aspect, tricking a user to click on a
>> link. The link may be a simple attack (not really the case anymore)
>> or a complex web site pretending to be your financial institution in
>> order to gather your credentials.  While HOBA may help in that
>> instance, the more common phishing attacks today include
>> malware/Trojan (or crimeware that includes malware, trojans, etc.,
>> per the APWG) installs from the link the user is tricked into
>> clicking on.  The link could just as easily include a XXS attack.
>> Phishing attacks will evolve to encompass attacks against HOBA.  Even
>> PKI stored via a PKSC#11 interface is vulnerable to phishing attacks
>> - just not the same attack that steals your password, a variation
>> that uses a trojan.
>>
>> As promised, I went through several sites to get updated definitions
>> to help clear this up:
>
> Thanks. So let's see, since this is the source of our different
> opinions.
>
>>
>> Definitions in RFCs: The definition of phishing from RFC4949 captures
>
> That one is certainly a bit odd, but isn't of much use. It does
> only mention credentials a user can type though.
>
>> the basic concept of phishing as a social engineering attack, but
>> doesn't get into variations that have evolved over time.  The first
>> paragraph of the introduction in RFC5901 (2010 - but was really from
>> 2007) explains the variations better n that malware can be part of
>> the phishing attack.
>
> Right, that says: " The terms "phishing" and "fraud" are used
> interchangeably in this document..." which is odd as clearly not
> all fraud is phishing. However that also goes on to only talk
> about user-entered credentials saying:
>
>                                         The terms "phishing" and
>    "fraud" are used interchangeably in this document to characterize
>    broadly-launched social engineering attacks in which an electronic
>    identity is misrepresented in an attempt to trick individuals into
>    revealing their personal credentials (e.g., passwords, account
>    numbers, personal information, ATM PINs, etc.).  A successful
>    phishing attack on an individual allows the phisher (i.e., the
>    attacker) to exploit the individual's credentials for financial or
>    other gain.  Phishing attacks have morphed from directed email
>    messages from alleged financial institutions to more sophisticated
>    lures that may also include malware.
>
> So far, only human-entered credentials are mentioned.
>
>> There's nothing to prevent Cross site scripting
>> from being part of a phishing attack either.
>
> Well, one could extend a definition to include elephants
> too but that'd also not be very useful:-)
>
>> Wikipedia: https://en.wikipedia.org/wiki/Phishing The third sentence
>> of wikipedia's definition includes mention of malware as well:
>> "Phishing emails may contain links to websites that are infected with
>> malware."
>
> That also says "...directs users to enter details at a fake website
> whose look and feel are almost identical to the legitimate one" which
> matches my idea of phishing.
>
>>
>> It case it helps to see examples of phishing attacks that are common
>> today, here are a few more links:
>>
>> APWG: The APWG posts a Phishing Attack Trend report regularly so you
>> can see the evolution: http://apwg.org/resources/apwg-reports/ They
>> include an updated definition in the latest report that basically
>> says techniques continue to evolve to steal credentials and include
>> malware and other attack vectors.  See the description of
>> 'crimeware' (used in their definition) on page 9 as it includes
>> multiple types. (My opinion - HOBA would only work against phishing
>> attacks for a short period of time):
>
> You are assuming your definition of phishing there, not mine.
> It is of course correct to say that implementations of HOBA
> can be attacked. That clearly does not mean all attacks are
> called phishing though.
>
>> http://docs.apwg.org/reports/apwg_trends_report_q2_2014.pdf
>
> And that says:
>
> "trick  recipients  into  divulging  financial  data  such  as
> usernames  and  passwords"
>
> However, I grant you that it then goes on to say that any malware
> is covered too which is pretty meaningless IMO and makes for a
> quite odd definition. (However, one might easily expect something
> called the APWG to extend that definition more and more over time
> of course:-)

You might not like it, but this is how the term is used today.  I've
been on 3 conference committees this year around incident handling.
The term is a moving target with the only part that is universal is
the social engineering to get a user to click on a link.

>
>> RSA: Anatomy of an attack (phishing is a typical first step with
>> malware installed to gain access)
>> https://blogs.rsa.com/anatomy-of-an-attack/
>
> That seems to use the term to mean anything delivered via
> an email that's crafted to look like something else. Again
> a uselessly broad (non-)definition IMO.

That's why I didn't think you should use phishing in the draft. ;-)

>
>>> You may not, but the incident response world does.  I can get you
>>> some links to show why I think this is a problem.  I've been deeply
>>> embedded in the incident response world for several years and the
>>> folks that work on phishing attacks include the download of
>>> malware/Trojans that result when a user clicks on a link in a
>>> phishing email as part of a phishing attack.  The malware/Trojans
>>> frequently steal credentials among other data of interest.  The
>>> APWG helps with the takedown of malware distribution servers as
>>> part of their response to the phishing use case they support (they
>>> do a few other attack types now too).
>>>>>
>>>>> There would just be a short window until HOBA was defeat-able
>>>>> in spear phishing related attacks using trojans installed on
>>>>> the client.
>>>>
>>>> Yes, but that would not be a phishing attack. HOBA is, as the
>>>> abstract correctly states "not vulnerable to phishing attacks."
>>>
>>> See above, I disagree as the common usage includes the download of
>>> malware as part of a phishing attack.
>>
>> See above updated definitions from good sources.
>
> Again, we disagree - I think those are not good definitions
> at all.
>
> However, this is boring and disputing a non-normative word or
> two is a really bad use of our time so I've changed the abstract
> to say:
>
>    HTTP Origin-Bound Authentication (HOBA) is a digital signature based
>    design for an HTTP authentication method.  The design can also be
>    used in Javascript-based authentication embedded in HTML.  HOBA is an
>    alternative to HTTP authentication schemes that require passwords and
>    therefore avoids all problems related to passwords, such as leakage
>    of server-side password databases.

Thanks for that, I do think this is much more clear.

>
>>>>> By simply stating the password theft, you are covering more
>>>>> attack types that steal passwords on the client side than just
>>>>> those used as part of phishing attacks and lower the complexity
>>>>> from using a full blown PKI.  This is what I think you need to
>>>>> target HOBA's use toward.
>>>>>
>>>>> Section 1 Curious as to how it scales since it seems
>>>>> private/public keys pairs would have to be stored, but I guess
>>>>> that's no different than passwords.  Maybe it doesn't matter
>>>>> with that assumption.
>>>>
>>>> Yep. Scaling isn't a differentiator, it's linear in the size of
>>>> the user population basically. I've used the same nosql DB as is
>>>> used on hoba.ie with millions of entries on a standard server
>>>> with no issues at all.
>>>
>>> Thanks.
>>>>
>>>>>
>>>>> In the third paragraph possible attacks on the server side are
>>>>> mentioned when passwords are used, you should also mention
>>>>> client side issues like password theft and re-use (on same site
>>>>> or others) will be prevented.
>>>>
>>>> I'm not clear that that's worth adding but don't object. I do
>>>> think the password verifier DB theft issue is the main
>>>> distinction between HOBA and password based schemes though so
>>>> would prefer keep that front and centre. (And as you say later,
>>>> that issue is called out eventually.)
>>>
>>> It was a way to get away from the phishing comment to what it
>>> actually helps prevent.
>>>
>>>>
>>>>> You may or may not want to include this, but it does have
>>>>> traction/interest in industry to improve password
>>>>> authentication: Other mechanisms with Basic could combine with
>>>>> other factors to use 'risk-based' authentication systems
>>>>> (geo-location, system properties, etc.).  HOBA could do this
>>>>> too.  This may include browser information (make sure it's the
>>>>> same one each time or prompt with some other auth if it
>>>>> changes), IP layer information to get geo-location (can't
>>>>> travel somewhere in less than x hours - doesn't make sense).
>>>>
>>>> I don't think it'd be a good idea to start to describe other
>>>> mechanisms here, nor to try cover multi-factor authentication.
>>>> There is a fine RFC to be written on that, but this ain't it:-)
>>>> If we tried that, we'd face potentially endless comment from all
>>>> sides which I don't think would be worthwhile. And it'd also
>>>> cause issues for other WG drafts too maybe if some do, and some
>>>> don't try describe multi-factor auth issues.
>>>
>>> It's used in industry to help prevent attacks that involve
>>> credentials, like reuse of credentials stolen in phishing attacks
>>> ;-).  I'm not sure there is interest to standardize, but wanted to
>>> point this out since it's commonly used (pretty ubiquitous in the
>>> financial sector).
>>>>
>>>>> Section 5 If this is describing both HTTP HOBA and HOBA-js, it
>>>>> would be good to state that explicitly and differences that
>>>>> should be noted.  The intro reads as if it is just for HTTP, if
>>>>> that's the case, then leave it alone.
>>>>
>>>> Well, we only use the -http and -js when necessary (i.e. when
>>>> there's a difference) and leave it implicit when its obvious or
>>>> doesn't matter. Does it matter here? (I've no problem adding that
>>>> this covers both if that helps, but I'm not clear it does help.)
>>>
>>> If you could just state what's intended for section 5 so it's clear
>>> to the reader, that will help.  Thanks.
>>
>> This one is left as a request, just calling it out so it doesn't get
>> lost.  Thanks.
>>
>>>
>>>>
>>>>> Section 5.3 Second to last paragraph, first time you use the
>>>>> term join (I think), you should provide a reference or explain
>>>>> what it means as this will likely be asked in subsequent
>>>>> reviews.  You describe it in section 6.1, I think it would be
>>>>> better to have the explanation in this section.
>>>>
>>>> Good point. I think the following para of 5.3 addresses the issue
>>>> though. Probably good to not say "already joined" as the first
>>>> occurrence mind you.
>>>>
>>>> I guess s/already-joined/another/ would be a good change, as it's
>>>> clarified in the next para. (Did that in our author's svn copy.)
>>>
>>> Thanks.
>>>>
>>>>>
>>>>> Section 6 What do you mean by "All additional services MUST be
>>>>> performed in TLS-protected sessions"?  If you are referring to
>>>>> HOBA and HOBA-js or the authentication process as the
>>>>> additional service, it would be better to state that
>>>>> explicitly.
>>>>
>>>> All meaning all:-) We didn't see any point in being selective so
>>>> the all-TLS thing seems easier. You need TLS at least to ensure
>>>> there's no MITM handing off challenges or new public keys being
>>>> submitted etc. So I'm not sure what's not clear tbh.
>>>
>>> The use of the word additional is what raised the question for me.
>>> Can you remove it?
>>
>> This one too - just trying to not get it lost in a reply to myself
>> :-)
>
> Actually before I did this I decided that that's not the right
> change. We only RECOMMEND TLS for the actual authentication
> step which is correct as HOBA ought be usable to replace any
> old cleartext uses of basic or digest, even if it's ridiculous
> that such things still exist. Since the other bits are all new,
> it's ok to have a MUST for TLS for section 6 I reckon. So I
> got rid of "additional" and replaced it with a ref to section
> 5.

Thank you.

>
> Please take a look at the just-posted -06 and then hopefully
> press that "request ietf LC" button:-)
>

Thanks for posting a new version & sure, but it will need a shepherd
report first.  I clicked through a bunch of the buttons, but the draft
shepherd will need to write the report and the chairs can kick it over
to me when ready.

Thank you,
Kathleen

> Ta,
> S.
>
> PS: I didn't check these changes with Paul or Mike as they're
> basically tweaks so it's slightly possible I might have mucked
> up a little but I'm fairly sure they could let us know during
> IETF LC and that'd be fine.
>
>
>
>
>>
>>>
>>>>
>>>>>
>>>>> Section 8.2
>>>>>
>>>>> Second paragraph:  current text: Again it's not clear that we
>>>>> are worse in this regard because the same attacker could get at
>>>>> browser password files, etc too.  One possible mitigation is to
>>>>> encrypt the keystore with a password/pin the user supplies.
>>>>> This may sound counter intuitive, but the object here is to
>>>>> keep passwords off of servers to mitigate the multiplier effect
>>>>> of a large scale compromise ala LinkedIn because of shared
>>>>> passwords across sites.
>>>>>
>>>>> Proposed update: Again it's not clear that we are worse in this
>>>>> regard because the same attacker could get at browser password
>>>>> files, stored PKI credentials (even via PKCS#11 interface), etc
>>>>> too.  One possible mitigation is to encrypt the keystore with a
>>>>> password/pin the user supplies.  This may sound counter
>>>>> intuitive, but the object here is to keep passwords off of
>>>>> servers to mitigate the multiplier effect of a large scale
>>>>> compromise ala LinkedIn because of shared passwords across
>>>>> sites.  This recommendation does not help against possible
>>>>> client side attacks, which are inevitable with the use of
>>>>> phishing/spear phishing related malware and trojans.
>>>>>
>>>>> Explanation: All forms of keys stored on a computer have been
>>>>> subject to attacks, including attacks that automate this theft
>>>>> of passwords and even PKI credentials in malware.  The last
>>>>> sentence of paragraph 2 could be stronger to reflect this
>>>>> inevitability.  Storing the credentials in an external secure
>>>>> container does help, but those have been successfully attacked
>>>>> too.
>>>>
>>>> I agree with your last but the section here is specific to HTPM5
>>>> localStorage as a private key store so pkcs#11 isn't relevant at
>>>> this point.
>>>
>>> Is just the point that this will be broken, it's pretty much
>>> inevitable.
>>
>> Here and the Abstract are the places that may need some adjustment
>> once agreed.
>>
>>>
>>>> And I think we've hit that difference in our definitions of
>>>> phishing again too:-)
>>>
>>> I'll get some links to show the common usage and use case
>>> descriptions of phishing and spear phishing attacks tomorrow.
>>>>
>>>> So I'd suggest no change there.
>>>>
>>>>
>>>>> I'm glad to see the password re-use problem mentioned in the
>>>>> last paragraph, so you don't need that in the intro, but I'll
>>>>> leave my comment there as it is part of the overview as to why
>>>>> it might be a good idea to use HOBA.  You may want to emphasize
>>>>> the difficulty of PKI and the advantage of preventing server
>>>>> side password database attacks since the credentials can be
>>>>> stolen on the client side (or will be once deployed).  This has
>>>>> a niche and we should be clear on that IMO.
>>>>
>>>> Fair points but I think the audience for this are probably aware
>>>> of all that. I don't think we should try sell HOBA in the RFC,
>>>> but just define it - the sales pitch that is absolutely required
>>>> is for elsewhere/others. But maybe others think differently.
>>>
>>> I was just trying to get you away from the phishing angle as it
>>> won't work for long.
>>
>> Thanks, Kathleen
>>
>>>
>>> Have a good night. Kathleen
>>>>
>>>> Cheers, S.
>>>>
>>>>
>>>>>
>>>>>
>>
>>
>>



-- 

Best regards,
Kathleen