Subject: [OAUTH-WG] Questions about OAuth and DTLS

From: Ludwig Seitz <[email-masked]>
Date: Thu, 4 Feb 2016 10:54:51 +0100

Hello list(s),

in the process of updating our draft [1] (mainly in reaction to the 
reviewer's comments) I've come up with a question I'd like to put to the 
list (crossposting to OAuth as well, they might have considered that 
already):

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?

It would simplify the DTLS cases a lot, if I could just require the 
token and the DTLS session to use the same type of key. For starters we 
could use DTLS handshake to perform the proof-of-possession.

Would there be any security issues with using the PoP key in the DTLS 
handshake?

I'm thinking of using pre-shared symmetric PoP keys as PSK as in RFC4279 
and raw public PoP keys as client-authentication key as in
RFC7250.

Regards,

Ludwig

[1] https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz/
[2] https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-02

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

Phone +46(0)70 349 9251
http://www.sics.se

---

From: Michael Richardson <[email-masked]>
Date: Thu, 04 Feb 2016 09:31:43 -0500

Ludwig Seitz <[email-masked]> wrote:
    > 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

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

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

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?

    > It would simplify the DTLS cases a lot, if I could just require the token and
    > the DTLS session to use the same type of key. For starters we could use DTLS
    > handshake to perform the proof-of-possession.

I agree, that it would be better.
(I'm also concerned that we not fail into where IKEv1 did: with weak PSK
being the only interoperable mechanism...)

    > I'm thinking of using pre-shared symmetric PoP keys as PSK as in RFC4279 and
    > raw public PoP keys as client-authentication key as in
    > RFC7250.

Just because I had to look it up...
4279 - Pre-Shared Key Ciphersuites for Transport Layer Security
7250 - Using Raw Public Keys in Transport Layer Security

I thought perhaps it was some more specific mechanism...

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Ludwig Seitz <[email-masked]>
Date: Thu, 4 Feb 2016 15:58:11 +0100

Thank you Michael! Comments inline.

/Ludwig

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

> 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
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelevägen 17
SE-223 70 Lund

Phone +46(0)70 349 9251
http://www.sics.se

---

From: John Bradley <[email-masked]>
Date: Thu, 4 Feb 2016 13:14:28 -0300

In https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution

The proof key is included in the access token or provided out of band. 

The proof mechanism to the RS is what would determine if the key type needs to match DTLS .  
If the proof is DTLS then they would need to match.  

POP will have different presentment mechanisms such as signing the payload or binding to mutual TLS client auth.

For a symmetric key you would encrypt it in the Access token with a Key known to the RS so only the token decryption key needs to be managed out of band.

John B.

> On Feb 4, 2016, at 11:58 AM, Ludwig Seitz <[email-masked]> wrote:
> 
> Actually even the raw public key needs to be provisioned out-of-band to those supposed to trust it for authentication.
> 
>> 
> 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
> SICS Swedish ICT AB
> Ideon Science Park
> Building Beta 2
> Scheelevägen 17
> SE-223 70 Lund
> 
> Phone +46(0)70 349 9251
> http://www.sics.se
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Ludwig Seitz <[email-masked]>
Date: Fri, 5 Feb 2016 09:30:31 +0100

> If the proof is DTLS then they would need to match.

Thank you John, this leads me to another question (maybe I just missed 
it in the PoP drafts): Who decides what the proof mechanism should be? 
How is the proof mechanism signaled to the client (the client may 
support several proof mechanisms)?

/Ludwig

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

Phone +46(0)70 349 9251
http://www.sics.se

---

From: Ludwig Seitz <[email-masked]>
Date: Mon, 8 Feb 2016 08:49:52 +0100

On 02/07/2016 06:24 PM, Samuel Erdtman wrote:
> Hi,
~snip~
> But I think there is some compelling properties of having a symmetric
> PoP key and a Raw Public Key (D)TLS. In this case the Public key of the
> RS can be distributed to the client in the client information (the
> attributes accompanying the token) from AS and the PoP key as defined by
> PoP key distribution draft. With this setup the client can authenticate
> the server at connection time and then it can send its PoP token to
> authorization information endpoint/resource at the RS (defined in
> draft-ietf-ace-oauth-authz as an alternative to the HTTP Authorization
> header) to authorize the client.
>

In this case you need to perform an additional proof-of-possession step. 
Worse, we have to define a new protocol for this.

@OAuth: It is not really clear to me from reading the PoP drafts, what 
the acceptable proof-of-possession methods are. Is this some work that 
the WG is planning to do?

/Ludwig

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

Phone +46(0)70 349 9251
http://www.sics.se

---

From: Ludwig Seitz <[email-masked]>
Date: Mon, 8 Feb 2016 09:02:15 +0100

Michael,

thank you for answering, this is getting very interesting.
Comments inline.

/Ludwig

On 02/05/2016 04:26 PM, Michael Richardson wrote:

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

Actually I don't want to authenticate the client, I just want do a 
proof-of-possession for the (symmetric) key that is bound to the token. 
Wouldn't the DTLS-PSK handshake provide that proof?

Detailed scenario (skip if the above makes sense):
Client has a PoP token with a symmetric PoP key. Client wants to use 
DTLS-PSK towards the RS with the symmetric PoP key as PSK to get a.) A 
secure connection and b.) do the proof-of-possession towards the RS.

