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
Hello!
Per the IETF 103 face-to-face meeting and the call on the mailing list, there
is support to adopt this draft (draft-palombini-ace-key-groupcomm).
Authors: please submit this draft as a -00 WG document
(draft-ietf-ace-key-groupcomm-00).
Regards,
Roman and Jim
> -Original
Hello!
Per the IETF 103 face-to-face meeting and the call on the mailing list, there
is support to adopt this draft (draft-tiloca-ace-oscoap-joining).
Authors: please submit this draft as a -00 WG document
(draft-ietf-ace-oscoap-joining-00).
Regards,
Roman and Jim
> -Original
> -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, Hannes Tschofenig wrote:
> >
Hi esko,
apologies for being unclear.
The CBOR wrapping is removed. It is only present for response of server
key generation /skg
Peter
Esko Dijk schreef op 2018-12-19 13:32:
> Dear Panos & Peter,
>
> On Jim's first point for section 4.1 below (content encoding) - will the
> CBOR-wrapped
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
Dear Panos & Peter,
On Jim's first point for section 4.1 below (content encoding) - will the
CBOR-wrapped ASN.1 payload be changed to "pure" ASN.1 payload for the media
types that are non-multipart?
I agree with Jim that the CBOR wrapping in this case is not needed (since the
CoAP
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
Hi Steffi,
Are you focused on token expiry or the case where a token + symmetric key has
been leaked?
Is the threat you are describing the case where the client uses DTLS/TLS with
the RS (potentially long after a token has been presented), or the case where
the client contacts the RS and
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,
12 matches
Mail list logo
