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

Ludwig Seitz <> Thu, 04 February 2016 14:58 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B9E771B30CB for <>; Thu, 4 Feb 2016 06:58:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3TEWqkZuhItE for <>; Thu, 4 Feb 2016 06:58:17 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4010:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4F5721B30C7 for <>; Thu, 4 Feb 2016 06:58:17 -0800 (PST)
Received: by with SMTP id l143so37828342lfe.2 for <>; Thu, 04 Feb 2016 06:58:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type; bh=bSwfiVYSEHgTJcF/LzxmXLv7+6PoZ7mCOsO+sioo55Q=; b=u6IofZPEAIAv0fEFTqwaJDO/JOcin+xBZa8mjKmUllhxx5HRsdXrnSXfwEOeXlQ1L8 B+3oroXtTYJOq6nMIaTlVD5xh+OG6C4xqOf8x8hs/RyuulCfSFMn4NYipVmsxecmM8hg ZcYjTa+NE3EvUlh6doeKb2h4I+yzpOI9T4rkZPmxcBCWIT5QYl2vsRCWUMNw3aAgxNLI 1qALGKhF1fBmludcI3f1f6teZ6iBehQ4Z97deGn7vOPQCxvmDsAstgv6U5QdnxDctx8v boqbkIU+CEXDvOo3AvVwftsoOOL4pnMSoZ1AtZ0c7CSK6HTVaUz/IHAaNBRwyhe0a0q7 rnYQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type; bh=bSwfiVYSEHgTJcF/LzxmXLv7+6PoZ7mCOsO+sioo55Q=; b=NbjYcwBRb+XbfvKhRjTU0roh1vojs/E9eU6n//NJbPlI8LQcbALB5O8teK75clP0be JnwMibztcvnJztNiAaBogc4PKsgHKQ9QfXj575FfpmzlhHNoEGkW06o4BL/T9YxG0vPb jlBX0G38J37gYm+Y9dcjgTLQ5kfDTjkd/ccTufCn4EtMS00a35mnqSu6EEVdqe8fs3jQ CDF1BP7D85EoNpVNWnz88HWMtejOciQDv9QJf8cIoumSqPtWfPnHqEhqBRNk0Kn/fSV7 2ng/hvnsrxJll+H6RWdaY4QMJxHYJxu6y8NaWiBnuSe+krONIkdMnCMy2WrtNiGdv5Et KJWA==
X-Gm-Message-State: AG10YORYIcwnwb91ynJc0MVZQucNvZxNrJu3CoTzxoVXk/Jrb7ZqmvLUOaycCeNP1mLzueY+
X-Received: by with SMTP id g16mr3101681lfg.82.1454597895517; Thu, 04 Feb 2016 06:58:15 -0800 (PST)
Received: from Hyperion.suse ( []) by with ESMTPSA id rp10sm1580917lbb.13.2016. (version=TLSv1/SSLv3 cipher=OTHER); Thu, 04 Feb 2016 06:58:15 -0800 (PST)
To: Michael Richardson <>
References: <> <>
From: Ludwig Seitz <>
Message-ID: <>
Date: Thu, 04 Feb 2016 15:58:11 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms080207050001000001060200"
Archived-At: <>
Subject: Re: [OAUTH-WG] [Ace] Questions about OAuth and DTLS
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 04 Feb 2016 14:58:19 -0000

Thank you Michael! Comments inline.


On 02/04/2016 03:31 PM, Michael Richardson wrote:
> Ludwig Seitz <> 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.

> 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.

Ludwig Seitz, PhD
Ideon Science Park
Building Beta 2
Scheelevägen 17
SE-223 70 Lund

Phone +46(0)70 349 9251