On Tue, 2016-11-15 at 18:10 +0900, Martin Thomson wrote: > On 15 November 2016 at 17:34, Fossati, Thomas (Nokia - GB) > <thomas.foss...@nokia.com> wrote: > > > > The draft proposes two ways to allocate the identifier (see 3rd > > para of > > https://thomas-fossati.github.io/draft-tls-cid/#rfc.section.1): > > 1. Server decides unilaterally a value that is fixed for the > > duration of > > the session (SecAssocType.fixed); > > 2. Server and Client agree on a sequence of values generated using > > HOTP > > [RFC 4226] seeded by the session shared secret (SecAssocType.hotp); > > Client > > shifts to the next value when needed (e.g. on transport handover). > > > > > > At first this might not look particularly elegant, but there are > > good > > reasons for having both methods. > > I'm not seeing quite enough information here to implement this. How > does a server know which of the many HOTP keys it has are in use? > Surely you can't use the same HOTP key with every client.
Not sure I understand the question, but I'd suggest to read the text on generating the hotp keys. regards, Nikos _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
