Subject: [dix] Agenda bashing

From: Pete Resnick <[email-masked]>
Date: Mon, 3 Jul 2006 00:02:11 -0500

So, from the conversation so far, these are the 
architectural/protocol issues I think need discussing at the BOF:

- Discussion of the scope and number of the mechanisms. There seem to 
be desires for (1) the ability for the user to identify to the server 
(probably authenticating, preventing phishing as much as possible), 
(2) the ability to transfer user attributes to the server, (3) the 
ability to store user attributes remotely, and (4) the ability for a 
3rd-party to warrant user attribute claims.

- Discussion of the pros and cons of mechanisms that involve changes 
to the user agent versus mechanisms which rely on a separate identity 
server to do all of the work without changing the user agent (e.g., 
DIX).

- Discussion of the types of authentication mechanisms to be used. 
(I read Ben as saying it should be a general mechanism not tied to 
HTTP, Eliot and Terry as saying that the underlying mechanism should 
be common but that there should be HTTP-specific protocol, and John 
as having no interest in solving that particular problem. :-) )

I don't think these discussions need to be spurred by presentations. 
Most of this is going to be a high-level discussion and should 
definitely not reference any particular mechanism. (If logistics 
permit, I'd like to do a "pass the mic" format instead of standing in 
a queue at the mics, and I will do floor control.) With that in mind, 
here's what I have in mind for a meeting agenda:

(Pre-meeting: Find minutes and jabber people - volunteers NOW would 
be useful!!)
- Start passing blue sheets, Agenda bash - 2 minutes
- What problems are we trying to solve? - 1 hour
    - Discuss what sort of authentication/identification from user to 
server is desired
       - Anti-phishing discussion here
    - Discuss what sort of attribute info from user to server is desired
    - Discuss whether remote storage of attributes is desired
    - Discuss whether 3rd-party claims are desired
- What sorts of mechanisms should we use? - 1 hour
    - Discuss downsides of using current web auth mechanisms (i.e., 
user-agent changes)
    - Discuss downsides of using mechanisms that include no user-agent changes
    - Discuss authentication mechanism in light of above discussions
- What work items do we have? - 28 minutes
    - Enumerate work items
    - Enumerate documents (if different than above)
    - Enumerate editors
- End

I have posted this for the agenda web page, but we can always make changes.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

_______________________________________________
dix mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dix

---

From: Eliot Lear <[email-masked]>
Date: Mon, 03 Jul 2006 09:27:20 +0200

Pete,
> So, from the conversation so far, these are the architectural/protocol
> issues I think need discussing at the BOF:
>

On point (1) in order to fix phishing it is the server that must
properly authenticate to the user (e.g., other way round).

> server to do all of the work without changing the user agent (e.g., DIX).
>
> - Discussion of the types of authentication mechanisms to be used. (I
> read Ben as saying it should be a general mechanism not tied to HTTP,
> Eliot and Terry as saying that the underlying mechanism should be
> common but that there should be HTTP-specific protocol, and John as
> having no interest in solving that particular problem. :-) )
The focus needs to be on commonality.  We want to avoid having to do
this for each and every protocol separately.  Using something like SASL
would be ideal.

I will not be present in Montreal, but I am very interested in the
problem space, and may propose solutions in the coming months.

Eliot

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 03 Jul 2006 10:17:41 -0700

> properly authenticate to the user (e.g., other way round).

That's *one* way to attack phishing (at least the current form).
There are others (cf. PwdHash)

-Ekr

---

From: Eliot Lear <[email-masked]>
Date: Mon, 03 Jul 2006 21:45:32 +0200

> There are others (cf. PwdHash)

I'm sorry, but PwdHash is not enough of a reference for me to
understand, but I claim that the most *effective* way to prevent
phishing is to demand that the server prove its identity enough to know
the right question to ask of the client.  If PwdHash covers this ground,
then we agree.

Eliot

---

From: Pete Resnick <[email-masked]>
Date: Mon, 3 Jul 2006 11:18:27 -0400

>properly authenticate to the user (e.g., other way round).

Good point. That should be called out separately as a desirable item.

>problem space, and may propose solutions in the coming months.

We will hopefully have audio stream and jabber available, so if you 
(or anyone else) is computer-near, please do join us.

pr

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 03 Jul 2006 13:41:29 -0700

Eliot Lear <[email-masked]> writes:

> understand,

http://crypto.stanford.edu/PwdHash/

It's the first hit in Google, FWIW.

> but I claim that the most *effective* way to prevent

It doesn't. It uses an entirely different technique.

I don't think it's profitable to argue about what "most effective"
is, but I don't agree that the mechanism you describe is the only
one.

-Ekr

---

From: "Haripriya S" <[email-masked]>
Date: Tue, 04 Jul 2006 04:11:40 -0600

pwdHash can address two problems: 
 a. theft of the passwords from one website and using the same at other
websites
 b. theft of passwords for the target website by phishing
But techniques like pwdHash cannot prevent phishing attacks where the
phishing sites do not even validate the password from the user, but goes
on to prompt and capture long-term credentials from the user like credit
cards etc. As Eliot pointed out, in such cases it is the server which
needs to be authenticated in a phish-proof way.

Thanks and Regards,
Haripriya
 
>>> Eric Rescorla <[email-masked]> 07/04/06 2:11 AM >>> 

- Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 04 Jul 2006 06:59:39 -0700

> needs to be authenticated in a phish-proof way.

That's one way to look at it. Another is that this is just another
password and should be solved with the same approach.

-Ekr

---

From: [email-masked]
Date: Wed, 05 Jul 2006 19:02:26 -0400

