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

[Ludwig Seitz]

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?

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

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



smime.p7s
Description: S/MIME Cryptographic Signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[John Bradley]

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  wrote:
> 
> On 02/04/2016 05:14 PM, John Bradley wrote:
>> 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.
>> 
> 
> 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
> 

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Phil Hunt (IDM)]

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  wrote:
> 
> 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  wrote:
>> 
>> On 02/04/2016 05:14 PM, John Bradley wrote:
>>> 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.
>> 
>> 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
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Michael Richardson]

Ludwig Seitz  wrote:
> 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.

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





signature.asc
Description: PGP signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Samuel Erdtman]

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  wrote:

> 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
>
>
> ___
> Ace mailing list
> a...@ietf.org
> https://www.ietf.org/mailman/listinfo/ace
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Ludwig Seitz]

On 02/04/2016 05:14 PM, John Bradley wrote:

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.



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



smime.p7s
Description: S/MIME Cryptographic Signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Ludwig Seitz]

Thank you Michael! Comments inline.

/Ludwig

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



smime.p7s
Description: S/MIME Cryptographic Signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Michael Richardson]

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.

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





signature.asc
Description: PGP signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[John Bradley]

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  wrote:
> 
> Thank you Michael! Comments inline.
> 
> /Ludwig
> 
> 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
> 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
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth