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

[Michael Richardson <[e-mail]>]

Ludwig Seitz <[e-mail]> 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.

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

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

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 <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-