>      >> 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?
>
>      > (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.
>
Yes if the PoP token uses a public key as PoP key. C could even generate 
an ephemeral key-pair just for this token (and the DTLS-RPK handshake).

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

Phone +46(0)70 349 9251
http://www.sics.se

---

From: John Bradley <[email-masked]>
Date: Mon, 8 Feb 2016 12:04:05 -0300

The RS is going to have to advertise what presentment mechanisms it supports.

We don’t have that yet.   I suspect that it might be part of OAuth Discovery.  Currently that mostly cover AS discovery, but for the RS I could see doing a head on the resource and getting back a link to a JSON document that would contain meta-data about the RS.

The standard OAuth answer to this question is the client would get it from the service documentation, but that is not really scalable.

> On Feb 5, 2016, at 5:30 AM, Ludwig Seitz <[email-masked]> wrote:
> 
> Thank you John, this leads me to another question (maybe I just missed it in the PoP drafts): Who decides what the proof mechanism should be? How is the proof mechanism signaled to the client (the client may support several proof mechanisms)?
> 
> /Ludwig
> 
> 
> -- 
> Ludwig Seitz, PhD
> SICS Swedish ICT AB
> Ideon Science Park
> Building Beta 2
> Scheelevägen 17
> SE-223 70 Lund
> 
> Phone +46(0)70 349 9251
> http://www.sics.se
>

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Mon, 8 Feb 2016 09:52:21 -0800

There is a more general problem in PaaS deployment about how RA and AS infrastructure discover and coordinate with each other. For the most part this hasn't been necessary since usually the AS and RS are controlled by the same admins. But in PaaS/IaaS the requirements vary widely. 

How does an RS indicate to an AS what tokens it is able to support (directly or indirectly via a security module). And then subsequently for the as and rs to let the client know?

We need to broaden discovery to cover all the scenarios so that automated and secure config of AS/RS/Tkn/Reg/RS entities works. 

Phil

> On Feb 8, 2016, at 07:04, John Bradley <[email-masked]> wrote:
>

---

From: Michael Richardson <[email-masked]>
Date: Fri, 05 Feb 2016 10:26:07 -0500

Ludwig Seitz <[email-masked]> wrote:
    >> Ludwig Seitz <[email-masked]> 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.
    >>
    >> 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.
    >>
    >> through some out-of-band (perhaps human mediated?) process, while the
    >> raw public key did not need any other pre-arrangement.

---

From: Samuel Erdtman <[email-masked]>
Date: Sun, 7 Feb 2016 18:24:21 +0100

Hi,

I think it is a reasonable simplification to mandate that PoP key and
(D)TLS Mode matches i.e. if the PoP keys is symmetric the (D)TLS mode would
be PSK, if the PoP key is asymmetric (D)TLS mode would be Raw Public key.

But I think there is some compelling properties of having a symmetric PoP
key and a Raw Public Key (D)TLS. In this case the Public key of the RS can
be distributed to the client in the client information (the attributes
accompanying the token) from AS and the PoP key as defined by PoP key
distribution draft. With this setup the client can authenticate the server
at connection time and then it can send its PoP token to authorization
information endpoint/resource at the RS (defined in
draft-ietf-ace-oauth-authz as an alternative to the HTTP Authorization
header) to authorize the client.

Regards
//Samuel

On Thu, Feb 4, 2016 at 10:54 AM, Ludwig Seitz <[email-masked]> wrote:

> It would simplify the DTLS cases a lot, if I could just require the token
> and the DTLS session to use the same type of key. For starters we could use
> DTLS handshake to perform the proof-of-possession.
>
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace
>
>