Subject: [Ace] Replay ... RE: WGLC feedback on draft-ietf-ace-cwt-proof-of-possession-02

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 22 Jun 2018 13:36:15 +0000

Hi Roman,

Thanks for your review.

As I was re-reading the reviews I spotted this comment:

>  (14) (Editorial)  Page 8, Section 4, Per "Replay can also be avoided if a sub-key is derived from a shared secret that is specific to the instance of the PoP demonstration."  PoP is spelled out everywhere else in this draft but here.  Yes, the acronym is defined, but for readability, I recommend against it using it and consistently spelling it out here too.

I believe the current text is a bit confusing. Here is what it says:

Proof of possession via encrypted symmetric secrets is subject to replay attacks.
This attack can, for example, be avoided when a signed nonce or challenge is used
since the recipient can use a distinct nonce or challenge for each interaction.
Replay can also be avoided if a sub-key is derived from a shared secret
that is specific to the instance of the proof-of-possession demonstration.

This somehow gives the impression that replay attacks are only a concern for symmetric key techniques.
Of course, this is not true. Furthermore, the text gives the impression that this attack is actually
something that can be covered within the CWT-PoP token spec itself. This is also not the case.

For this reason I am suggesting to change the paragraph to:
"
CBOR Web Tokens with proof-of-possession keys are used in context of an architecture,
such as ACE-OAuth [REF], where protocols are used by a presenter to request these tokens and
to subsequently use them with recipients. To avoid replay attacks when the proof-of-possession tokens
are sent to presenters a security protocol, which uses nonces or timestamps, has to be utilized.
Note that a discussion of the architecture or specific protocols CWT proof-of-possession tokens
are used with are outside the scope of this specification. "

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Mike Jones <[email-masked]>
Date: Fri, 22 Jun 2018 21:06:30 +0000

I agree with this proposed update and will apply it to the editor's draft.

-----Original Message-----
From: Ace <[email-masked]> On Behalf Of Hannes Tschofenig
Sent: Friday, June 22, 2018 6:36 AM
To: Roman Danyliw <[email-masked]>; [email-masked]
Subject: [Ace] Replay ... RE: WGLC feedback on draft-ietf-ace-cwt-proof-of-possession-02

Hi Roman,

Thanks for your review.

Proof of possession via encrypted symmetric secrets is subject to replay attacks.
This attack can, for example, be avoided when a signed nonce or challenge is used since the recipient can use a distinct nonce or challenge for each interaction.
Replay can also be avoided if a sub-key is derived from a shared secret that is specific to the instance of the proof-of-possession demonstration.

This somehow gives the impression that replay attacks are only a concern for symmetric key techniques.
Of course, this is not true. Furthermore, the text gives the impression that this attack is actually something that can be covered within the CWT-PoP token spec itself. This is also not the case.

For this reason I am suggesting to change the paragraph to:
"
CBOR Web Tokens with proof-of-possession keys are used in context of an architecture, such as ACE-OAuth [REF], where protocols are used by a presenter to request these tokens and to subsequently use them with recipients. To avoid replay attacks when the proof-of-possession tokens are sent to presenters a security protocol, which uses nonces or timestamps, has to be utilized.
Note that a discussion of the architecture or specific protocols CWT proof-of-possession tokens are used with are outside the scope of this specification. "

Ciao
Hannes

_______________________________________________
Ace mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ace

---

From: Roman Danyliw <[email-masked]>
Date: Tue, 26 Jun 2018 01:56:55 +0000

Hi Hannes!

> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Friday, June 22, 2018 9:36 AM
> Subject: Replay ... RE: WGLC feedback on draft-ietf-ace-cwt-proof-of-
> possession-02
> 
> Hi Roman,
> 
> Thanks for your review.
> 
> >  (14) (Editorial)  Page 8, Section 4, Per "Replay can also be avoided if a sub-
> key is derived from a shared secret that is specific to the instance of the PoP
> demonstration."  PoP is spelled out everywhere else in this draft but here.
> Yes, the acronym is defined, but for readability, I recommend against it using
> it and consistently spelling it out here too.
> 
> This attack can, for example, be avoided when a signed nonce or challenge is
> used since the recipient can use a distinct nonce or challenge for each
> interaction.
> Replay can also be avoided if a sub-key is derived from a shared secret that is
> specific to the instance of the proof-of-possession demonstration.
> 
> Of course, this is not true. Furthermore, the text gives the impression that
> this attack is actually something that can be covered within the CWT-PoP
> token spec itself. This is also not the case.
> 
> CBOR Web Tokens with proof-of-possession keys are used in context of an
> architecture, such as ACE-OAuth [REF], where protocols are used by a
> presenter to request these tokens and to subsequently use them with
> recipients. To avoid replay attacks when the proof-of-possession tokens are
> sent to presenters a security protocol, which uses nonces or timestamps, has
> to be utilized.
> Note that a discussion of the architecture or specific protocols CWT proof-of-
> possession tokens are used with are outside the scope of this specification. "

This new paragraph is easier to understand.  It addresses my feedback. 

Thanks,
Roman

> Ciao
> Hannes
> 
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.