[OAUTH-WG] Fwd: draft-ietf-tls-oob-pubkey: The Open Issue
Hannes Tschofenig <hannes.tschofenig@gmx.net> Wed, 11 July 2012 10:57 UTC
Return-Path: <hannes.tschofenig@gmx.net>
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 E27FC21F867E for <oauth@ietfa.amsl.com>; Wed, 11 Jul 2012 03:57:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.409
X-Spam-Level:
X-Spam-Status: No, score=-102.409 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 H7D04wfmyIpA for <oauth@ietfa.amsl.com>; Wed, 11 Jul 2012 03:57:24 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id EAFFD21F867D for <oauth@ietf.org>; Wed, 11 Jul 2012 03:57:23 -0700 (PDT)
Received: (qmail invoked by alias); 11 Jul 2012 10:57:53 -0000
Received: from unknown (EHLO [10.255.128.232]) [194.251.119.201] by mail.gmx.net (mp020) with SMTP; 11 Jul 2012 12:57:53 +0200
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX1/H+NR9hFLHyHB9K5+I/EMaNyUjVSOC7Q8ArSLWx5 XRXzkNufHiyNmk
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Apple Message framework v1084)
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Date: Wed, 11 Jul 2012 13:57:47 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <0B69E351-2826-4F26-A65A-40B4551827AB@gmx.net>
References: <1CA8C4CB-1FD8-4498-9988-41B6334F58FD@gmx.net>
To: OAuth WG <oauth@ietf.org>
X-Mailer: Apple Mail (2.1084)
X-Y-GMX-Trusted: 0
Subject: [OAUTH-WG] Fwd: draft-ietf-tls-oob-pubkey: The Open Issue
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: Wed, 11 Jul 2012 10:57:25 -0000
It would be good to get your feedback here as well as this document relates to the the holder-of-the-key concept (with the exchange of the raw public key in TLS). Ciao Hannes Begin forwarded message: > From: Hannes Tschofenig <hannes.tschofenig@gmx.net> > Date: July 11, 2012 1:56:40 PM GMT+03:00 > To: tls@ietf.org > Cc: Hannes Tschofenig <hannes.tschofenig@gmx.net> > Subject: draft-ietf-tls-oob-pubkey: The Open Issue > > Hi all, > > draft-ietf-tls-oob-pubkey specifies a new TLS certificate type for exchanging raw public keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) for use with out-of-band public key validation. > > Here is the latest draft: > http://tools.ietf.org/html/draft-ietf-tls-oob-pubkey-03 > > I would be great to get your feedback on an open issue that concerns the semantic of the exchange. I believe there are three use cases we would like to support with this work. Below, I provide high level message exchanges to explain those: > > I) Server uses Raw Public Keys (client authentication happens at some other layer) > (the DANE use case) > > client_hello, > raw-public-key-indicator="Server, when you send me your raw public key? I support this out-of-band key validation using DANE." -> > > <- server_hello, > raw-public-key="OK. The certificate structure below contains my raw public key.", > certificate, // with raw public key inside > server_key_exchange, > server_hello_done > > client_key_exchange, > change_cipher_spec, > finished -> > > <- change_cipher_spec, > finished > > Application Data <-------> Application Data > > > II) Client and Server use Raw Public Keys > (the smart object use case - CORE working group) > > client_hello, > raw-public-key="Server, please send me your raw public key and I will then send you mine. Are you OK processing my raw public key for client authentication?" -> > > <- server_hello, > raw-public-key="Below you find my raw public key and please send me your raw public key for client > authentication", > certificate, // raw public key > server_key_exchange, > certificate_request, > server_hello_done > > certificate, // with client's raw public key > client_key_exchange, > certificate_verify, > change_cipher_spec, > finished -> > > <- change_cipher_spec, > finished > > Application Data <-------> Application Data > > > II) Hybrid Scenario > (the OAuth Holder-of-the-Key Use case) > > client_hello, > raw-public-key="I would like to use my raw public key for client authentication with OAuth. I also process X.509 for server-side authentication." -> > > <- server_hello, > raw-public-key="Please send me your raw public key. I use X.509 for server-side authentication", > certificate, // with X.509 cert. > server_key_exchange, > certificate_request, > server_hello_done > > certificate, // with client's raw public key > client_key_exchange, > certificate_verify, > change_cipher_spec, > finished -> > > <- change_cipher_spec, > finished > > Application Data <-------> Application Data > -------- > > QUESTION: Are these all the message exchanges we need? Are there some problems with the exchanges? > > Ciao > Hannes >
- [OAUTH-WG] Fwd: draft-ietf-tls-oob-pubkey: The Op… Hannes Tschofenig