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

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 1 Dec 2014 17:42:22 -0500

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:

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
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/

There would just be a short window until HOBA was defeat-able in spear
phishing related attacks using trojans installed on the client.

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.

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.

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).

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.

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.

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.

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'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.

-- 

Best regards,
Kathleen

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 02 Dec 2014 00:52:41 +0000

Hiya,

> 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:-)

(So far, I made one change below in my local copy that'd go
into a -06 whenever needed.)

> Spear phishing attacks that install trojans have been around for

Not all trojan installs are phishing though.

> 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.

> 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."

> 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.

> issues like password theft and re-use (on same site or others) will be

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.)

> 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.

> reads as if it is just for HTTP, if that's the case, then leave it

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.)

> 6.1, I think it would be better to have the explanation in this

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.)

> 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.

> external secure container does help, but those have been successfully

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. And I think we've hit that difference
in our definitions of phishing again too:-)

So I'd suggest no change there.

> will be once deployed).  This has a niche and we should be clear on

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.

Cheers,
S.

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 1 Dec 2014 20:24:08 -0500

Hi,

Sent from my iPhone

> On Dec 1, 2014, at 7:52 PM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hiya,
> 

Either is fine.  Nothing is too drastic in my review.
> 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.

> but I believe my definition is ok tbh.
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).
> 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. 
> used on hoba.ie with millions of entries on a standard server

Thanks.
> 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.

> 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).
> that this covers both if that helps, but I'm not clear it does

If you could just state what's intended for section 5 so it's clear to the reader, that will help.  Thanks.

> it's clarified in the next para. (Did that in our author's svn

Thanks.
> 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?

> relevant at this point.

Is just the point that this will be broken, it's pretty much inevitable.

> And I think we've hit that difference

I'll get some links to show the common usage and use case descriptions of phishing and spear phishing attacks tomorrow.
> 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.

Have a good night.
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 2 Dec 2014 11:28:38 -0500

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.

> 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.

>> 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 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:

Definitions in RFCs:
The definition of phishing from RFC4949 captures 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.
There's nothing to prevent Cross site scripting from being part of a
phishing attack either.

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."

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):
http://docs.apwg.org/reports/apwg_trends_report_q2_2014.pdf

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/

> 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.

> 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.

> 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 :-)

> 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.

> I was just trying to get you away from the phishing angle as it won't work for long.

Thanks,
Kathleen

-- 

Best regards,
Kathleen

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 05 Dec 2014 16:26:50 +0000

Sorry for being slow, travel and all that...

On 02/12/14 16:28, Kathleen Moriarty wrote:
>>>> On 01/12/14 22:42, Kathleen Moriarty wrote: Hi Stephen, Paul, &
>>>> Michael,
>>>> 
>>>> 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.
>>>> 
>>> 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:-)
>> 

Okey dokey. I've put out a -06 with the changes described
below.

> 
>>> 
>>> (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
>>> 
>> 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.). 
>>> 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.
> 
> 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.
> 
> 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.
> 

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: 

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.

> 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 
> 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:-)

> RSA: Anatomy of an attack (phishing is a typical first step with
> malware installed to gain access) 

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.

>> 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.
>>> 

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.

>>>> 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.
>>> 
>>>> 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.)
>> 
>>>> 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).
>>> 
>>> 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.
>>> 
>>> 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.)
>> 
>>>> 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.
>> 

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.

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

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.
>> 
>>> 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.
>>> 
>>>> 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.
>>> 
> Thanks, Kathleen
>> Have a good night. Kathleen
>>> 
>>> Cheers, S.
>>> 
>>> 
>>>> 
>>>> 
> 
> 
>

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 5 Dec 2014 14:18:43 -0500

Hi,

> Sorry for being slow, travel and all that...

No worries.

> Okey dokey. I've put out a -06 with the changes described

Thank you.

> called the APWG to extend that definition more and more over time

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.

> a uselessly broad (non-)definition IMO.

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

>    of server-side password databases.

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

> got rid of "additional" and replaced it with a ref to section

Thank you.

> 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

-- 

Best regards,
Kathleen