Re: [OAUTH-WG] draft-ietf-tls-oob-pubkey: My summary

John Bradley <ve7jtb@ve7jtb.com> Fri, 13 July 2012 13:31 UTC

Return-Path: <ve7jtb@ve7jtb.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 087C721F8821 for <oauth@ietfa.amsl.com>; Fri, 13 Jul 2012 06:31:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.901
X-Spam-Level:
X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[AWL=0.698, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uYs1C29YUi4k for <oauth@ietfa.amsl.com>; Fri, 13 Jul 2012 06:31:47 -0700 (PDT)
Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 71BFF21F8804 for <oauth@ietf.org>; Fri, 13 Jul 2012 06:31:47 -0700 (PDT)
Received: by pbcwy7 with SMTP id wy7so5820286pbc.31 for <oauth@ietf.org>; Fri, 13 Jul 2012 06:32:23 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=y4N5AwFVBcyl/UJdbRbuWdRX7Bv+pHUC5GHe5AxfwaA=; b=MHtF/54hB7tNmBoJ+azSmJdzh2lZf/p4cwCFmDLTf8kLYyVV8eWOdfuvc0wS8pmCad CYI9hu3i1irE0KuDagO4z0my7vysQbKNGkeVbyxf3iIiFNEwqZdz8U7AXjWPxoMdeLES wOVDFnlJnfkpLY9LijrTqMtHKcH2zVR9tq00FVEZ3EzL5Kc/Qzz/hv3nqyvfUkU0lYoA YKof6s3Q6jXykRxOBslEgZwMLEi6Bm3nhcbbbxvfkPxA7rB2B7NLi+sRlEVpXhUvPYl9 XEjBx8f+yOQRLv1pbuC/eh6bEs4g7B7UVj549ExI7hldDk43RlMSTUzZNQOHUl1Rj2sI EQYw==
Received: by 10.68.221.38 with SMTP id qb6mr3751621pbc.144.1342186343509; Fri, 13 Jul 2012 06:32:23 -0700 (PDT)
Received: from [10.2.2.165] (75-147-25-205-NewEngland.hfc.comcastbusiness.net. [75.147.25.205]) by mx.google.com with ESMTPS id ms9sm3243996pbb.43.2012.07.13.06.32.20 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 13 Jul 2012 06:32:22 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: text/plain; charset="us-ascii"
From: John Bradley <ve7jtb@ve7jtb.com>
In-Reply-To: <D5D5341E-BEFB-4CA0-9AE9-0F6160BE37DB@gmx.net>
Date: Fri, 13 Jul 2012 09:32:18 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <70FA7F7B-0ED2-4CE6-986B-673CC7410937@ve7jtb.com>
References: <213AE838-274D-4809-B841-CCCC51C7B3CD@gmx.net> <255B9BB34FB7D647A506DC292726F6E114F7AB4406@WSMSG3153V.srv.dir.telstra.com> <6A196EDE-3AF5-4B17-8F8D-2DA8FD9036AC@ve7jtb.com> <D5D5341E-BEFB-4CA0-9AE9-0F6160BE37DB@gmx.net>
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>
X-Mailer: Apple Mail (2.1278)
X-Gm-Message-State: ALoCoQm6iGv0s8ekqkoBAuNPTQOdn6rixhhkEmQuXXFHIFupGksj5Q+h7JV8xvkMraZHwwQhVt05
Cc: OAuth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] draft-ietf-tls-oob-pubkey: My summary
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Jul 2012 13:31:49 -0000

I am not saying it is unusual in a bad way.

Some people think of TLS client auth happening at the TLS layer.   That is common in  server to server connections.

Decisions based on the client cert can happen at the app layer, as they do in SAML HoK.

I think people have less experience with doing that though.

John B.
On 2012-07-13, at 8:35 AM, Hannes Tschofenig wrote:

> Hi John, 
> 
> authorization decisions are not made by the TLS library - they are made by the application. 
> 
> For example, in the HTTPS case the authorization decision that is made by the client is to compare the content of the cert with the domain part of the HTTP URI. Similar authorization decisions are being made by many applications using HTTP, see http://tools.ietf.org/html/rfc6125.
> 
> So, there is nothing unusual here. 
> 
> 
> Ciao
> Hannes
> 
> 
> On Jul 13, 2012, at 3:13 PM, John Bradley wrote:
> 
>> It sucks for TLS hinting:)
>> 
>> In principal the client needs to know what keypair to use for the TLS session before it is initiated.
>> 
>> The protected resource establishes the session with client auth accepting any client key.
>> 
>> The protected resource compares the client key passed in from TLS with the one in the token as part of token validation, and accepts or rejects the token.
>> 
>> It is different from "normal" TLS client auth in that it is not the TLS layer making the access decision.
>> 
>> John B.
>> On 2012-07-12, at 11:40 AM, Manger, James H wrote:
>> 
>>>> III) Hybrid Scenario (the OAuth Holder-of-the-Key Use case)
>>>> 
>>>> client_hello,
>>>> cert-receive=(X.509, Raw) // (1)
>>>> cert-send=(Raw)             -> // (2)
>>>> 
>>>>                       <-  server_hello,
>>>>                           cert-info=(X.509),// (3)
>>>>                           certificate, // (4)
>>>>                           certificate_request, // (5)
>>>>                           cert-receive=(Raw) // (6)
>>>>                           server_key_exchange,
>>>>                           server_hello_done
>>>> 
>>>> cert-info=(Raw), // (7)
>>>> certificate, // (8)
>>>> client_key_exchange,
>>>> change_cipher_spec,
>>>> finished                  ->
>>>> 
>>>>                       <- change_cipher_spec,
>>>>                          finished
>>>> 
>>>> Application Data        <------->     Application Data
>>>> 
>>>> Legend:
>>>> 
>>>> (1) Client accepts to receive X.509 certs and raw public keys, in this
>>>> order of preference. (Could also be X.509 only in this example)
>>>> (2) The client does have a raw public key for client authentication.
>>>> (3) The server decides to sends his X.509 cert and indicates this in
>>>> the cert-info field.
>>>> (4) The certificate payload contains the X.509 cert.
>>>> (5) The server wants to use client authentication and sends a cert-
>>>> request.
>>>> (6) The certificate request asks for a certificate of type 'raw'
>>>> (knowing that the client supports it from (2)).
>>>> (7) The client indicates that the certificate payload contains a raw
>>>> public key.
>>>> (8) Here is the payload of the certificate itself.
>>> 
>>> 
>>> So the OAuth client completes a TLS handshake with a protected resource using a raw key, but the protected resource doesn't get any authorization for that raw key until it sees an access_token which appear where? In an HTTP header somewhere in the App Data some time after the TLS handshake finishes?
>>> 
>>> --
>>> James Manger
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>