I believe that PwdHash does rely on a certain level of proof of the 
server's identity.  The browser needs to decide that
the domain name that the server is presenting actually belongs to it.  
This is usually done by relying on SSL/TLS.
If the false server can convince the browser that it is in fact the 
targeted domain, then the browser will happily
transmit the full credential (H(password, domain)) to the server.

PwdHash does NOT require that the proved domain match anything the user 
has in mind.  That is, the identity
does not need to be presented to the user, or compared against anything 
the user is doing. This seems to be the
primary problem in phishing attacks (the last foot).  That's where the 
real advantage of techniques like PwdHash are.

Terry

-----Original Message-----
From: Eric Rescorla <[email-masked]>
To: Digital Identity Exchange <[email-masked]>
Sent: Mon, 3 Jul 2006 13:41:29 -0700
Subject: Re: [dix] Agenda bashing

________________________________________________________________________
Check out AOL.com today. Breaking news, video search, pictures, email 
and IM. All on demand. Always Free.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 05 Jul 2006 16:07:03 -0700

[email-masked] writes:

> PwdHash does NOT require that the proved domain match anything the
> user has in mind.  That is, the identity
> does not need to be presented to the user, or compared against
> anything the user is doing. This seems to be the

I think this is a fair summary.

-Ekr

---

From: Eliot Lear <[email-masked]>
Date: Thu, 06 Jul 2006 08:12:31 +0200

> real advantage of techniques like PwdHash are.

Pretty neat.  There are two problems that still really need to be
addressed.  The first is that you need to manage a transition.  It must
be clearly visible to the user when PwdHash is used and when it is not. 
Otherwise someone just phishes the original password and that's the ball
game.

Second, PwdHash still relies on the underlying security of the user's
computer.  I don't know about you but that is a goal I would like to
address.  I want a means to have a secure opaque channel of
communication between the server and the smart card.  That's what I'm
looking for from the IETF.

Eliot

---

From: "Ben Laurie" <[email-masked]>
Date: Thu, 6 Jul 2006 13:11:21 +0100

> looking for from the IETF.

This seems like a worthy goal, but one that is perhaps orthogonal to
other means of authenticating users. Certainly I'd be violently
opposed to requiring users to have smartcards.

---

From: Eliot Lear <[email-masked]>
Date: Thu, 06 Jul 2006 14:15:25 +0200

> opposed to requiring users to have smartcards.

Reiterating: the protocol MUST solve the problem for smart cards, but it
MUST NOT require their implementation.

Eliot

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 06 Jul 2006 05:56:59 -0700

> Otherwise someone just phishes the original password and that's the ball

Of course. Hence all my ranting about how this is a UI problem.

> looking for from the IETF.

Well, you could clearly use PwdHash this way. In fact, that's how
your industry standard challenge-response token works. But it doesn't
really help because you don't have HRA against an attacker who
controls the victim's computer. So, they don't capture your
authentication string but they capture the immediately following
session.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 06 Jul 2006 07:23:19 -0700

Eliot Lear <[email-masked]> writes:

> PwdHash as an algorithm doesn't protect you from a host computer
> compromise.  For that you need architectural separation, which is why
> smart cards etc exist. 

Yes, Eliot, I'm really quite familiar with the principle of 
two-factor authentication. My point was that the algorithm
that PwdHash employs is basically the same one that your 
average challenge response token uses. It's purely a matter
of location.

> It remains up to the end server as to what
> transactions might require additional authentication.  So for instance,
> a bank may choose to authenticate on new payees for online billing or
> for particularly large transactions.  Or not.

The problem is that this only sort-of protects you against host
computer compromise because the token that the user authenticates with
generally isn't cryptographically bound to the request the user
is making. This allows the crimeware to claim it's requesting
you to use your token for innocuous purpose X (e.g, routine
security check) but to actually be using it for malicious purpose
Y. So, it's a liveness check, but not a misuse check. See also
[BF99].

-Ekr

[BF99] "Hand-Held Computers Can Be Better Smart Cards." Dirk Balfanz
and Edward Felten. Proceedings of USENIX Security '99. Washington,
DC. August 1999.

---

From: Eliot Lear <[email-masked]>
Date: Thu, 06 Jul 2006 16:13:26 +0200

smart cards etc exist.  It remains up to the end server as to what

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Fri, 07 Jul 2006 04:36:39 +0200

> average challenge response token uses. It's purely a matter

That the password is at all related to the hash result at all is an
(IMHO) unnecessary risk that would in our scenarios impact more than a
single service.  There exists methods where this is NOT the case.

> Y. So, it's a liveness check, but not a misuse check. See also
Indeed if you don't trust your browser to function properly you are left
with tradeoffs.  As we've seen even in the mobile world, a browser can
get hacked.  But there are approaches to further reduce the risk, like
describing the transaction on a display of the card.  And Eric, keep in
mind one obvious application for all of this: if I want to put an end to
bots at my company, I may want to periodically demand strong
authentication from the PCs for various functions.  Let's see the
malware that is both a useful bot and attempts to fool me into thinking
I'm not sending that email I mean to send.

Eliot

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 06 Jul 2006 22:29:23 -0700

> single service.  There exists methods where this is NOT the case.

Yes, there do. But they all involve lugging some object around,
in which case the problem becomes vastly easier. We need 
a system which doesn't require a token.

> describing the transaction on a display of the card.

Yes. The reference I provided was to one such system.

-Ekr

---

From: Eliot Lear <[email-masked]>
Date: Fri, 07 Jul 2006 10:00:05 +0200

> a system which doesn't require a token.

That's not true, Eric.  Anything you can lug around can be "lugged"
around in software.  It doesn't solve the malware/bot problem, but the
two issues are separate and distinct.

Eliot