Re: [OAUTH-WG] [Ace] Questions about OAuth and DTLS

Michael Richardson <mcr+ietf@sandelman.ca> Fri, 05 February 2016 15:26 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 709BD1B3A43; Fri, 5 Feb 2016 07:26:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.902
X-Spam-Level:
X-Spam-Status: No, score=-0.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_BACKHAIR_12=1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YtEvaXRF1F39; Fri, 5 Feb 2016 07:26:09 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76FD71B3A8B; Fri, 5 Feb 2016 07:26:09 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 7AB962009E; Fri, 5 Feb 2016 10:35:06 -0500 (EST)
Received: from obiwan.sandelman.ca (ip6-localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 6ACA963751; Fri, 5 Feb 2016 10:26:07 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Ludwig Seitz <ludwig@sics.se>
In-Reply-To: <56B36703.8060305@sics.se>
References: <56B31FEB.4010204@sics.se> <16330.1454596303@obiwan.sandelman.ca> <56B36703.8060305@sics.se>
X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.2
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Fri, 05 Feb 2016 10:26:07 -0500
Message-ID: <21409.1454685967@obiwan.sandelman.ca>
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/_5_Yd-N9KhZCkW0cyNbk6UCmWHo>
X-Mailman-Approved-At: Mon, 08 Feb 2016 12:29:58 -0800
Cc: oauth@ietf.org, ace@ietf.org
Subject: Re: [OAUTH-WG] [Ace] Questions about OAuth and DTLS
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
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: <https://mailarchive.ietf.org/arch/browse/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, 05 Feb 2016 15:26:11 -0000

Ludwig Seitz <ludwig@sics.se> wrote:
    > On 02/04/2016 03:31 PM, Michael Richardson wrote:
    >>
    >> Ludwig Seitz <ludwig@sics.se> wrote: > Assuming we are using (D)TLS to
    >> secure the connection between C and RS, > assuming further that we are
    >> using proof-of-possession tokens [2], > i.e. tokens linked to a key,
    >> of which the client needs to prove possession in > order for the RS to
    >> accept the token.
    >>
    >> > Do we need to support cases, where the type of key used with DTLS
    >> does not > match the type of key in the PoP-token?
    >>
    >> > Example:
    >>
    >> > The client uses its raw public key as proof of possession, but the
    >> DTLS > connection C - RS is secured with a pre-shared symmetric key.
    >>
    >> > Is that a realistic use case?
    >>
    >> Before I agree that it's unrealistic, I think it's worth going out of
    >> charter scope and ask how much these two credentials were
    >> created/distributed.
    >>
    >> I think that in this case, the pre-shared symmetric key is initialized
    >> through some out-of-band (perhaps human mediated?) process, while the
    >> raw public key did not need any other pre-arrangement.

    > Actually even the raw public key needs to be provisioned out-of-band to
    > those supposed to trust it for authentication.

First, let me say that I confused RS and RO/AS in my mind when reading before.

Starting again, I think that any PSK for authentication between C<->RS is
unrealistic.

    >> So my question is then: could the out-of-band process have
    >> pre-exchanged the raw public key (and the RS's key/certificate!) as
    >> well?

    > Short answer: Yes but only to the AS not to the client(s).

    > Long answer: I am laboring under the assumption that the AS not only
    > provides the OAuth token and the corresponding PoP key to the client,
    > but also some information on the communication security protocols that
    > the RS supports. Furthermore the AS facilitates the establishment of a
    > security context between client and RS by providing things such as a
    > (D)TLS-PSK or the RS's raw public key, depending on the (D)TLS mode
    > that the RS is going to support. Thus individual clients would not,
    > a-priori, know the raw public key of a RS, but would be able to get
    > that information from the AS.

That seems entirely reasonable.  Would the OAuth token not also be bound to
the Raw RSA key of C?    So RS would never need to be told about C's key,
because the AS would have told it "key XYZ can access resource ABC" in the
OAuth token.

--
Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-