Hi Göran, Thanks for doing the sweep through the document checking for "nonce" usage. The change you call out below (and the entire -17) looks good to me.
Thanks again, Ben On Mon, Mar 08, 2021 at 11:24:17AM +0000, Göran Selander wrote: > > Hi Ben, and all, > > I just submitted -17 based on Ben's comments in this mail thread, and also a > change of a security consideration. > > * "mutual authentication" removed from figure > * the changes proposed below are all included, and further changes to the > same effect > > When I went through the 61 occurrences of "nonce" I found a description of > an attack which I thought needed to clarified. Please review. > > OLD > If that is not guaranteed, nodes are susceptible to reuse of AEAD (nonce, > key) pairs, especially since an on-path attacker can cause the client to use > an arbitrary nonce for Security Context establishment by replaying > client-to-server messages. > > NEW > If that is not guaranteed, nodes are susceptible to reuse of AEAD (nonce, > key) pairs, especially since an on-path attacker can cause the use of a > previously exchanged client nonce N1 for Security Context establishment by > replaying the corresponding client-to-server message. > > > Göran > > > > On 2021-03-04, 22:09, "Benjamin Kaduk" <[email protected]> wrote: > > On Thu, Mar 04, 2021 at 04:17:52PM +0000, Göran Selander wrote: > > Hi Ben, > > > > Thanks for good comments. > > > > Starting with the second comment, I agree the text "mutual > authentication" in the figure should appear after the first exchange. It > seems to have been left and forgotten during the ASCII art session. It is > described in Section 4 so could be removed from the figure if it isn't > possible to find a place for it to print well. > > Sounds reasonable. > > > On 2021-03-04, 03:29, "Benjamin Kaduk" <[email protected]> wrote: > > > > Hi all, > > > > I was going through the four drafts that have been "waiting for > writeup" > > for a while, to check that the latest changes are good and they are > ready > > to go once the last point from the secdir review of > > draft-ietf-ace-dtls-authorize is wrapped up. In short: they are, > but I had > > a couple comments on the OSCORE profile that might help improve it. > > > > In section 2, we have some discussion: > > > > The use of nonces during the exchange prevents the reuse of an > > Authenticated Encryption with Associated Data (AEAD) nonces/key > pair > > for two different messages. Reuse might otherwise occur when > client > > and RS derive a new Security Context from an existing (non- > expired) > > access token, as might occur when either party has just > rebooted, and > > might lead to loss of both confidentiality and integrity. > Instead, > > by using nonces as part of the Master Salt, the request to the > authz- > > info endpoint posting the same token results in a different > Security > > Context, by OSCORE construction, since even though the Master > Secret, > > Sender ID and Recipient ID are the same, the Master Salt is > different > > (see Section 3.2.1 of [RFC8613]). If nonces were reused, a node > > reusing a non-expired old token would be susceptible to on-path > > attackers provoking the creation of OSCORE messages using old > AEAD > > keys and nonces. > > > > [GS] Here is a proposal to address your first comment. There are > already nonce qualifications in partial use so it didn't make sense to me to > insert extra adjectives on every occasion. See below. > > > > The use of nonces during the exchange prevents the reuse of an > > Authenticated Encryption with Associated Data (AEAD) nonces/key > pair > > for two different messages. > > > > [GS] In the sentence above the difference between the nonces should be > clear, right? > > Yes, though if we name N1 and N2 (so, "the use of nonces N1 and N2 during > the exchange") that would let us use N1 and N2 as disambiguators later in > the paragraph, if we need to. (We may not need to use the names N1 and > N2, > though.) > > > Reuse might otherwise occur when client > > and RS derive a new Security Context from an existing (non- > expired) > > access token, as might occur when either party has just > rebooted, and > > might lead to loss of both confidentiality and integrity. > Instead, > > by using nonces as part of the Master Salt, the request to the > authz- > > > > [GS] "Instead, by using the exchanged nonces as part of the Master > Salt, ..." > > +1 > > > info endpoint posting the same token results in a different > Security > > Context, by OSCORE construction, since even though the Master > Secret, > > Sender ID and Recipient ID are the same, the Master Salt is > different > > (see Section 3.2.1 of [RFC8613]). If nonces were reused, a node > > > > [GS] "If the exchanged nonces were reused, ... " > > +1 > > > reusing a non-expired old token would be susceptible to on-path > > attackers provoking the creation of OSCORE messages using old > AEAD > > keys and nonces. > > > > [GS] "... the creation of an OSCORE message using an old AEAD key and > nonce." > > +1 > > > [GS] In the rest of the document we would use nonce without > qualification as it is referring to the exchanged value. Is that clear enough > or do you want a consistent adjective throughout the draft? > > My expectation is that the rest of the document is clear enough as-is, and > that only this portion needs special treatment since it's specifically > talking about the risks of "nonce reuse" for a different type of nonce. > > Thanks for putting this together, > > Ben > _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
