Re: [Ietf-http-auth] Re: [dix] Notes on Web authentication enhancements

Sam Hartman <hartmans-ietf@mit.edu> Thu, 06 July 2006 19:07 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyZCJ-0000gJ-Hf; Thu, 06 Jul 2006 15:07:35 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyZCI-0000eb-CY for dix@ietf.org; Thu, 06 Jul 2006 15:07:34 -0400
Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyZCG-00059n-W9 for dix@ietf.org; Thu, 06 Jul 2006 15:07:34 -0400
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 23EEBE0079; Thu, 6 Jul 2006 15:07:57 -0400 (EDT)
From: Sam Hartman <hartmans-ietf@mit.edu>
To: EKR <ekr@networkresonance.com>
Subject: Re: [Ietf-http-auth] Re: [dix] Notes on Web authentication enhancements
References: <20060619220742.40B85222427@laser.networkresonance.com> <tsl3bdoiq9g.fsf@cz.mit.edu> <86mzbqbwjm.fsf@raman.networkresonance.com>
Date: Thu, 06 Jul 2006 15:07:57 -0400
In-Reply-To: <86mzbqbwjm.fsf@raman.networkresonance.com> (Eric Rescorla's message of "Mon, 03 Jul 2006 07:19:41 -0700")
Message-ID: <tslk66qa6wi.fsf@cz.mit.edu>
User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64
Cc: Digital Identity Exchange <dix@ietf.org>, ietf-http-auth@lists.osafoundation.org
X-BeenThere: dix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Digital Identity Exchange <dix@ietf.org>
List-Id: Digital Identity Exchange <dix.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dix>, <mailto:dix-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dix>
List-Post: <mailto:dix@ietf.org>
List-Help: <mailto:dix-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dix>, <mailto:dix-request@ietf.org?subject=subscribe>
Errors-To: dix-bounces@ietf.org

>>>>> "Eric" == Eric Rescorla <ekr@networkresonance.com> writes:
    >> An additional issue is hijacking: without cryptographic
    >> binding, an attacker who observes a request can make future
    >> requests in the name of the user via a cut-and-paste attack
    >> (remember, the token is bearer). If you take the threat of this
    >> type of attack seriously, you need to run the traffic over
    >> SSL/TLS. [1]
    >> 
    >> 
    >> [1] Note that if you're worried about this class of attack, you
    >> need *every* PDU to be cryptographically bound to the
    >> credential with all designs. If, for instance, you use
    >> cert-based auth but then transition to cookies over HTTP for
    >> state management, there's a cut-and-paste attack there.
    >> 
    >> 
    >> I think the primary paragraph is misleading.  We've started
    >> from an assumption that there are practical problems that
    >> prevent server certificates from being validated.  Given this
    >> assumption I don't understand how TLS actually gives us
    >> protection against the hijacking.

    Eric> Imagine a case where you have credentials that have CRA but
    Eric> not HRA. A good example is Boneh's PwdHash, which includes
    Eric> the domain name of the server in the "password". If it's
    Eric> restricted to use with SSL/TLS then you know that each RP
    Eric> will have a unique domain name and therefore each "password"
    Eric> is unique to a single RP, so there's automatic CRA--if the
    Eric> user is phished the phisher must pose as a different RP
    Eric> because he has a different certificate. [0]

This is not true of all credentials that have cra but not ha--or at
least I don't see why it is.  TLS only provides security because you
bind the two authentication layers together by using the same naming
for both the TLS authentication and the higher layer authentication.
(It also assumes that your CA is trusted; that assumption seems
consistent with our threat model.)

I was explicitly trying to get at the fact that you needed to do
something in addition to TLS.  Here you've made the naming be the
same.

    >> I also think the footnote ignores an important deployment
    >> model.  I may be concerned about whether I have reached the
    >> right RP while not concerned about network level hijacking.  So
    >> I'm not at all convinced that you always need to protect every
    >> exchange if you are concerned about hijacking in some
    >> situations.

    Eric> By hijacking, I mean network level hijacking. If you mean
    Eric> typos and phishing, then I think this is a different threat.

Can we have a name for that threat, because I thought you were lumping the two together.


_______________________________________________
dix mailing list
dix@ietf.org
https://www1.ietf.org/mailman/listinfo/dix