Re: [websec] draft-williams-websec-session-continue-prob-00

James M Snell <jasnell@gmail.com> Tue, 15 January 2013 16:05 UTC

Return-Path: <jasnell@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 05F6721F8757 for <websec@ietfa.amsl.com>; Tue, 15 Jan 2013 08:05:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.416
X-Spam-Level:
X-Spam-Status: No, score=-4.416 tagged_above=-999 required=5 tests=[AWL=-2.484, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_FWDLOOK=1.666]
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 OCZOqax2k6y9 for <websec@ietfa.amsl.com>; Tue, 15 Jan 2013 08:05:13 -0800 (PST)
Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com [209.85.223.178]) by ietfa.amsl.com (Postfix) with ESMTP id E24E121F8632 for <websec@ietf.org>; Tue, 15 Jan 2013 08:05:12 -0800 (PST)
Received: by mail-ie0-f178.google.com with SMTP id c12so452366ieb.23 for <websec@ietf.org>; Tue, 15 Jan 2013 08:05:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=FPSmQfbLzhkSZsDyaIcBFYMH4+jZHC72FJ9YtZVc4+g=; b=e2KkFaX/kaPMHCkQqBmbBuAAvWwOukoxv32XXdv4+6YixEo4at4MIOVlFStXpXax7S bQ2Vtlv8ZyUq/k+X+kOHj7ikV9cO2kiKvllfcpaomZJxvhZTJrJI9XW4nYDrWbKr3sPi FZHXDwaHm30n+PUYf3KColUBNEP0IvjsnnFQpiMw0R1FOKhsP2cYKr0JOgOd1nWUGGQN P9EujZbZPS+TeYCMxUs80s1JT7HElQezgQKak3Qwi7QgQs7xLvlG9OgVa3ZoK4Hyouca Og/gvwsUtFLL0ZjiFwsu8sqJTPH1HDVK7lq7EK1op97QU0GamesPS3ekzpG97cA1CxYo nZDg==
Received: by 10.50.196.227 with SMTP id ip3mr1974642igc.97.1358265912462; Tue, 15 Jan 2013 08:05:12 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.26.137 with HTTP; Tue, 15 Jan 2013 08:04:52 -0800 (PST)
In-Reply-To: <4613980CFC78314ABFD7F85CC302772111984CB4@IL-EX10.ad.checkpoint.com>
References: <CABP7RbcUNkxZ55T626iGBVCVRzt_r6DsyLBLeEjN-of8H3xHFA@mail.gmail.com> <4613980CFC78314ABFD7F85CC302772111984CB4@IL-EX10.ad.checkpoint.com>
From: James M Snell <jasnell@gmail.com>
Date: Tue, 15 Jan 2013 08:04:52 -0800
Message-ID: <CABP7Rbe2AeC9gFz0RCVzVdHw0zj2ytwgTzBpB2QyiKwLWL9uqw@mail.gmail.com>
To: Yoav Nir <ynir@checkpoint.com>
Content-Type: multipart/alternative; boundary=14dae934117b390c3104d355ed96
Cc: "<websec@ietf.org>" <websec@ietf.org>
Subject: Re: [websec] draft-williams-websec-session-continue-prob-00
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: Tue, 15 Jan 2013 16:05:14 -0000

On Tue, Jan 15, 2013 at 6:04 AM, Yoav Nir <ynir@checkpoint.com> wrote:

>  Hi James
>
>  I've now read your draft. It looks to solve the same kind of problem as
> PHB's integrity draft [1], although that one currently uses HTTP/1 syntax.
>
>
There is definitely overlap in the use of the integrity frame. Once http/2
is down the road a bit and I see how things evolve there I hope to work
with PHB to reconcile the two mechanisms.


>  The protocol you propose binds a key to a session (or "KEY-ID") and this
> allows to integrity protect both requests and responses. It also allows the
> client to bind specific requests to specific sessions, which is one of the
> requirements in the session-continue draft. Integrity protection of the
> requests (an possibly responses) is definitely a key component of any
> solution to make sessions secure. It doesn't help to authenticate just the
> fact that there is a request, if we then allow a proxy to rewrite the
> entire content of the request.
>
>
Correct.. the original use case for my spec was for key negotiation for
encryption of individual spdy frames and establishment authenticated
credentials. It can, however, be leveraged for a broader set of cases but
there are certainly details that would need to be ironed out (not the least
of which is how these manifest within the http/2 framing layer which is
going to take quite some time to figure out)


>  What's missing for me is a binding of that key-id to an authenticated
> identity. Identities can be authenticated multiple ways. There's the user
> certificate in TLS, Some better or worse HTTP schemes (everything from
> Basic to ZKPPs), two-factor methods using some side-channel (such as
> instant messaging to mobile phones), and even HTTP forms, whether they are
> the insecure kind we use today or something with browser-based encryption.
> I think it would be a worthy goal to have all of these bind somehow to the
> key-id.
>
>
Agreed. That's something I'll be looking at. The keynego frames themselves
allow for a range of protocols for establishing a key, and multiple keys
can be negotiated for a single session. For instance, we can have a keynego
exchange that authenticates both the client and servers identities and
establishes a shared secret key that is then used to encrypt the individual
frames in the stream. Again tho, this is very preliminary and there are
many details to work out. At this step, I largely just wanted to make sure
people were aware of the draft as the discussion moves forward.


>  The other thing that's missing, but should probably be in a separate
> document (that I think we're not ready to start yet) is a specification of
> client behavior, meaning when should the client use the same session id (or
> "key id") for different requests. For example, if I have gmail open in one
> browser tab, and in another tab I have a site, where teh HTML says "<img
> src="mail.google.com/imgs/yellow_arrow.gif">"if">", should the request to
> mail.google.com use the same key id that I am using with GMail?  The one
> that is bound to my identity? With the current cookie mechanism, the answer
> is yes. If we define a new session mechanism, we can re-think this.
>
>
Agreed.

- James


>  Yoav
> [1] http://tools.ietf.org/html/draft-hallambaker-httpintegrity-02
>
>  On Jan 14, 2013, at 11:36 PM, James M Snell <jasnell@gmail.com> wrote:
>
>  Hello,
>
>  Just jumped over here from the http list per Yoav Nir's request for
> feedback with regards to the draft-williams-websec-session-continue-prob
> draft.
>
>  Overall I think the draft is a good start. There definitely does need to
> be more of an explanation as to why the existing cookie-based mechanism is
> bad.
>
>  As far as more forward looking feedback is concerned, I wanted to point
> to the In-Session Key Negotiation draft I wrote as input to the ongoing
> http/2 discussion
>
>    http://tools.ietf.org/html/draft-snell-httpbis-keynego-00
>
>  This draft introduces a new (currently experimental) bidirectional
> key-negotiation sub-protocol within spdy/http2 for the negotiation of
> secure keys and can be used for the establishment of authenticated and
> unauthenticated sessions. (Note that I'm just making sure folks know
> about this draft as it is relevant to the discussion)... Running down
> through the list of requirements stated by the websec-session-continue-prob
> draft it covers a good deal of the issues.
>
>  - James
>
>
>