Opened 8 years ago

Closed 7 years ago

#6 closed defect (fixed)

Issues in section 6

Reported by: ynir@… Owned by: draft-ietf-httpauth-mutual@…
Priority: major Milestone:
Component: mutual Version:
Severity: Submitted WG Document Keywords:
Cc:

Description

Reported by Yaron:

The discussion of nonces sounds like it it always the client that generates a nonce, and the server verifies it. But shouldn't we support the other direction, too?

Section 6, last paragraph: it is unclear how the protocol is supposed to work if everybody is using the value 232-1 for all messages, which is how I understand the last sentence. Why not simply re-establish the session when the value overflows?

Change History (3)

comment:1 Changed 8 years ago by y.oiwa@…

I think it's OK. The server side already has another thing corresponding to it.

In comparison with Digest auth:

  • Digest server nonces <--> Session IDs and crypto-generated keys
  • Digest client nonces <--> nonces in Mutual

For the last sentence, we rewrote it in -01 draft, hoping it becomes clearer.
Intented behavior is not to replace nonce for every message with 232 - 1, but replace the "maximum limit for nonce" with 232 - 1, leading to the re-establishment of session after overflow.

comment:2 Changed 7 years ago by mlepinski.ietf@…

Closing this issue. There appear to be no working group objections to the authors' explanation that no change is needed. (That is, other than a minor wording change in the last paragraph of Section 6 which has been completed)

comment:3 Changed 7 years ago by mlepinski.ietf@…

  • Resolution set to fixed
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.