Hi Valery, I have some comments on
https://tools.ietf.org/html/draft-smyslov-ipsecme-ikev2-aux-00
AUX_EXCHANGE_SUPPORTED:
This specification doesn't define any data this
notification may contain, so the Notification Data is left empty.
However, other specifications may override this.
On 2018-07-05, 3:10 PM, "Scott Fluhrer (sfluhrer)"
mailto:sfluh...@cisco.com>> wrote:
From: Valery Smyslov
Sent: Thursday, July 05, 2018 8:44 AM
To: Scott Fluhrer (sfluhrer) ; 'Daniel Van Geest'
; ipsec@ietf.org
Subject: RE: IKE_AUX comments
Hi Scott,
So,
Hi Valery, opinions inline
On 2018-07-19, 10:14 AM, "Valery Smyslov"
mailto:smyslov.i...@gmail.com>> wrote:
Hi,
as it often happens, good thoughts come a bit late...
While I agreed before on using all-zero key for PRF and even
put this into my yesterday's presentation, while keeping thinking
ab
On 2018-07-25, 5:27 PM, "Scott Fluhrer (sfluhrer)"
mailto:sfluh...@cisco.com>> wrote:
I do have one issue I’ve been pondering, though; we do an IKE_AUX exchange, and
then follow it up with an IKE_AUTH exchange. At least with my accent, those
are phonetically quite close. It would be nice i
Hi John, Scott,
RFC 4739 (experimental) defines multiple authentication in IKEv2:
https://datatracker.ietf.org/doc/html/rfc4739. It allows for mixed
authentication types (e.g. EAP/certificates) and also multiple certificates.
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-auth
all chunk size to avoid IKEv2
fragmentation means many message exchanges when using large key sizes, but
picking large chunk sizes increases the changes of dropping IKEv2 fragments and
having to retransmit entire messages.
—
Daniel Van Geest (daniel.vange...@isara.com<mailto:daniel.
And if the WG decides it wants to use Type-2 as specified in
draft-hu-ipsecme-pqt-hybrid-auth, we should also advise LAMPS that we intend to
abuse their composite signatures construction by reusing private keys within a
composite signature and stand-alone. Perhaps the non-separability concerns
I don't think Type-1 precludes Type-2 or vice-versa and there are use cases for
either.
In both cases, assuming that hybridization is not permanent and not a flag-day,
during the transition period two certificate chains will need to be managed,
always a traditional one and either a composite on
Your draft lists RFC 4739 (Multiple Authentication Exchanges in the Internet
Key Exchange (IKEv2) Protocol) as a normative reference but doesn't mention it
anywhere in the body. In your presentation I'd like to hear
advantages/disadvantages of your draft vs RFC 4739.
Thanks,
Daniel
> -Ori
I support this work, but there is already a draft specifying both ML-DSA and
SLH-DSA in IKEv2:
https://datatracker.ietf.org/doc/draft-reddy-ipsecme-ikev2-pqc-auth/
Scott, as you're an author on both you'll have no problem reconciling the two
drafts :)
Regards,
Daniel
On 2025-01-31 7:40 p.m.,
On 2025-07-21 10:12 a.m., Jun Hu (Nokia) wrote:
just got time to read through this thread, this downgrade attack requires both
peers to allow IKEv2 with only weak DH, it won’t work if either peer only
allows strong DH or a hybrid DH include strong DH.
Such attack is valid on theory, but I wonder
Inline as well
On 2025-07-21 12:27 p.m., Jun Hu (Nokia) wrote:
Pls see my comments in line
From: Daniel Van Geest
<mailto:daniel.vangeest=40cryptonext-security@dmarc.ietf.org>
On 2025-07-21 10:12 a.m., Jun Hu (Nokia) wrote:
just got time to read through this thread, this downgrade
I don't think it's plausible to provide support for parallel signature chains
and then expect people to not use a chain individually. An advantage of
parallel chains is that you can maintain a traditional algorithm chain for
backwards compatibility with peers who haven't yet been upgraded to PQ.
13 matches
Mail list logo
