[websec] HTTP Integrity header / Session Continuation scheme

Phillip Hallam-Baker <hallam@gmail.com> Thu, 15 November 2012 01:54 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: websec@ietfa.amsl.com
Delivered-To: websec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2529821F84D5 for <websec@ietfa.amsl.com>; Wed, 14 Nov 2012 17:54:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.61
X-Spam-Level:
X-Spam-Status: No, score=-3.61 tagged_above=-999 required=5 tests=[AWL=-1.252, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xRYOUVHFSOGR for <websec@ietfa.amsl.com>; Wed, 14 Nov 2012 17:53:58 -0800 (PST)
Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9C34921F84C4 for <websec@ietf.org>; Wed, 14 Nov 2012 17:53:58 -0800 (PST)
Received: by mail-oa0-f44.google.com with SMTP id n5so1233496oag.31 for <websec@ietf.org>; Wed, 14 Nov 2012 17:53:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=k4YQHe012Qya8BOKesdUUzYSbgkdG1kFfVl/mBy8lqU=; b=Z1SiNjetFclSGFl0WO0l7En6lrP6b1F17ek6OaSDqdxaRZ0cbacwmBN6OU/wVHekAC b7G9d4vp6exAlnhJ2Daz2hkJZogze/C6htBDIhKgNZthjcDNPYsIj7Udf/x9XsN1enqI dsHkUN2REYJw8BFeZxznCPpYKqqQz95ArTIzw/JhXz+cmZ3nalFHNwVu4d4kL0vr4RVE yabm1GDJeXOsqKrnC/gWzWeEGBC2LYzNwVP9bt3fu4oRMJ6C4eeZHUwHYrJMSKqXER0g NwRvEp+IOhH2955DU8P7MtI3oQShrsAEc2CxR9wWxm7G7kEeR68MTGdLgNf+B8SjEdbs vn/w==
MIME-Version: 1.0
Received: by 10.60.28.42 with SMTP id y10mr21225195oeg.24.1352944438123; Wed, 14 Nov 2012 17:53:58 -0800 (PST)
Received: by 10.76.27.103 with HTTP; Wed, 14 Nov 2012 17:53:57 -0800 (PST)
Date: Wed, 14 Nov 2012 20:53:57 -0500
Message-ID: <CAMm+Lwh2c4NsHErsbsf3awJn8kt3V1D_KAo7fOW_oSsHA-_BvA@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: websec <websec@ietf.org>
Content-Type: multipart/alternative; boundary=e89a8f503b84a29d6404ce7eec09
Subject: [websec] HTTP Integrity header / Session Continuation scheme
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <websec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/websec>, <mailto:websec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/websec>
List-Post: <mailto:websec@ietf.org>
List-Help: <mailto:websec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/websec>, <mailto:websec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Nov 2012 01:54:00 -0000

There is a new draft at:
http://tools.ietf.org/html/draft-hallambaker-httpintegrity-02

One of the biggest holes in the Web Security scheme is the fact that
cookies end up being used as bearer tokens and this is a very, very bad
idea. It leads to all sorts of cookie stealing schemes which are very hard
to deal with because while the HTTP stack is simple, the Web stack of HTTP
+ HTML + JavaScript + Random plugins is very complicated and many parts
were originally designed by people who didn't know what the rest did.

While we cannot move to eliminate cookies overnight, there are some
companies with affiliate schemes that are loosing seven or eight figure
sums each year in affiliate fraud. If even one of the major browsers
supported a mechanism that prevented cookie stealing, they would see an
instant return.


The scheme described in the draft is NOT an authentication scheme, rather
it describes one small part of the authentication scheme, the part that
allows an authentication/authorization context established in one protocol
exchange to be continued into further transactions.

The mechanism by which the authentication context is established is outside
the scope of the draft because that is an area where there can be a lot of
useful variation. If an organization has a Kerberos server or SAML
infrastructure already then it makes sense to use those. There is never
going to be a single canonical means of managing user credentials or
presenting/validating them.

But when you look at how a good authentication mechanism continues on from
the point the session has been established it pretty much boils down to
some form of identifier to specify the session and some sort of shared
secret used to create a result that authenticates the session. We can add
in additional information such as nonces and time values and counters and
the like to prevent replay attacks but these are generic mechanisms that
can be used to the same effect whether we used Kerberos, OpenID, SAML or
some newfangled scheme to set up the context.


I am not quite sure where this would be best progressed. In the short term
I was thinking of applying for a provisional HTTP header assignment so that
I can start using it in the Web Service protocol I am writing (omnibroker).
But right now the scheme could fit in WebSec or could fit in HTTPbis or
even the proposed Web Authentication WG.

Regardless of where the work ends up, I think it is clear that if we are
going to specify any new HTTP authentication schemes we are going to end up
addressing the issue of session continuation somewhere and that the
eventual solution needs to be reviewed by the people in all three places
(if they are distinct persons).


-- 
Website: http://hallambaker.com/