On Wed, 23 Jul 2025, at 08:51, Alan DeKok wrote:
> I'm not sure what it's used for. If it's just a random field, why
> have this text:
>
> The nonce in a request MUST have its least significant bit
> set to zero (0), and the nonce in a response MUST have the same
> value as the request nonce except the least significant bit MUST
> be set to one (1).
>
> ? If it's just a nonce, there should be no reason to set / clear that bit.
Maybe it was perceived as a simply way to remove any problem with looping back
a request as a response.
Not saying it is valid (or invalid).
I *think* I have seen this done elsewhere, in effect this is done by other
protocols when they encompass the message type ('request' or 'reply') in the
crypto-sausage making machine.
Digging around, this language was in the text back in 2011 both in:
draft-ietf-emu-eap-tunnel-method-00
draft-zhou-emu-eap-fastv2-00
So this looks to go further back to 2004 with the EAP-FAST draft[1] where you
need to 'increment' a 256 bit number.
Unable to find anything in the mailing list for around that period (is it
archived?) and not really sure what value it would add here especially as there
would be no harm revisiting if this is still appropriate.
> The Nonce field seems to be there "just in case". Adding a nonce isn't bad,
> but it's not clear if it's a solution to anything.
At the time it may have been just a way to rule out replay attacks altogether.
Cheers
Alex
[1]
https://datatracker.ietf.org/doc/html/draft-cam-winget-eap-fast-00#section-12.7
_______________________________________________
Emu mailing list -- [email protected]
To unsubscribe send an email to [email protected]
