Many thanks for all of the comments. I feel that AUTH_HMAC_SHA1_96 should be
formally deprecated not necessarily for its security* relative to the
deprecated AUTH_HMAC_SHA1_160, but for purposes of consistency, clarity and in
support of a broad migration away from SHA-1 dependencies.
I’m a rela
Daniel Shiu writes:
> Many thanks for all of the comments. I feel that AUTH_HMAC_SHA1_96
> should be formally deprecated not necessarily for its security*
> relative to the deprecated AUTH_HMAC_SHA1_160, but for purposes of
> consistency, clarity and in support of a broad migration away from
> SHA-
On Mon, 12 Aug 2024, Tero Kivinen wrote:
Because AUTH_HMAC_SHA1_96 used to be mandatory it was moved t MUST-,
not to SHOULD NOT or MUST NOT while AUTH_HMAC_SHA2_256_128 was made
MUST.
In the next update of the Algorithm Implementation Requirements and
Usage Guidance for IKEv2 (RFC8247) and E
Paul Wouters writes:
> I don't believe in this, but if I did, wouldn't you extend the Transorm Type 5
> to:
>
> - SN
> - ESN
> - SN without replay protection
> - ESN without replay protection
>
> Hence my comment about bytes and flags being a bit confusing. I
> don't think we can repurpose this r
Hi Tero,
> Valery Smyslov writes:
> > The draft uses the method similar to RFC 8784:
> >
> > SK_d = prf+ (PPK, SK_d')
> >
> > with the replacement of SK_d with SKEYSEED.
> >
> > The rationale for using the current form:
> > 1. This is the most straightforward and conservative use of prf, when
