On Thu, Dec 20, 2018 at 09:11:24AM +, Hannes Tschofenig wrote:
>
> -Original Message-
> From: Ludwig Seitz
> Sent: Donnerstag, 20. Dezember 2018 08:40
> To: Jim Schaad ; Hannes Tschofenig
> ; 'Stefanie Gerdes' ; ace@ietf.org
> Subject: Re: [Ace] Security of the
; Jim Schaad ; ace@ietf.org
Subject: Re: [Ace] Security of the Communication Between C and RS
On 19/12/2018 14:04, Hannes Tschofenig wrote:
> Thanks, Ludwig. The list of steps below help me to understand the concern.
>
>
>
>
> 1.) C obtains token and pop-key from AS
>
Hi Ludwig, Hi Jim
A few remarks below:
-Original Message-
From: Ludwig Seitz
Sent: Donnerstag, 20. Dezember 2018 08:40
To: Jim Schaad ; Hannes Tschofenig
; 'Stefanie Gerdes' ; ace@ietf.org
Subject: Re: [Ace] Security of the Communication Between C and RS
On 19/12/2018 21:22, Jim
On 19/12/2018 21:22, Jim Schaad wrote:
In step (4) you tie the expiry of the token to the attacker
getting hold of the key. What happens if the attacker gets hold
of the pop key before the token expires?
If it is detected the AS would revoke the token. Then the client
_could_ use client
> -Original Message-
> From: Ludwig Seitz
> Sent: Wednesday, December 19, 2018 5:24 AM
> To: Hannes Tschofenig ; Stefanie Gerdes
> ; Jim Schaad ; ace@ietf.org
> Subject: Re: [Ace] Security of the Communication Between C and RS
>
> On 19/12/2018 14:04,
On 19/12/2018 14:04, Hannes Tschofenig wrote:
Thanks, Ludwig. The list of steps below help me to understand the concern.
1.) C obtains token and pop-key from AS
2.) C transmits token to RS and sets up secure communication (e.g.
DTLS-PSK) using the pop-key
3.) C sends secure requests to
Thanks, Ludwig. The list of steps below help me to understand the concern.
1.) C obtains token and pop-key from AS
2.) C transmits token to RS and sets up secure communication (e.g.
DTLS-PSK) using the pop-key
3.) C sends secure requests to the RS
4.) token expires, an attacker manages to
On 19/12/2018 12:46, Stefanie Gerdes wrote:
Hi Hannes,
On 12/19/2018 12:36 PM, Hannes Tschofenig wrote:
Hi Steffi,
Are you focused on token expiry or the case where a token + symmetric key has
been leaked?
I am talking about the expiry of the keying material for RS that AS
provides to C.
Hi Hannes,
On 12/19/2018 12:36 PM, Hannes Tschofenig wrote:
> Hi Steffi,
>
> Are you focused on token expiry or the case where a token + symmetric key has
> been leaked?
I am talking about the expiry of the keying material for RS that AS
provides to C.
>
> Is the threat you are describing
and presents a token?
Ciao
Hannes
-Original Message-
From: Stefanie Gerdes
Sent: Mittwoch, 19. Dezember 2018 12:26
To: Hannes Tschofenig ; Ludwig Seitz
; Jim Schaad ; ace@ietf.org
Subject: Re: [Ace] Security of the Communication Between C and RS
Hi Hannes,
On 12/18/2018 04:26 PM, Hannes
Hi Hannes,
On 12/18/2018 04:26 PM, Hannes Tschofenig wrote:
> Hi Steffi,
>
>> In OAuth, the expires_in field is usually used to inform the client how long
>> the access token is valid. If the client uses the access token in a request
>> after the token expired, the RS will reject the request,
Hi Steffi,
>> I also think that the client must be able to assume that RS' RPK that C
>> receives from AS is also valid as long as the token, unless C has additional
>> information.
>
> I would think that it is rather unlikely that the RS will change its
> public/private key pair so quickly.
Hi Steffi,
> In OAuth, the expires_in field is usually used to inform the client how long
> the access token is valid. If the client uses the access token in a request
> after the token expired, the RS will reject the request, which usually is not
> a big problem for the client.
> In ACE, AS
Hi Hannes,
On 12/15/2018 04:04 PM, Hannes Tschofenig wrote:
> Hi Steffi,
>
> ~snip~
>
>
>> I also think that the client must be able to assume that RS' RPK that C
>> receives from AS is also valid as long as the token, unless C has additional
>> information.
>
> I would think that it is
Hi Hannes,
On 12/18/2018 02:51 PM, Hannes Tschofenig wrote:
> ~snip~
>
>
> Now that I got a response from the OAuth working group (in the sense that I
> was thinking about the claims in the access token rather than the parameters
> in the response from the AS) I think checking the expires_in
On 18/12/2018 14:51, Hannes Tschofenig wrote:
Hi Steffi, Hi Ludwig,
~snip~
The access information optionally can contain an expires_in
field. It would help to prevent security breaches under the
following conditions:
1. the keying material is valid as long as the ticket, 2. the
expires_in
Hi Steffi, Hi Ludwig,
~snip~
>> The access information optionally can contain an expires_in field.
>> It would help to prevent security breaches under the following
>> conditions:
> 1. the keying material is valid as long as the ticket, 2. the
> expires_in field is present in the access
Hi Ludwig,
A few remarks inline:
-Original Message-
From: Ludwig Seitz
Sent: Dienstag, 18. Dezember 2018 09:27
To: Hannes Tschofenig ; Stefanie Gerdes
; Jim Schaad ; ace@ietf.org
Subject: Re: [Ace] Security of the Communication Between C and RS
On 15/12/2018 16:04, Hannes Tschofenig
On 15/12/2018 16:04, Hannes Tschofenig wrote:
Hi Steffi,
~snip~
I really think you should point out that symmetric keying material
that the AS provides to the client is valid as long as the token.
I think that's a useful recommendation. I do, however, believe that
we are not making the same
Hi Steffi,
~snip~
> I really think you should point out that symmetric keying material that the
> AS provides to the client is valid as long as the token.
I think that's a useful recommendation. I do, however, believe that we are not
making the same assumption for an asymmetric key bound to
Hi Ludwig,
>>
>> I am currently only referring to the keying material that AS provides to
>> C, i.e., the symmetric key shared between C and RS or, if asymmetric
>> keys are used, RS's RPK. Since it is clear to you that symmetric keys
>> are only valid as long as the token, you should point that
21 matches
Mail list logo
