Re: [websec] HTTP Integrity header / Session Continuation scheme

Phillip Hallam-Baker <hallam@gmail.com> Thu, 22 November 2012 17:21 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 A479321F85A1 for <websec@ietfa.amsl.com>; Thu, 22 Nov 2012 09:21:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.082
X-Spam-Level:
X-Spam-Status: No, score=-4.082 tagged_above=-999 required=5 tests=[AWL=-0.484, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 ZcwugsgEmAib for <websec@ietfa.amsl.com>; Thu, 22 Nov 2012 09:21:10 -0800 (PST)
Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5D70A21F8584 for <websec@ietf.org>; Thu, 22 Nov 2012 09:21:09 -0800 (PST)
Received: by mail-vc0-f172.google.com with SMTP id fw7so6975498vcb.31 for <websec@ietf.org>; Thu, 22 Nov 2012 09:21:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=25BQzK7HhhxhTTxhGezYBGMFFxsKY0qtZmn7his1TJk=; b=yevCR+AIrf6grNCjAJFVGVRBu15PMAMz9yZoh6aAWUjKCxHbkSZa1ijoCkdbUKKqRP dMeNf3iNFWs/7kHV0fVz3sOcQ2N+MesuMnRFuoM5S/H8pLUQzA4mB2/ET3aomk6CmETp V8a48lHXxKLrSO542cZG6s3GL+WAgR2NYtrqXC4Vr+k7VR9TZ/9ebAkjJ82Ugi9J8JkY JisB/U3rSSl0+oWaRfTz8NMQKVsjtWxth2KVEtN3jOSeK7XL/NuzhpVv2JpmlZZR56Gi lWuTlgzpsrnCHJe3i6iIDEhibv0V7+J9rH3TWLIM4ACpSzkKdlrnIK/z5OyAdvnUXJ1b 2Wzg==
MIME-Version: 1.0
Received: by 10.220.241.141 with SMTP id le13mr1855494vcb.26.1353604868149; Thu, 22 Nov 2012 09:21:08 -0800 (PST)
Received: by 10.58.19.130 with HTTP; Thu, 22 Nov 2012 09:21:08 -0800 (PST)
In-Reply-To: <4B59D185-7F74-442B-B0F3-5122E1C2498D@gmx.net>
References: <CAMm+Lwh2c4NsHErsbsf3awJn8kt3V1D_KAo7fOW_oSsHA-_BvA@mail.gmail.com> <4B59D185-7F74-442B-B0F3-5122E1C2498D@gmx.net>
Date: Thu, 22 Nov 2012 12:21:08 -0500
Message-ID: <CAMm+Lwi28i3rg0c9zJ=ajRjqYXxtwVStkuEDBcX2t4t9TnoQZw@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Content-Type: multipart/alternative; boundary="14dae9cdc32b55122904cf18b16a"
Cc: websec <websec@ietf.org>
Subject: Re: [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, 22 Nov 2012 17:21:10 -0000

I can implement all the features describes in the OAUTH-MAC draft in my
scheme but I don't think the reverse is true.

The idea here is that we take out the session continuation component and
make it a single common feature that OAUTH, OpenID, SAML and Web Services
authentication schemes can all share so that we have one way to do it for
all HTTP schemes.

Designing in the context of OAUTH only leads to a scheme that is difficult
to then apply as a generic. There are two problems to be addressed in a
session continuation mechanism, one is which parts of the message (if any)
should be covered by the authentication mechanism and second how to prevent
replay attacks. Which choices you take are going to depend on which
particular authentication problem to solve.


If what we are trying to do here is to simply replace bearer token cookies
with something less disastrous then we are not going to want to have any
authentication binding to the content at all so that we avoid the problem
of intermediaries raised by Hannes etc. We are going to be concerned about
replay attacks though and probably want to ensure that the solution is
stateless at the server.

If what we are doing is looking to replace the SOAP/WS-Security stack then
we are going to want a MAC over the message contents and probably the
request URI as well. Replay attack might not be a concern then because we
might prefer to do that in the application layer or if we do it in the HTTP
layer we probably don't care much about the overhead of per connection
state.