Ludwig Seitz <lud...@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.
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 <mcr+i...@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
