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.
- [websec] HTTP Integrity header / Session Continua… Phillip Hallam-Baker
- Re: [websec] HTTP Integrity header / Session Cont… Stephen Farrell
- Re: [websec] HTTP Integrity header / Session Cont… Hannes Tschofenig
- Re: [websec] HTTP Integrity header / Session Cont… Phillip Hallam-Baker
- Re: [websec] HTTP Integrity header / Session Cont… Phillip Hallam-Baker