[IPsec] Re: interaction between RFC9370 and RFC8784

[Valery Smyslov]

Hi Jun,

 

RFC8784 and RFC9370 are not interdependent, thus the can be used together.

Among the options you listed, only b) is feasible.

You cannot use PPK unless you know its identity, which is sent in the
IKE_AUTH request.

Thus, all IKE_INTERMEDIATE exchanges are performed as defined in 9370 and

IKE_AUTH is performed as defined in 8784. After last IKE_INTERMEDIATE is
completed

and keys are updated as per 9370, the initiator applies PPK and re-calculate
keys again as per 8784.

 

Note, that it is also possible to use draft-ietf-ipsecme-ikev2-qr-alt with
RFC 9370.

The draft explicitly says:

 

   If a series of the IKE_INTERMEDIATE exchanges takes place, the

   PPK_IDENTITY_KEY notification(s) MUST be sent in the last one, i.e.

   in the IKE_INTERMEDIATE exchange immediately preceding the IKE_AUTH

   exchange.  

 

and later:

 

   Note that if the IKE SA keys are also

   recalculated as the result of the other actions performed in the

   IKE_INTERMEDIATE exchange (for example, as defined in [RFC9370]),

   then applying PPK MUST be done after all of them, so that

   recalculating IKE SA keys with PPK is the last action before they are

   used in the IKE_AUTH exchange.

 

Hope this helps.

 

Regards,

Valery.

 

 

From: Jun Hu (Nokia)  
Sent: Wednesday, September 18, 2024 9:16 PM
To: ipsec@ietf.org
Subject: [IPsec] interaction between RFC9370 and RFC8784

 

Hi,

I don't know if this has been discussed before, but what would be the
interaction between 9370 and 8784 if they are both used? I know it seems
unnecessary to use both of them, but it could happen technically, I see
following options:

1.  Not allowing this: e.g. if a responder receives USE_PPK and ADDKEx
transform that is PQC alg in IKE_SA_INIT request, it choose to only use on
mechanism, e.g. if choose to use 9370, then responder doesn't include
USE_PPK in response 
2.  Support this, then the question is how would ppk be used?

a.  Used in every key exchange, to derive the SK_d, sk_pi, sk_pr as
specified in 8784
b.  Used only in last round key exchange 
c.  Used only in first round 

 

#1 seems simpler to implement, but is there any security benefit to do #2,
like ppk used as another level security enhancement? 

 

I know there are IPsec implementations(include mine) already implemented
8784, and now in process of implementing 9370 for PQC, I think it will be
beneficial to have some clarity on this interaction.

 

--

Hu Jun

 

___
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org

[IPsec] Re: I-D Action: draft-ietf-ipsecme-g-ikev2-14.txt

[Valery Smyslov]

Hi,

this version addresses last comments from Tero about the size of the rekey SA 
SPI.

Regards,
Valery.

> Internet-Draft draft-ietf-ipsecme-g-ikev2-14.txt is now available. It is a 
> work item of
> the IP Security Maintenance and Extensions (IPSECME) WG of the IETF.
> 
>Title:   Group Key Management using IKEv2
>    Authors: Valery Smyslov
> Brian Weis
>Name:draft-ietf-ipsecme-g-ikev2-14.txt
>Pages:   74
>Dates:   2024-09-04
> 
> Abstract:
> 
>This document presents an extension to the Internet Key Exchange
>version 2 (IKEv2) protocol for the purpose of a group key management.
>The protocol is in conformance with the Multicast Security (MSEC) key
>management architecture, which contains two components: member
>registration and group rekeying.  Both components are required for a
>GCKS (Group Controller/Key Server) to provide authorized Group
>Members (GMs) with IPsec group security associations.  The group
>members then exchange IP multicast or other group traffic as IPsec
>packets.
> 
>This document obsoletes RFC 6407.  This documents also updates RFC
>7296 by renaming a transform type 5 from "Extended Sequence Numbers
>(ESN)" to the "Replay Protection (RP)" and by renaming IKEv2
>authentication method 0 from "Reserved" to "NONE".
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-g-ikev2/
> 
> There is also an HTMLized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-g-ikev2-14
> 
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-ipsecme-g-ikev2-14
> 
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
> 
> 
> ___
> IPsec mailing list -- ipsec@ietf.org
> To unsubscribe send an email to ipsec-le...@ietf.org

___
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org

[IPsec] Re: G-IKEv2 review comments

[Valery Smyslov]

> > I think the GM will use the whole 16 bytes from the header for
> > multicast rekey SA (those, with the multicast destination IP).
> > Otherwise we will have 8 unused octets for SPIr in the IKEv2 header.
> 
> But as the "GCKS MUST make sure that the sole first 8 octets
(corresponding to
> "Initiator's SPI" field in the IKEv2 header) uniquely identify the Rekey
SA." there is
> no point of GM to check Responder SPI at all.
> 
> We could simply say that it is either random or all ones or something else
(yes we
> do want to include it in the header to keep header same as IKEv2).
> 
> So I think my main point is either use the 16-octet SPI pair to identify
the G-IKEv2
> SA or use 8-octet Initiator SPI and ignore the content of the Responder
SPI part in
> IKE header, and dont send it in notifies.
> 
> The current method seems to be mix of those two. The notify sends full
16-octets,
> but in IKE header only first 8-octets really matter, as they need to be
unique.
> 
> If we want to use 16-octet SPI then we should remove that text about first
8-octets
> uniquely identify the Rekey SA, just use full 16-octets all the time.
> 
> If we say first 8-octets uniquely identify the Rekey SA, then we could
leave out last
> 8-octets in notifies, and say they are sent all ones in IKE header (i.e.
0x
> )...

I see your point. I removed the requirement that the first 8 octets uniquely
identify SA.

I think that it is more appropriate from architecture point of view to have
both
SPIi and SPIr in the header meaningful, rather than use only one of them
and fill in the other with predefined or random value.

What about the text - I recall that it was added by me to simplify
co-existence
of IKE and GIKE_REKEY SAs in the same SADB on GCKS.
However, I now realize that this is an implementation optimization
and not the protocol requirement. In other words, the GCKS can always select
rekey SPI so, that its first half is unique (among all SPIs, both for IKE
and rekey SAs),
but the GMs will have to use whole 16 bytes to found the rekey SA.

I published a new -14 version.

Regards,
Valery.

> > > > Obviously, GCKS is unaware of the SAs each GM might have (it may
> > > > be a member of several groups controlled by different GCKSs and
> > > > besides it may have a lot of ordinary IKE SAs too), so the GCKS
> > > > selects SPI in random. To minimize the chance of collision it is
> > > > better to use full
> > > > 16 bytes of available room in IKEv2 header instead of only
> > > > selecting SPIi, since GMs won't contribute to this process anyway.
> > >
> > > Probability of having random collision with IKE SA when only using
> > > 64-bit IKE SPI is that I would ignore that. This is long lived SPI
> > > value, typically it will stay same for long time (hours, days, or
> > > even weeks).
> > >
> > > Also I think there is also the source IP address of the IKE packets
> > > that can be used to identify the GCKS so there should not be
> > > problems even if the SPIi somehow should collide.
> >
> > I wouldn't rely on source IP. It may change over time (NAT, DHCP
> > etc.).
> 
> This would only be needed if you happen to have collision for 8-octet SPI
with
> current draft already. I mean if two GCKS happen to pick same 8-octet
Initiator SPI
> then you are going to use IP address to separate them as the text says
they MUST
> be unique...
> 
> Either way, I do not have strong opinion about this, it just feels bit
wrong.
> --
> kivi...@iki.fi

___
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org

[IPsec] Re: G-IKEv2 review comments

[Valery Smyslov]

HI Tero,

> Valery Smyslov writes:
> > > I did understand that, but I do not see point of sending extra
> > > 8-octets as
> > the first 8-
> > > octets already identifies the IKE SA...
> >
> > The point is that we want to re-use IKEv2 header, which contains two
> > IKE SPIs.
> 
> Sure, but this does not have anything to do with the issue in hand, i.e.,
how to
> identify the IKE SA in the notify payload. The notify payload normally
only has 8
> octets to identify the IKE SA and now you suddenly want to have 16 octets
instead.

8 octets are used for IKE protocol SA, 16 octets would be used for
GIKE_REKEY protocol SA.
I see no misuse of the Notify payload here - SPI size is variable by
definition
and is determined by the protocol the SA relates to.

> > In normal IKEv2 each side selects its own IKE SPI, but in
> > G-IKEv2 it is impossible. It is the GCKS that provides GMs with SPI
> > for rekey SA and GMs will have to use it to select the right SA.
> 
> Yes, but as the GM will always only use the first 8 octets of the IKE SPIs
in the
> IKEv2 header we could simply use that to identify the IKE SA.

I think the GM will use the whole 16 bytes from the header for multicast
rekey SA
(those, with the multicast destination IP).
Otherwise we will have 8 unused octets for SPIr in the IKEv2 header.

> > Obviously, GCKS is unaware of the SAs each GM might have (it may be a
> > member of several groups controlled by different GCKSs and besides it
> > may have a lot of ordinary IKE SAs too), so the GCKS selects SPI in
> > random. To minimize the chance of collision it is better to use full
> > 16 bytes of available room in IKEv2 header instead of only selecting
> > SPIi, since GMs won't contribute to this process anyway.
> 
> Probability of having random collision with IKE SA when only using 64-bit
IKE SPI is
> that I would ignore that. This is long lived SPI value, typically it will
stay same for
> long time (hours, days, or even weeks).
> 
> Also I think there is also the source IP address of the IKE packets that
can be used
> to identify the GCKS so there should not be problems even if the SPIi
somehow
> should collide.

I wouldn't rely on source IP. It may change over time (NAT, DHCP etc.).

> If I remember correctly the IKE SA packets the GCKS is sending will be
using the
> unicast source IP address of the GCKS, and may contain either unicast
address of
> the GM or the multicast address. The source address would not be multicast
or
> broadcast address.

Correct.

Regards,
Valery.

> kivi...@iki.fi

___
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org

[IPsec] Re: I-D Action: draft-ietf-ipsecme-ikev2-qr-alt-04.txt

[Valery Smyslov]

Hi,

it was pointed out to me in a private conversation that the way the PPK 
Confirmation field is computed in IKE_INTERMEDIATE
is not appropriate for CREATE_CHILD_SA, since Nir is not yet known. The -04 
version addresses this issue
by omitting Nr from the calculation for this situation. It also clarifies the 
responder's behavior when
using PPKs in CREATE_CHILD_SA is mandatory for the responder, but the initiator 
doesn't propose any PPK
or proposes inappropriate ones (the responder sends back NO_PROPOSAL_CHOSEN).

Regards,
Valery.

> Internet-Draft draft-ietf-ipsecme-ikev2-qr-alt-04.txt is now available. It is 
> a work
> item of the IP Security Maintenance and Extensions (IPSECME) WG of the IETF.
> 
>Title:   Mixing Preshared Keys in the IKE_INTERMEDIATE and in the
> CREATE_CHILD_SA Exchanges of IKEv2 for Post-quantum Security
>Author:  Valery Smyslov
>Name:draft-ietf-ipsecme-ikev2-qr-alt-04.txt
>Pages:   12
>Dates:   2024-09-02
> 
> Abstract:
> 
>An Internet Key Exchange protocol version 2 (IKEv2) extension defined
>in RFC8784 allows IPsec traffic to be protected against someone
>storing VPN communications today and decrypting it later, when (and
>if) cryptographically relevant quantum computers are available.  The
>protection is achieved by means of Post-quantum Preshared Key (PPK)
>which is mixed into the session keys calculation.  However, this
>protection doesn't cover an initial IKEv2 SA, which might be
>unacceptable in some scenarios.  This specification defines an
>alternative way to get protection against quantum computers, which is
>similar to the solution defined in RFC8784, but protects the initial
>IKEv2 SA too.
> 
>Besides, RFC8784 assumes that PPKs are static and thus they are only
>used when an initial IKEv2 Security Association (SA) is created.  If
>a fresh PPK is available before the IKE SA is expired, then the only
>way to use it is to delete the current IKE SA and create a new one
>from scratch, which is inefficient.  This specification also defines
>a way to use PPKs in active IKEv2 SA for creating additional IPsec
>SAs and for rekeys operations.
> 
>This draft updates RFC8784 by extending use of PPKs.
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-qr-alt/
> 
> There is also an HTMLized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-ikev2-qr-alt-04
> 
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-ipsecme-ikev2-qr-alt-04
> 
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
> 
> 
> ___
> IPsec mailing list -- ipsec@ietf.org
> To unsubscribe send an email to ipsec-le...@ietf.org

___
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org

[IPsec] Re: I-D Action: draft-ietf-ipsecme-g-ikev2-13.txt

[Valery Smyslov]

Hi,

more comments from Tero are addressed.

Regards,
Valery.

> Internet-Draft draft-ietf-ipsecme-g-ikev2-13.txt is now available. It is a 
> work item of
> the IP Security Maintenance and Extensions (IPSECME) WG of the IETF.
> 
>Title:   Group Key Management using IKEv2
>    Authors: Valery Smyslov
> Brian Weis
>Name:draft-ietf-ipsecme-g-ikev2-13.txt
>Pages:   74
>Dates:   2024-08-21
> 
> Abstract:
> 
>This document presents an extension to the Internet Key Exchange
>version 2 (IKEv2) protocol for the purpose of a group key management.
>The protocol is in conformance with the Multicast Security (MSEC) key
>management architecture, which contains two components: member
>registration and group rekeying.  Both components are required for a
>GCKS (Group Controller/Key Server) to provide authorized Group
>Members (GMs) with IPsec group security associations.  The group
>members then exchange IP multicast or other group traffic as IPsec
>packets.
> 
>This document obsoletes RFC 6407.  This documents also updates RFC
>7296 by renaming a transform type 5 from "Extended Sequence Numbers
>(ESN)" to the "Replay Protection (RP)" and by renaming IKEv2
>authentication method 0 from "Reserved" to "NONE".
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-g-ikev2/
> 
> There is also an HTMLized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-g-ikev2-13
> 
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-ipsecme-g-ikev2-13
> 
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
> 
> 
> ___
> IPsec mailing list -- ipsec@ietf.org
> To unsubscribe send an email to ipsec-le...@ietf.org

___
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org

[IPsec] Re: G-IKEv2 review comments

[Valery Smyslov]

Hi Tero,

> > I see your point. I would leave GSA as is, and perhaps would change
> > GAP to Group Related policy (GR policy). "Policy" will not be part of
> > abbreviation in both cases. Your opinion? I didn't make any changes
> > yet...
> 
> Ok for me.

Or, even better, we can call it Group-Wise (GW) policy (I hope you are OK
with this too).
I made these changes, please review.

> > > 4.4.2.  Group Security Association Policy Substructure
> > >
> > > The SPI size for the IKE is 16, not 8, like in standard RFC7296 IKEv2.
> > > As the 8-first octets of the IKE SPI is the initiator SPI and it is
> > > only
> > one part that is
> > > used to identify the Rekey SA, so I think it could be possible to
> > > just
> > send 8-octets,
> > > i.e., the initiator SPI, and simply say that the Responder SPI of
> > > the
> > Rekey SA is
> > > simply ignored, i.e., receipient MUST use the Inititor SA to find
> > > the
> > rekey SA, and
> > > ignore the Responder SPI on recipient (and either that Initiator
> > > MUST or
> > SHOULD
> > > use the responder SPI static for all Rekey SA messages).
> > >
> > > Or we could define we send SPIi, and the SPIr will always be same as
> > > SPIi,
> > so
> > > each rekey SA will have identical SPIi and SPIr.
> > >
> > > Similar changes for the section 4.5.2.
> >
> > Note, that a new IKE protocol GIKE_REKEY is used here, for which the
> > size of SPI is 16 octets. I see no problem here.
> 
> I did understand that, but I do not see point of sending extra 8-octets as
the first 8-
> octets already identifies the IKE SA...

The point is that we want to re-use IKEv2 header, which contains two IKE
SPIs.
In normal IKEv2 each side selects its own IKE SPI, but in G-IKEv2 it is
impossible.
It is the GCKS that provides GMs with SPI for rekey SA and GMs will have to
use it
to select the right SA. Obviously, GCKS is unaware of the SAs each GM might
have
(it may be a member of several groups controlled by different GCKSs and 
besides it may have a lot of ordinary IKE SAs too), so the GCKS selects SPI
in random. To minimize the chance of collision it is better to use full 16
bytes
of available room in IKEv2 header instead of only selecting SPIi,
since GMs won't contribute to this process anyway.

> > > 4.4.2.2.1.  GSA_KEY_LIFETIME Attribute
> > >
> > > Why is this attribute needed? The senders should take cere of the
> > > rekeying the SA before too much data is sent over it, so there is no
> > > security reason for this. Is this just to allow clients to clean up
> > > extra SAs in case they loose connectivity, but why then this MUST be
> > > sent.
> > >
> > > I think we could just remove this attribute.
> >
> > The sender cannot rekey GSA, it is the GCKS who can only do it.
> > If for any reason the connectivity with the GCKS is lost or it
> > unexpectedly goes offline, then the group continues to live on its own
> > and the SA lifetime can be exceeded. This attribute is a safeguard for
> > this case - each group sender will know the lifetime of the SA and
> > stops using it after that time even if no new SA is established by the
> > GCKS.
> 
> So if the connectivity to the GCKS is lost then then there is no way to
rekey GSA,
> thus it would be enough for the senders to simply stop sending and then
lifetime is
> not exceeded. Yes, receivers will not know when to remove the SA, but that
is not
> an issue for security, just extra resources.

Actually, GSA_KEY_LIFETIME is provided to all GMs, not only senders.
The receivers should also delete SA once it is expired, so no extra
resources is wasted.

> Most likely they will/should try to re-establish connection to GCKS after
the senders
> stop sending and SA is idle.

It is anticipated.

> > > 4.4.2.2.2.  GSA_INITIAL_MESSAGE_ID Attribute
> > >
> > > Could we use similar method to transport the upper 32-bits of the ESN?
> > > This would of course only work in case the GCKS is actually either
> > > part of
> > the
> > > group or knows the current upper 32-bits of the ESN using some other
> > method (for
> > > example if it is the sender to that SA).
> > >
> > > Should we provide method for this even if would not work always?
> >
> > This will reliably only work if the GCKS is the only sender in the
group.
> > I'm not sure we should add support only for this particular case.
> 
> I think the GCKS being the only sender is quite common, so we might want
to
> support that.

I'd rather to postpone this. If a new ESPv4 becomes a reality soon,
there will be no need to complicate this already complicated protocol.

> > > 6.1.  Mixing Preshared Keys in IKEv2 for Post-quantum Security
> > >
> > > This sentence needs to say something that if implementations cares
> > > those issues then it needs to:
> > >
> > >For these reasons the GCKS MUST NOT send GSA and KD payloads in the
> > >GSA_AUTH response message and MUST return a new notification
> > >REKEY_IS_NEEDED instead.
> > >
> > > As you noted the GSK_w is protected, so store now, decrypt later
> > > atta

[IPsec] Re: I-D Action: draft-ietf-ipsecme-g-ikev2-12.txt

[Valery Smyslov]

Hi,

this version addresses review from Tero.

Regards,
Valery.

> Internet-Draft draft-ietf-ipsecme-g-ikev2-12.txt is now available. It is a 
> work item of
> the IP Security Maintenance and Extensions (IPSECME) WG of the IETF.
> 
>Title:   Group Key Management using IKEv2
>    Authors: Valery Smyslov
> Brian Weis
>Name:draft-ietf-ipsecme-g-ikev2-12.txt
>Pages:   76
>Dates:   2024-08-20
> 
> Abstract:
> 
>This document presents an extension to the Internet Key Exchange
>version 2 (IKEv2) protocol for the purpose of a group key management.
>The protocol is in conformance with the Multicast Security (MSEC) key
>management architecture, which contains two components: member
>registration and group rekeying.  Both components are required for a
>GCKS (Group Controller/Key Server) to provide authorized Group
>Members (GMs) with IPsec group security associations.  The group
>members then exchange IP multicast or other group traffic as IPsec
>packets.
> 
>This document obsoletes RFC 6407.  This documents also updates RFC
>7296 by renaming a transform type 5 from "Extended Sequence Numbers
>(ESN)" to the "Replay Protection (RP)" and by renaming IKEv2
>authentication method 0 from "Reserved" to "NONE".
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-g-ikev2/
> 
> There is also an HTMLized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-g-ikev2-12
> 
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-ipsecme-g-ikev2-12
> 
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
> 
> 
> ___
> IPsec mailing list -- ipsec@ietf.org
> To unsubscribe send an email to ipsec-le...@ietf.org

___
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org

[IPsec] Re: G-IKEv2 review comments

[Valery Smyslov]

Hi Tero,

> I finally managed to finish my G-IKEv2 review. Here are my comments:

many thanks for this epic effort :-)

> --
> 2.3.4.  GCKS Registration Operations
> 
>   The GAP MAY also be
>included to provide the ATD and/or DTD (Section 4.4.3.1.1) specifying
>activation and deactivation delays for SAs generated from the TEKs.
> 
> expand ATD and DTD, this is first time they are used, so they should be
expanded
> here.

Added them to the list of terms.

> --
> 
> 2.4.3.  Deletion of SAs
> 
>The GCKS MAY specify the remaining active time of the policy by using
>the GAP_DTD attribute in the GSA GAP substructure.  If a GCKS has no
>further SAs to send to group members, the GSA and KD payloads MUST be
>omitted from the message.
> 
> What is this text related to? This deletion of SA Figures 12 and 13, do
not include
> GSA or KD payloads.

This text seems to be a leftover from early versions of the draft. Deleted.

> --
> 
> 3.4.  SA Keys
> 
>algorithm is used for encryption, then SK_a key will not be used (GM
>can use the formula above assuming the length of SK_a is zero).
> 
> I think the SA_a should GSK_a here.

Fixed.

> --
> 
> 4.4.1. Group Policies
> 
> Having terms Group Security Association Policy (GSA Policy) and Group
> associated Policy (GAP are bit difficult to read, as those two are so
similar.
> Perhaps Group Policy (GP) and Group Security Association Policy (GSAP)?

I see your point. I would leave GSA as is, and perhaps would change
GAP to Group Related policy (GR policy). "Policy" will not be part
of abbreviation in both cases. Your opinion? I didn't make any changes
yet...

> --
> 
> 4.4.2.  Group Security Association Policy Substructure
> 
> The SPI size for the IKE is 16, not 8, like in standard RFC7296 IKEv2.
> As the 8-first octets of the IKE SPI is the initiator SPI and it is only
one part that is
> used to identify the Rekey SA, so I think it could be possible to just
send 8-octets,
> i.e., the initiator SPI, and simply say that the Responder SPI of the
Rekey SA is
> simply ignored, i.e., receipient MUST use the Inititor SA to find the
rekey SA, and
> ignore the Responder SPI on recipient (and either that Initiator MUST or
SHOULD
> use the responder SPI static for all Rekey SA messages).
> 
> Or we could define we send SPIi, and the SPIr will always be same as SPIi,
so
> each rekey SA will have identical SPIi and SPIr.
> 
> Similar changes for the section 4.5.2.

Note, that a new IKE protocol GIKE_REKEY is used here,
for which the size of SPI is 16 octets. I see no problem here.

> --
> 
> 4.4.2.1.3.  Replay Protection Transform
> 
> Add titles for [RFC4302] and [RFC4303], or just change "described in
[RFC4302]
> and [RFC4303]" to "described in the AH and ESP RFCs".

Added titles.

> It might be good idea to explain the "Not used" value for RP registry here
too.
> Currently that value is only defined in sections 2.6 and 9.2, but there is
no text
> describing what that option really means (section 2.6 just says that such
value was
> added, and 9.2 adds it but no functional description is given for it.

Added such text.

> Also there have been discussion of making changes to ESP, so that we would
send
> full ESN in the header, and in that case the ESN can be used with G-IKEv2.
> 
> To allow that change the:
> 
>   For this
>reason extended sequence numbers MUST NOT be used for multicast Data-
>Security SAs and thus the value "Extended Sequence Numbers" (1) for
>the Replay Protection transform type MUST NOT be used in the GSA
>Payload.
> 
> 
> to
> 
>   For this
>reason the value "Extended Sequence Numbers" (1) for the Replay
>Protection transform type MUST NOT be used in the GSA Payload.

Done.

> --
> 
> 4.4.2.2.  GSA Attributes
> 
>   In the table, attributes that are defined as TV are
>marked as Basic (B); attributes that are defined as TLV are marked as
>Variable (V).
> 
> It would be better to use TV and TLV in the table, and not use IKEv1 terms
B(asic)
> and V(ariable) at all.
> 
> Same for 4.4.3.1, 4.5.2, 4.5.3 and 9.
> 
> Also the IANA tables in uses column "Format" to specify whether attribute
is TV or
> TLV.

Done.

> --
> 
> 
> 4.4.2.2.1.  GSA_KEY_LIFETIME Attribute
> 
> Why is this attribute needed? The senders should take cere of the rekeying
the SA
> before too much data is sent over it, so there is no security reason for
this. Is this
> just to allow clients to clean up extra SAs in case they loose
connectivity, but why
> then this MUST be sent.
> 
> I think we could just remove this attribute.

The sender cannot rekey GSA, it is the GCKS who can only do it.
If for any reason the connectivity with the GCKS is lost 
or it unexpectedly goes offline, then the group continues to live 
on its 

[IPsec] Re: WGLC of the draft-ietf-ipsecme-ikev2-qr-alt-03

[Valery Smyslov]

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
> > the first argument (PPK) is uniformly random key.
> 
> The Multiple Key Echange RFC9370 uses SK_d which is uniformly random key
> as it is generated using PRF. The PPK is NOT uniformly random key, as it
is
> usually generated by user, and might for example only contain base64-
> characters (as recommended Mixing PSKs in IKEv2 for PQ Security RFC 8784
for
> the PPK_ID_FIXED).
> 
> So SK_d is uniformly random, PPK might be or might not be depending how it
> was generated.
> 
> I do not think it affects security as much how it is generated as long as
it has
> enough entropy, but if you are concerned that PRF might not be as good if
the
> key is not uuniformy random, then you really should use SK_d instead
ofPPK.
> 
> 
> > 2. The first argument to prf is usually a key while the second is
> >  usually a (public) data, some API to crypto libraries may not
> >  allow use of a secret key as a data and may not allow export
> >  it, so the current use of PPK is generally easier to implement.
> 
> Here we have two keys, SK_d and PPK, and one of them is uniformly random
> (SK_d), and other might be uniformly random or might be very much not
> uniformly random (PPK).

My point was that it is sometimes tricky to get key data to use as a second
argument to prf.
Many APIs assume that keys are always the first argument.
It may be easier for session keys (which results of KE are)
and may be more complex for long-term keys (like PPK).
Or may be impossible at all unless you hack APIs.
The current design tries to avoid unnecessary complexities.

> > 3. The draft can be seen as an successor to RFC 8784, and it is
> > believed that these two will be implemented together, thus
> > re-using the computation method from RFC 8784 makes sense. In
> > contrast, the draft is completely independent from RFC 9370.
> 
> It is independent from the Multiple Key Exchanges RFC9370, but uses
> IKE_INTERMEDIATE echange, and the original PPK in IKE_AUTH RFC 8784 does
> not, and the text how to mix new keys to the crypto context of the IKEv2
SA
> perhaps should have been in the IKE_INTERMEDIATE RFC, not in the Multiple
> key exchanges RFC, as we can generate ways to mix new keys to crypto
context
> also in other places than multiple key exchanges.

I disagree. The idea was that IKE_INTERMEDIATE specification defines 
only the intermediate exchange and not the numerous ways it can be used.
Not all of possible use require key derivation (like RFC 9593).

And mixing keys is often needed not only for initial IKE SA,
but in CREATE_CHILD_SA too, which is not related to IKE_INTERMEDIATE at all.

On the other hand, there may be various ways to mix keys,
so I don't think we should stick with the single way for all purposes.
Note also, that mixing keys, as specified in 9370 and this draft
affects not only IKE_INTERMEDIATE, but also CREATE_CHILD_SA,
so this would be strange to specify it in IKE_INTERMEDIATE specification.

> And we did have much more discussion about the mixing of the keys when we
> were working on the multiple key exchanges RFC than when we were working
> on the PPK in IKE_AUTH RFC, so I would consider the multiple key exchanges
> version to have received more reviews.

Scott was co-author of both RFCs, thus I don't think there are any security
issues there.

What you propose will in fact complicate implementations. I assume that 
this specification will most likely be implemented by those, who already
implemented RFC 8784, and there is a substantial re-use of code.
On the other hand, RFC 9370 is more difficult to implement 
(and IKE_INTERMEDIATE is not the only source of complexity, IKE_FOLLOWUP_KE
is another).
There would be many places in code when additional conditions
should be added to implement your proposal.

Regards,
Valery.

> --
> kivi...@iki.fi

___
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org

[IPsec] Re: Comments on draft-pwouters-ipsecme-child-pfs-info

[Valery Smyslov]

Hi Paul,

 

On Thu, Aug 1, 2024 at 4:21 AM Valery Smyslov < <mailto:smyslov.i...@gmail.com> 
smyslov.i...@gmail.com> wrote:

Hi,

I also have some comments on draft-pwouters-ipsecme-child-pfs-info. 

>From the Introduction I learned that the problem this draft is trying to
address is the 
lack of knowledge at the time the initial Child SA is being created in
IKE_AUTH of what KE methods are 
configured for subsequent rekeys of this Child SA.

 

Yes.

 

So, the main purpose is to allow manual troubleshooting of possible
configuration mismatches, right?

 

And to actually allow it to fail immediately instead of later during rekey.

 

The proposed solution is limited in its functionality:
- it doesn't support policies when some KE method are tied to particular
ENCR & PRF transforms

 

That assumes that you allow a different KE from the IKE KE for the child? That 
is

questionable at best to begin with.

 

 I meant that the policy may be:

 

 - use AES-GCM with P256 

 or

 - use Chacha20 with X25519

 

 but do not mix them up any other way.

 

 This policy is impossible to express with the proposed notify.

 

- it doesn't support RFC9370

 

It's tricky to understand what a child sa KE for rekey is in the case of 
multiple KEs anyway?

Do you want to full multi Key Types protection for the child, you would have to 
redo the

entire IKE SA chain anyway because you cannot do it for the Child SA ?

 

No. RFC9370 allows using multiple key exchanges in CREATE_CHILD_SA, including 
rekeys 

(with the help of the new IKE_FOLLOWUP_KE exchange).

 

- there is no guarantee that the KE method included will be the same as used
during actual rekey

 

It should be equal or "stronger" and if you want to avoid discussion what is 
weak or strong, it

has to be the same.

 

 Imagine the situation: during IKE_AUTH you propose X25519 and Ed448 and

 your peer didn’t mind, but later he changed his policy to only allow 
Ed448

 (which is stronger, so it is OK). When you propose X25519 during 
actual rekey 

 some hours later it will fail.


It also requires quite a lot of changes in the code - currently it is
assumed that crypto transforms
negotiation is done entirely within SA payload processing. With this
proposal we have also
look at this notify, which complicates code.

 

I think the complexity is rather limited. Also see above for some assumptions 
anway.

 

In a way, it is almost mostly telling you "PFS is required or optional or 
forbidden". Or

maybe a "without PFS is fine if you immediately rekey the IKE SA afterwards".

 

 This is not what the draft proposes now.

 

Given the complexity and serious limitations of the proposed solution and
assuming that 
its main purpose is to allow manual troubleshooting of possible
configuration mismatches,
I wonder whether it would be more simple and reliable way to achieve this to
just
have a button in the implementation's UI "Test Child SA rekey"? The operator
would push this 
button to immediately force a rekey once initial SA is established and
troubleshoot
should there are any errors.

 

I want something at the protocol level. Telling people to push buttons will not 
happen.

They think "up" means success and at rekey time there will be an outage. That is

the whole problem we are solving.

 

 You may eliminate additional button. Just make so, that when

 users establishes a connection (e.g. presses “Connect” button)

 always perform an immediate rekey of Child SA and indicate “up” onle

 when it succeeds. This is seamless for user and the penalty is not big.

 

Maybe instead of KE, it makes more sense to move this to indicate the above:

- PFS for child mandatory

- PFS for child forbidden

- PFS for child optional

- PFS for child requires prompt IKE rekey

 

Would that address your concerns?

 

 That would be much better. But I would limit it to 2 flags:

 - no PFS is OK

 - using the same KE(s) as used for IKE SA is OK

 

 sent by each peer (no negotiation, just announcement).

 If no common flags exchanged, then the peers have to perform full 
CREATE_CHILD_SA with possible troubleshooting.

 And I still think that this functionality is most useful for 
draft-ietf-ipsecme-ikev2-sa-ts-payloads-opt

 and thus should live there and not in a separate draft.

 

 Regards,

 Valery.

 

Paul

___
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org

[IPsec] Comments on draft-pwouters-ipsecme-child-pfs-info

[Valery Smyslov]

Hi,

I also have some comments on draft-pwouters-ipsecme-child-pfs-info. 

>From the Introduction I learned that the problem this draft is trying to
address is the 
lack of knowledge at the time the initial Child SA is being created in
IKE_AUTH of what KE methods are 
configured for subsequent rekeys of this Child SA.

So, the main purpose is to allow manual troubleshooting of possible
configuration mismatches, right?

The proposed solution is limited in its functionality:
- it doesn't support policies when some KE method are tied to particular
ENCR & PRF transforms
- it doesn't support RFC9370
- there is no guarantee that the KE method included will be the same as used
during actual rekey

It also requires quite a lot of changes in the code - currently it is
assumed that crypto transforms
negotiation is done entirely within SA payload processing. With this
proposal we have also
look at this notify, which complicates code.

Given the complexity and serious limitations of the proposed solution and
assuming that 
its main purpose is to allow manual troubleshooting of possible
configuration mismatches,
I wonder whether it would be more simple and reliable way to achieve this to
just
have a button in the implementation's UI "Test Child SA rekey"? The operator
would push this 
button to immediately force a rekey once initial SA is established and
troubleshoot
should there are any errors.

Regards,
Valery.


___
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org

[IPsec] Re: Comments on draft-pwouters-ipsecme-delete-info

[Valery Smyslov]

Hi Paul,

 

now I will use this color for my remarks.

 

  By the way, I think that it would be more helpful to the user if you 
include “Related SPI” field

 in your notify – the SPI of the SA that caused the deletion of this SA.

 In case of INITIAL_CONTACT this might help.

 

It could be useful, but is it useful enough to add it to the structure so every 
"reason" has to have a "related SPI"

field? It might be, andwould be more structural that expecting it in a "free 
from field". So I wouldn't object to

adding this.

 

 Yes, I was thinking about a separate field for related SPI, not about 
a free form (which necessity I oppose).

 Actually, related SPI is only useful with INITIAL_CONTACT reason, but 
may still be specified for all reasons, just not be used (sent as zero) for 
most of them.

 

 Regards,

 Valery.

 

Paul

___
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org

[IPsec] Re: Comments on draft-pwouters-ipsecme-delete-info

[Valery Smyslov]

> > It just comes up to my mind that the “string” type is widely used in
> > YANG modules. But I didn’t see any with a language indictor. I wonder
> > how YANG modules handle this issue.
> >
> >  I don’t know. Perhaps those strings are not transferred on
> > the wire and are not presented to end user.
> 
> I do know. Language is not specified, the strings are sent over the wire, 
> they are
> presented to the user, and it's working just fine. Thank you for the obvious 
> example
> of why we don't need to argue/rat-hole over this anymore. :)

No problem, but then I have a question to Paul: can you as AD clarify whether 
the following page

https://wiki.ietf.org/group/art/TypicalARTAreaIssues

reflects the IESG position on reviewing the IETF documents or not?

ARTART reviewers were advised by ART AD (Francesca at that time) to check IETF 
documents
for common ART area issues, that were listed on this page. One of them is:

If your spec has protocol elements that contain human-readable text, 
you need to specify language tags for those fields, or justify why language 
tagging is not needed. 

As ARTART reviewer I wonder whether I should still pay attention to this advice 
or not
(perhaps I wrongly marked some drafts as "Not Ready" for lacking language 
information :-))

Regards,
Valery.

> Thanks,
> Chris.
> 
> 
> >
> >
> >
> >  BCP18 (RFC 2277) states in Section 4.2:
> >
> >
> >
> >Protocols that transfer text MUST provide for carrying information
> >
> >about the language of that text.
> >
> >
> >
> >Protocols SHOULD also provide for carrying information about the
> >
> >language of names, where appropriate.
> >
> >
> >
> > and in Section 4.4:
> >
> >
> >
> >Protocols where users have text presented to them in response to
> > user
> >
> >actions MUST provide for support of multiple languages.
> >
> >
> >
> >  Regards,
> >
> >  Valery.
> >
> >
> >
> > Regards & Thanks！
> >
> > Wei PAN (潘伟)
> >
> >
> >
> > ___
> > IPsec mailing list -- ipsec@ietf.org
> > To unsubscribe send an email to ipsec-le...@ietf.org

___
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org

[IPsec] Re: Comments on draft-pwouters-ipsecme-delete-info

[Valery Smyslov]

Hi William,

 

Hi Valery,

 

 I would also add that if this field is left, then the issues with its 
language must be addressed. 

 In particular, a compliance with BCP18 is needed.

 

It just comes up to my mind that the “string” type is widely used in YANG 
modules. But I didn’t see any with a language indictor. I wonder how YANG 
modules handle this issue.

 

 I don’t know. Perhaps those strings are not transferred on the wire 
and are not presented to end user.

 

 BCP18 (RFC 2277) states in Section 4.2:

 

   Protocols that transfer text MUST provide for carrying information

   about the language of that text.

 

   Protocols SHOULD also provide for carrying information about the

   language of names, where appropriate.

 

and in Section 4.4:

 

   Protocols where users have text presented to them in response to user

   actions MUST provide for support of multiple languages.

 

 Regards,

 Valery.

 

Regards & Thanks！

Wei PAN (潘伟)

___
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org

[IPsec] Re: Comments on draft-pwouters-ipsecme-delete-info

[Valery Smyslov]

Hi William,

 

Hi,

 

I’ve read the threads, and to avoid the long email page I try to summarize my 
opinions below.

 

1. I also support making this document Informational or Experimental.

 

2. Through the discussions, I feel that even IPsec experts will have 
inconsistencies and ambiguities in their understanding of the reasons currently 
defined. Without clear definition and consistent understanding, this delete 
reason hint may be misguiding. I suggest that we summarize the common 
situations/reasons of the SA deletion, and give more details about these 
situations, i.e., explaining the delete reasons better, to ensure everyone 
having the same understanding.

 

 I would suggest to add a “Related SPI” that would specify the SPI of 
the SA that somehow caused this SA to be deleted.

 This would be really helpful for INITIAL_CONTACT reason.

 

3. Regarding the “Delete Reason Text”, I have no concern with the language 
issue, because it’s only a hint, and you can use it if you understand it and 
ignore it if you don’t. But my concern is what if you can understand the text 
but it is inconsistent with the “Delete Reason Type”, then which one should be 
considered true. So my suggestion is to not have this text field in the first 
available version, or to make it optional and not use it when a specific delete 
reason type is given. I.e., we should use the “Delete Reason Type” as much as 
possible.

 

 I would also add that if this field is left, then the issues with its 
language must be addressed. 

 In particular, a compliance with BCP18 is needed.

 

 Regards,

 Valery.

 

Regards & Thanks！

Wei PAN (潘伟)

 

___
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org

[IPsec] Re: Comments on draft-pwouters-ipsecme-delete-info

[Valery Smyslov]

Hi Paul,

 

(I think gmail is reaching its limits on careful quoting context, hope I get it 
all right)

 

 I will mark my replies with this color.

 

 

 As I wrote in the message to Chris, if we use any human-readable text 
in the protocol,

 then we MUST support multiple languages to be compliant with BCP18 
(RFC2277, Sections 4.4, 4.2).

 This is what “Typical ART Area Issues” page 
(https://wiki.ietf.org/group/art/TypicalARTAreaIssues) 

requires to check when doing ART review. I really don’t want to open this I18N 
can of worms L

 

 And in this case the text won’t always help much. Will you understand 
what is happening if I send you:

 

Сервер отключен для пусконаладочных работ, включим после дождичка в четверг

 

 Will it help your debugging? I doubt.

 

No but if it says "abra cadabra conn 'vpn-customer1-toronto-rain[4]' more words 
and words", it could already help me

debugging so I know to look for my connection named vpn-customer1-toronto-rain, 
using state object 4. Obviously,

this depends on implementation. But it is definitely not useless.

 

 And what you will do with “vpn-customer1-toronto-rain[4]” at your 
side? This is the name of the connection

 on peer’s side that doesn’t relate to your configuration at all (even 
more true for state object). You still

 to have to call the peer and in this case the only information it 
needs is an SPI.

 

 By the way, I think that it would be more helpful to the user if you 
include “Related SPI” field

 in your notify – the SPI of the SA that caused the deletion of this SA.

 In case of INITIAL_CONTACT this might help.

 

 2. The list of reasons looks to me both incomplete and excessive at the same
time.
For example, CONFIGURATION_CHILD_REMOVED and CONFIGURATION_IKE_REMOVED
are not needed, since you either delete IKE SA or Child SA in a single
exchange, so it is 
always clear what configuration is removed and only one such reason
would suffice. 

 

This is not about the current instance of the exchange but about the local 
configuration. It basically

says "this one tunnel is no longer configured" vs "the entire config for the 
peer has been removed".

 

 OK, this is not clear from the draft (that increases my concerns that 
without

 direct (phone) contact with the peer these reason have little value).

 

Yes, the notify reason basically TOLD YOU, there is an expectation difference 
between you and the peer. Maybe

you forgot to pay a bill. It's a feature not a bug :)

 

 And the bill number with the needed sum will be included into the 
reason text? J

 

 

 Can you please provide an example or give more detailed explanation 
how this can happen?

 From my understanding of IKEv2 it is always known from the local logs

 which SA is deleted as erroneous in case of simultaneous rekey. Am I 
missing something?

 

Often when we deal with customers, they cannot produce a log on their end and 
finding reasons about their

behaviour is impossible. Having the remote peer put some information into a 
delete reason payload would mean

the customer's equipment does tell us a bit better why, without needing the 
remote logs.

 

 My point was that deletion due to the simultaneous rekey is always 
clear from any side’s logs…

 At least from our experience. The only case when remote logs are 
needed in this case is

 when you turned off local logging…

 

The point of this reason is to put the Exec Summary of that phone call in the 
payload :)

 

 This is not really needed. The only information that is needed for the 
phone call is SPI of the SA.

 

Not in my world. The extend of info a customer tells me about their Cisco 
failure is usually a "tunnel failed".

They usually dont know how to get logs, how to enable debugging, or who to talk 
to to help with their ipsec

machine.

 

 In this case how the reason notify would help? I presumed that this 
notify is for logging purposes only

 and if users don’t know how to get their own logs, then they cannot 
tell you the received reason.

 Or is it intended to be displayed to the user on a UI? Randomly 
popping up?

 

 

 I see. It won’t help those poor who was down when the hardware started 
been replaced – 

 they never receive this announcement and won’t know why the cannot 
connect J

 

Some of my customers run an RFC5685 IKEV2 redirect proxy in front of their 
servers, so this wouldn't be

a problem :)   So imagine you receive a "deleted connection because IPsec GW 
being upgraded", but with

0 downtime. You redirect and the proxy redirects you. If you were down for a 
few seconds, you know what the

cause was, that you not need to do anything.

 

 Redirect would help in this case regardless of the reason code.

 As a customer, I’d rather use it i

[IPsec] Re: Comments on draft-pan-ipsecme-anti-replay-notification

[Valery Smyslov]

Hi Paul,

 

 Perhaps this discussion is a bit premature, since I currently have to 
guess what 

 you intend to achieve and how this influences packet processing.

 Can you please include answers to the following questions in the next 
revision:

 

 1. What happens with SN if peers negotiate not using replay protection:

 - will it be incremented or send as a constant (what constant)?

 - if incremented will it be allowed to wrap around (I guess yes)?

 

It will be incremented, eg just like today, guaranteed to be unique.

It will not be allowed to wrap (this cannot work with things like AES_GCM where 
the same number is in use)

 

 

 2. What happens with ESN if peers negotiate ESN and not using replay 
protection:

 - will SN be incremented or send as a constant (what constant)?

 

Same as above. The sending does not get modified at all. Only the receiving 
side omits any checks for in-order

or in-window and will always allow any packet with any SN.

 

 - how the upper half of ESN is computed (it is included in ICV 
calculation)? Will it be deducted as usual or be constant?

 

Same as now.

 

 - if ESN is incremented, will it be allowed to wrap around?

 

No - same as now.

 

 

 Sorry, but here I’m completely lost. From your explanation it looks 
like the sender’s behavior is not affected by this notify – 

 it is the same for both SN and ESN cases regardless of whether this 
notify was exchanged or not. Given the fact, that reply protection is a local 
matter – 

 what is the purpose of this notify? In other words, why to inform the 
other side about the state of your replay protection if this information 

 doesn’t change that side’s behavior as a sender? What’s the reason? Am 
I missing something?

 

 If the negotiation of the replay protection status is still needed, then:

- it is better to be done in a way it is done in draft-ietf-ipsecme-g-ikev2
(section 2.6),
  since it couples this feature with negotiation of ESN

 

I am not a big fan of renaming the type 5 registry into "replay protection". It 
seems to mixup integers

with flags (bits) and become a grab bag of miscellaneous things. 

 

 Not really, this is still integers:

 - SN

 - ESN

 - no replay protection (do not look at SN at all)

 

SN or ESN cannot be sent as constant number, or rather it can be since you have 
to keep a counter anyway

for the AEAD counter, there is no point doing that. Only the receiver changes 
as to not drop any packets

based on SN / ESN.

 

 This is only true for implicit IV. All original AEAD transforms use 
explicit IV that is not

 related to (E)SN. And in case of several multicast senders the GCKS 
takes care

 to assign a unique IV prefix to each sender, so IVs don’t repeat 
(unlike SNs).

 Transforms with implicit IV cannot be used with multicast, which is 
documented in RFC 8750, Section 7.

 

replay protection is therefor orthogonal to SN/ESN, which is why I don't like 
mashing this into the Transform Type 5.

 

 Not completely. In case of several unsynchronized multicast sender the 
SN is not guaranteed to be unique, 

 thus the replay protection is turned off. In this case ESN cannot be 
used at all.

 

 

 Why doesn't the g-ikev2 doc simply

say to always negotiate NO-ESN if that is what is needed. I don't see the need 
for a rename of the ESN

IANA registry?

 

 Because if we want to negotiate replay protection in IKEv2 this is 

 a better way to do it via transform then via notify. Because,

 for example, you may propose no replay protection only with

 those encryption transforms, that have explicit IV and always propose 

 replay protection for implicit IV. 

 

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

 

 The last case is meaningless for multicast scenario. 

 

Hence my comment about bytes and flags being a bit confusing. I don't think we 
can repurpose this registry as

flags (bits) because some implementations will read the two octets and require 
the integer 0 or 1 out of that.

 

 I still have to understand why you want to inform the other side about 
your replay protection state

 if this doesn’t change that side’s behavior as a sender.

 

 Multicast is a separate thing, where “ESN without replay protection” 
makes no sense.

 

 

 I just wonder that if you negotiate not using replay protection, then 

 the sender is free to send constant (E))SN or allowing SN it to wrap 
around,

 that is obviously incompatible with RFC 8750.

 

I don't think anyone should do constant (E)SN or wrapping around ever. I think 
these two items have nothing

to do with replay prote

[IPsec] Re: Comments on draft-pwouters-ipsecme-delete-info

[Valery Smyslov]

> >> humans are capable of reading text in a language w/o needing a tag to
> > identify it.
> >
> > I emphatically disagree. If I send you the following reason message,
> > will it help you?
> >
> > Сервер отключен для пусконаладочных работ на три часа
> 
> This example doesn't make sense to me, it seems contrived to make some point
> but it's not realistic.
> 
> People aren't contacting random IPsec servers that are mis-configured for 
> their
> users. If the user wouldn't understand the above language then the operator
> wouldn't configure it.

There are a lot of VPN services in the wild that provide access
to the Internet worldwide from where it is restricted. Some of them use 
IKEv2/IPsec
and they don't care about the languages their users understand. For the users
it is a just a "random IPsec server".

Regards,
Valery.

> Thanks,
> Chris.
> 
> >
> > You will probably use Google translate and it will ask you what
> > language it is in?
> > Sometimes it can correctly guess the language (and the text above is
> > an easy example), but often not.
> > I also want to point out that some languages (e.g. Finnish) are very
> > difficult for machine translation.
> >
> > FWIW, using language tags is not my whim. If we leave human-readable
> > text in the protocol, then we MUST support multiple languages and MUST
> > be able to transfer language information to be compliant with BCP18
> > (RFC 2277, Section 4.2, Section 4.4).
> > I don't want to deal with all this issues, so I'd rather to not
> > include fields with human-readable text in IKEv2.
> >
> > Regards,
> > Valery.
> >
> >> I do think the encoding might need to be specified, since that is
> > something the
> >> computer may need to understand.
> >>
> >> Thanks,
> >> Chris.
> >>
> >>
> >>
> >> >
> >> > In general, I think it is a bad idea to transmit text strings
> >> > to be read by users in a low level
> >> > protocol which IKEv2 is. This is an UI issue, and it is the UI
> >> > that should properly display to the user in a user
> >> > chosen language what is happening.
> >> >
> >> > 2. The list of reasons looks to me both incomplete and excessive at
> >> > the same time.
> >> > For example, CONFIGURATION_CHILD_REMOVED and
> >> CONFIGURATION_IKE_REMOVED
> >> > are not needed, since you either delete IKE SA or Child SA in a
> >> > single exchange, so it is
> >> > always clear what configuration is removed and only one such
> >> > reason would suffice.
> >> > SIMULTANEOUS_REKEY adds no new information,
> >> > since you always understand this reason from local logs. On the
> >> > other hand,
> >> > it is not specified what to indicate in the reason when ESP SA
> >> > is being deleted
> >> > in response to deleting the tied ESP SA for the other direction.
> >> >
> >> >In general, I think that indicating the reason the SA is deleted
> >> > doesn't help much the user much.
> >> >In many cases it can be inferred from local logs. And if it
> >> > cannot, then you probably
> >> >will to contact the other end in any case to get more detailed
> >> > information on the reason,
> >> >in which case sending the reason on the wire has little value.
> >> >
> >> > 3. Perhaps the most useful field is Downtime. But thinking more
> >> > about
> > this,
> >> >I believe that since this value is only a hint, you will
> >> > probably not trust it.
> >> >For example, if you have to communicate to the peer ASAP and it
> > deletes
> >> >SA indicating that downtime is 1 hour, you will not wait for all
> >> > this time,
> >> >you will try to establish new SA every minute (it costs you
> >> > nothing,
> > but
> >> >you have a chance to get it up earlier).
> >> >
> >> > Regards,
> >> > Valery.
> >> >
> >> > ___
> >> > IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email
> >> > to ipsec-le...@ietf.org

___
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org

[IPsec] Re: Comments on draft-pan-ipsecme-anti-replay-notification

[Valery Smyslov]

Hi Paul,

 

I think that the following assertion in the draft is wrong:

   Although
   ESN is good to avoid the sequence number running out in a short
   period, there is a prerequisite for using ESN - RFC 4302 and RFC 4303
   both require ESN to be used in conjunction with the anti-replay
   function.  That is, ESN can only be used if the anti-replay feature
   is enabled.

Actually, RFC 4303 and RFC 4302 say:

   Note: If a receiver chooses to not enable anti-replay for an SA, then
   the receiver SHOULD NOT negotiate ESN in an SA management protocol.

While SHOULD is a strong requirement, it is still not MUST, so it is 
perfectly valid to use ESN with no replay protection if you have a good 
reason (and you have).

 

The text can be tweaked. But in practise these two properties are currently 
linked.

 

In the case when the receiver has disabled anti-replay, but negotiated
ESN, it still needs to monitor SN values in the incoming packets and
maintain the upper
half of the ESN, since it is included in the ICV calculation.
But this is really small burden, compared to full replay protection.

Thus, I don't see a need for this notification at all. 

 

The issue is that clients want to have both "disable replay protection" and 
"ESN". Currently, many

implementations (including Linux) do not support this. We are working on 
getting that fixed, but that

will inevitably need a signal by the IKE daemon to let peers know what is 
supported and desired, so

that ESN can be requested for those that support ESN without replay protection. 
And so that NO-ESN

can be selected for those implementations that do not support "disable replay 
protection" with ESN.

 

I missed the deadline to extend the notify payload to add this signaling. The 
next revision will include this.

 

 Perhaps this discussion is a bit premature, since I currently have to 
guess what 

 you intend to achieve and how this influences packet processing.

 Can you please include answers to the following questions in the next 
revision:

 

 1. What happens with SN if peers negotiate not using replay protection:

 - will it be incremented or send as a constant (what constant)?

 - if incremented will it be allowed to wrap around (I guess yes)?

 

 2. What happens with ESN if peers negotiate ESN and not using replay 
protection:

 - will SN be incremented or send as a constant (what constant)?

 - how the upper half of ESN is computed (it is included in ICV 
calculation)? Will it be deducted as usual or be constant?

 - if ESN is incremented, will it be allowed to wrap around?

 

If the negotiation of the replay protection status is still needed, then:

- it is better to be done in a way it is done in draft-ietf-ipsecme-g-ikev2
(section 2.6),
  since it couples this feature with negotiation of ESN

 

I am not a big fan of renaming the type 5 registry into "replay protection". It 
seems to mixup integers

with flags (bits) and become a grab bag of miscellaneous things. 

 

 Not really, this is still integers:

 - SN

 - ESN

 - no replay protection (do not look at SN at all)

 

Why doesn't the g-ikev2 doc simply

say to always negotiate NO-ESN if that is what is needed. I don't see the need 
for a rename of the ESN

IANA registry?

 

 Because if we want to negotiate replay protection in IKEv2 this is 

 a better way to do it via transform then via notify. Because,

 for example, you may propose no replay protection only with

 those encryption transforms, that have explicit IV and always propose 

 replay protection for implicit IV. 

 

- a text should be added about incompatibility with RFC 8750

 

I guess we could, although I feel that RFC 8750 should have been more explicit 
in saying "ESN is not

supported due to re-using the same counter after 2^32 bytes". There is nothing 
specific to this draft that

related to that. Seems more like an errata against 8750, but I don't object to 
warning users here either.

 

 This is wrong, RFC 8750 supports ESN. In fact it does always use 64 
bit IV,

 but with no ESN the upper half is set to zero.

 

 I just wonder that if you negotiate not using replay protection, then 

 the sender is free to send constant (E))SN or allowing SN it to wrap 
around,

 that is obviously incompatible with RFC 8750.

 

 Regards,

 Valery. 

 

Paul

 

___
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org

[IPsec] Re: Comments on draft-pwouters-ipsecme-delete-info

[Valery Smyslov]

Hi Paul,

 

On Mon, Jul 29, 2024 at 6:18 AM Valery Smyslov < 
<mailto:smyslov.i...@gmail.com> smyslov.i...@gmail.com> wrote:

Hi,

I have some comments on draft-pwouters-ipsecme-delete-info that I tried to
express at IETF120,
but due to lack of time they were not responded to.

1. I'm very much concerned with the "Delete Reason Text" field. My primary
question - 
in what language this free text explanation is supposed to be? I suppose

it is assumed to be English, but why do you think all customers in the
world understand English well enough
for this field to be really useful? If arbitrary language is allowed,
then we need to add a language tag,
otherwise it is generally impossible to even recognize what language the
text is in.
And allowing arbitrary language makes this field even less useful.

 

The idea is that the provider uses some language it knows the receiver would 
understand, in addition

to the enum. Computers and UIs can be use the ENUM, and I expect most people 
would not need

or want custom text. However, when presented at IETF119 the group was split. 
Half wanted an enum

and half wanted free flow text. This was the compromise.

 


In general, I think it is a bad idea to transmit text strings to be read
by users in a low level
protocol which IKEv2 is. This is an UI issue, and it is the UI that
should properly display to the user in a user
chosen language what is happening.

 

In general, I agree. Although I could also see the freeform text to perhaps but 
in some more details

that could make debugging easier.

 

 As I wrote in the message to Chris, if we use any human-readable text 
in the protocol,

 then we MUST support multiple languages to be compliant with BCP18 
(RFC2277, Sections 4.4, 4.2).

 This is what “Typical ART Area Issues” page 
(https://wiki.ietf.org/group/art/TypicalARTAreaIssues) 

requires to check when doing ART review. I really don’t want to open this I18N 
can of worms L

 

 And in this case the text won’t always help much. Will you understand 
what is happening if I send you:

 

Сервер отключен для пусконаладочных работ, включим после дождичка в четверг

 

 Will it help your debugging? I doubt.

 

2. The list of reasons looks to me both incomplete and excessive at the same
time.
For example, CONFIGURATION_CHILD_REMOVED and CONFIGURATION_IKE_REMOVED
are not needed, since you either delete IKE SA or Child SA in a single
exchange, so it is 
always clear what configuration is removed and only one such reason
would suffice. 

 

This is not about the current instance of the exchange but about the local 
configuration. It basically

says "this one tunnel is no longer configured" vs "the entire config for the 
peer has been removed".

 

 OK, this is not clear from the draft (that increases my concerns that 
without

 direct (phone) contact with the peer these reason have little value).

 

SIMULTANEOUS_REKEY adds no new information,
since you always understand this reason from local logs. On the other
hand,
it is not specified what to indicate in the reason when ESP SA is being
deleted
in response to deleting the tied ESP SA for the other direction.

 

In general yes, but again we have seen race conditions and uncertainly, where I 
think it would have

helped debugging if this reason was explicitly logged as part of the exchange. 

 

 Can you please provide an example or give more detailed explanation 
how this can happen?

 From my understanding of IKEv2 it is always known from the local logs

 which SA is deleted as erroneous in case of simultaneous rekey. Am I 
missing something?

 

   In general, I think that indicating the reason the SA is deleted doesn't
help much the user much.
   In many cases it can be inferred from local logs. And if it cannot, then
you probably 
   will to contact the other end in any case to get more detailed
information on the reason, 
   in which case sending the reason on the wire has little value.

 

The point of this reason is to put the Exec Summary of that phone call in the 
payload :)

 

 This is not really needed. The only information that is needed for the 
phone call is SPI of the SA.

 

And perhaps entities that don't answer the phone (eg hyperscale cloud 
providers) would

populate those automatically, since they are usually not reachable by phone :)

 

 Yes, but what you do with the reason information in this case?

 Either the deletion is expected (you may guess the reason or knows it 
for sure) or not.

 In the latter case, when the peer behaves strangely to you (suddenly 
deletes SA with no clear reason)

 you either live with this or still have to reach out to the peer by 
phone.

 Even if peer sends you  CONFIGURATION_IKE_REMOVED won’t 

 you try to phone and

[IPsec] Re: Comments on draft-pwouters-ipsecme-delete-info

[Valery Smyslov]

Hi Chris,

> > Hi,
> >
> > I have some comments on draft-pwouters-ipsecme-delete-info that I
> > tried to express at IETF120, but due to lack of time they were not
> > responded to.
> >
> > 1. I'm very much concerned with the "Delete Reason Text" field. My
> > primary question -
> > in what language this free text explanation is supposed to be? I
> > suppose
> >
> > it is assumed to be English, but why do you think all customers in
> > the world understand English well enough
> > for this field to be really useful? If arbitrary language is
> > allowed, then we need to add a language tag,
> > otherwise it is generally impossible to even recognize what
> > language the text is in.
> > And allowing arbitrary language makes this field even less useful.
> 
> This text is for humans to read not computers, I understood that it's been
asked for
> by users to help them understand better why something was deleted.
> 
> The language can be left up to the implementation it should not be
standardized.
> One could easily imagine the language being one of the following:
> 
> 1) Multiple language choices (perhaps set by Locale) configured by user.

The problem is that the locale is configured on the sending host,
while the reader of the text is on the receiving host.

> 2) English

I suspect not all customers in the world understands English well enough.
Also see below.

> Supporting locale's (or not) is something that implementations
differentiate
> themselves in the market on.
> 
> In any case a computer is not parsing the language, so there's no need for
a tag
> identifying the language. Again the message is meant for humans to read
and
> humans are capable of reading text in a language w/o needing a tag to
identify it.

I emphatically disagree. If I send you the following reason message, will it
help you?

Сервер отключен для пусконаладочных работ на три часа

You will probably use Google translate and it will ask you what language it
is in?
Sometimes it can correctly guess the language (and the text above is an easy
example), but often not.
I also want to point out that some languages (e.g. Finnish) are very
difficult for machine translation.

FWIW, using language tags is not my whim. If we leave human-readable text in
the protocol,
then we MUST support multiple languages and MUST be able to transfer
language information 
to be compliant with BCP18 (RFC 2277, Section 4.2, Section 4.4).
I don't want to deal with all this issues, so I'd rather to not include
fields with human-readable text in IKEv2.

Regards,
Valery.

> I do think the encoding might need to be specified, since that is
something the
> computer may need to understand.
>
> Thanks,
> Chris.
> 
> 
> 
> >
> > In general, I think it is a bad idea to transmit text strings to
> > be read by users in a low level
> > protocol which IKEv2 is. This is an UI issue, and it is the UI
> > that should properly display to the user in a user
> > chosen language what is happening.
> >
> > 2. The list of reasons looks to me both incomplete and excessive at
> > the same time.
> > For example, CONFIGURATION_CHILD_REMOVED and
> CONFIGURATION_IKE_REMOVED
> > are not needed, since you either delete IKE SA or Child SA in a
> > single exchange, so it is
> > always clear what configuration is removed and only one such
> > reason would suffice.
> > SIMULTANEOUS_REKEY adds no new information,
> > since you always understand this reason from local logs. On the
> > other hand,
> > it is not specified what to indicate in the reason when ESP SA is
> > being deleted
> > in response to deleting the tied ESP SA for the other direction.
> >
> >In general, I think that indicating the reason the SA is deleted
> > doesn't help much the user much.
> >In many cases it can be inferred from local logs. And if it cannot,
> > then you probably
> >will to contact the other end in any case to get more detailed
> > information on the reason,
> >in which case sending the reason on the wire has little value.
> >
> > 3. Perhaps the most useful field is Downtime. But thinking more about
this,
> >I believe that since this value is only a hint, you will probably
> > not trust it.
> >For example, if you have to communicate to the peer ASAP and it
deletes
> >SA indicating that downtime is 1 hour, you will not wait for all
> > this time,
> >you will try to establish new SA every minute (it costs you nothing,
but
> >you have a chance to get it up earlier).
> >
> > Regards,
> > Valery.
> >
> > ___
> > IPsec mailing list -- ipsec@ietf.org
> > To unsubscribe send an email to ipsec-le...@ietf.org

___
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org

[IPsec] Comments on draft-pan-ipsecme-anti-replay-notification

[Valery Smyslov]

Hi,

I have some comments on draft-pan-ipsecme-anti-replay-notification that I
tried to express at IETF120, 
but due to lack of time they were not responded to.

I think that the following assertion in the draft is wrong:

   Although
   ESN is good to avoid the sequence number running out in a short
   period, there is a prerequisite for using ESN - RFC 4302 and RFC 4303
   both require ESN to be used in conjunction with the anti-replay
   function.  That is, ESN can only be used if the anti-replay feature
   is enabled.

Actually, RFC 4303 and RFC 4302 say:

   Note: If a receiver chooses to not enable anti-replay for an SA, then
   the receiver SHOULD NOT negotiate ESN in an SA management protocol.

While SHOULD is a strong requirement, it is still not MUST, so it is 
perfectly valid to use ESN with no replay protection if you have a good 
reason (and you have).

In the case when the receiver has disabled anti-replay, but negotiated
ESN, it still needs to monitor SN values in the incoming packets and
maintain the upper
half of the ESN, since it is included in the ICV calculation.
But this is really small burden, compared to full replay protection.

Thus, I don't see a need for this notification at all. 

If the negotiation of the replay protection status is still needed, then:

- it is better to be done in a way it is done in draft-ietf-ipsecme-g-ikev2
(section 2.6),
  since it couples this feature with negotiation of ESN
- a text should be added about incompatibility with RFC 8750

Regards,
Valery.

___
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org

[IPsec] Comments on draft-pwouters-ipsecme-delete-info

[Valery Smyslov]

Hi,

I have some comments on draft-pwouters-ipsecme-delete-info that I tried to
express at IETF120,
but due to lack of time they were not responded to.

1. I'm very much concerned with the "Delete Reason Text" field. My primary
question - 
in what language this free text explanation is supposed to be? I suppose

it is assumed to be English, but why do you think all customers in the
world understand English well enough
for this field to be really useful? If arbitrary language is allowed,
then we need to add a language tag,
otherwise it is generally impossible to even recognize what language the
text is in.
And allowing arbitrary language makes this field even less useful.

In general, I think it is a bad idea to transmit text strings to be read
by users in a low level
protocol which IKEv2 is. This is an UI issue, and it is the UI that
should properly display to the user in a user
chosen language what is happening.

2. The list of reasons looks to me both incomplete and excessive at the same
time.
For example, CONFIGURATION_CHILD_REMOVED and CONFIGURATION_IKE_REMOVED
are not needed, since you either delete IKE SA or Child SA in a single
exchange, so it is 
always clear what configuration is removed and only one such reason
would suffice. 
SIMULTANEOUS_REKEY adds no new information,
since you always understand this reason from local logs. On the other
hand,
it is not specified what to indicate in the reason when ESP SA is being
deleted
in response to deleting the tied ESP SA for the other direction.

   In general, I think that indicating the reason the SA is deleted doesn't
help much the user much.
   In many cases it can be inferred from local logs. And if it cannot, then
you probably 
   will to contact the other end in any case to get more detailed
information on the reason, 
   in which case sending the reason on the wire has little value.

3. Perhaps the most useful field is Downtime. But thinking more about this,
   I believe that since this value is only a hint, you will probably not
trust it.
   For example, if you have to communicate to the peer ASAP and it deletes
   SA indicating that downtime is 1 hour, you will not wait for all this
time,
   you will try to establish new SA every minute (it costs you nothing, but
   you have a chance to get it up earlier).

Regards,
Valery.

___
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org

[IPsec] Re: Review of draft-ietf-ipsecme-ikev2-qr-alt

[Valery Smyslov]

Hi Tero,

> I think the reason I am unhappy with the current one is that I do not like
the fixed
> 8-octet stuff at the end, which we can't change without allocating yet
another
> notification (in case someone would want to change it to 16 octets, we
need to
> allocate new PPK_IDENTITY_KEY2 notify for it. If there would be length of
the
> PPK_ID and PPK Confirmation in the beginning of the notify that would
allow
> extending the notify later, by adding stuff in the end if needed, and
modifying the
> size of the PPK Confirmation, so if we are not really defining new format,
but are
> just concatining two things to together, we could do that by adding new
PPK ID
> types which include PPK Confirmation inside.

The fixed 8 bytes were used for simplicity. The purpose of this field
is only to avoid use of misconfigured PPKs, so it is believed
that 2^-64 is an adequate chance for misusing PPK.
In the worst case the SA won't be established with no clear
reason in the log file - just "invalid ICV".

If you really concern the length might be insufficient, then we can change
PPK_IDENTITY_KEY
to have the confirmation length at the beginning (1 octet) following
by the confirmation following by the PPK_ID.

> > It is not that simple. Actually, your proposal complicates code and
> > adds potential vulnerabilities. Note, that the current draft uses both
> > PPK_IDENTITY_KEY (with confirmation) in request and PPK_IDENTITY (w/o
> > confirmation, the same as in RFC 8784) in response. All PPK_ID types
> > (currently defined and future) are eligible to appear in both
> > notifications. The reason two notification are used is that only
> > responder checks the confirmation. The initiator proposes PPK and
> > provides the confirmation, the responder checks whether it is correct.
> > There is no need for initiator to check it again, thus the
> > confirmation is omitted in response.
> 
> Yes, actually it would be better if the PPK_IDENTIFY notify would have
included bit
> more of than just one octet of the type, then we could have taken another
byte for
> the confirmation length and have that as zero if it is not needed.

This still would be a new notification and not a new ID type.

> Anyways this is minor point, I am just bit concerned of the fixed 8 octet
stuff we
> have there... They have a habit of causing problems.

See above.

> > If it were included in the response then we'd have a bunch of
> > problems: the initiator have either check it again (for what?) or
> > ignore.
> 
> I would say it would be fatal protocol error if such confirmation is used
by
> responder when responding to initiator. Just adding text you MUST NOT use
> confirmation versions of the IDs when indicating PPK from responder to
initiator.

I see no reason to do it. The draft is clear that the responder should
return
PPK_IDENTITY, and not PPK_IDENTITY_KEY for the protocol to continue.
If it doesn't, then this extension just won't be used, nothing fatal.

> Or just ignore, what the initiator will do now if the responder decides to
use
> PPK_IDENTIFY_KEY in addition to PPK_IDENTITY... And if responder does not
> use PPK_IDENTITY but uses PPK_IDENTIFY_KEY I assume that is fatal error
now
> already?

Not really. This will be treated as an unexpected notify and will be
ignored.
And since no PPK_IDENTITY is returned, the initiator will assume
that no matching PPK exists on the responder and continue accordingly (3.1
bullet "c").

> > In the former case we have to handle situations when the confirmation
> > is incorrect (that actually is difficult to be handled gracefully,
> > since this is probably a broken responder implementation in which case
> > the initiator should not even inform the responder about the problem,
> > making it difficult to debug if that happens). In the latter case we
> > have a perfect covert channel (data that is transmitted, but never
> > used in the protocol), which I want to avoid.
> > For these reason the response doesn't include confirmation and uses
> > different notification type.
> 
> IKEv2 has so many covert channels inside the IKE SA, that this is does not
even
> count. Just use Status Notify payloads, vendor id payloads, or CERT or
CERTREQ
> payloads etc.

This is not the reason we should add more :-)

> > IKE_INTERMEDIATE (RFC 9242) doesn't define how additional keys are
> > stirred into session keys computation - it is agnostic to this key
> > derivation. It is Multiple Key Exchanges (RFC 9370) which does. Both
> > this specification and RFC 9370 use IKE_INTERMEDIATE, but they are
> > independent from each other and I see no reason why they have to use
> > the same method for key derivation. I can even imagine that some new
> > specification appears in the future that will rely on IKE_INTERMEDIATE
> > and specify another method (more secure or more
> > efficient) for session keys calculation.
> 
> If you are not going to use what we agreed on the mutliple key exchanges
rfc, then
> you need to justify why you think what you 

[IPsec] Re: WGLC of the draft-ietf-ipsecme-ikev2-qr-alt-03

[Valery Smyslov]

Hi,

> This will start two week WGLC for the draft-ietf-ipsecme-ikev2-qr-alt [1]. 
> This last
> call will end at 2024-08-11. If you have any comments about the draft send 
> them to
> the WG list.
> 
> This current draft uses different method of mixing the secret data to the IKE 
> SA
> state than the Multiple Key Exchanges RFC9370 [2], and this is one of the 
> items I
> would like to get confirmation from the WG.
> 
> The current draft uses:
> 
>   SKEYSEED' = prf+ (PPK, SK_d)
> 
>   {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr}
>= prf+ (SKEYSEED', Ni | Nr | SPIi | SPIr )
> 
> When Multiple Key Exchanges RFC9370 uses:
> 
>   SKEYSEED(n) = prf(SK_d(n-1), SK(n) | Ni | Nr)
> 
>   {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr}
>= prf+ (SKEYSEED', Ni | Nr | SPIi | SPIr )
> 
> (we could simply use that by saying that SK(n) = PPK in that calculation, and 
> if we
> have both multiple key exchanges and PPK, we would concatenate PPK and
> SK(n))
> 
> [1] https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-qr-alt/
> [2] https://datatracker.ietf.org/doc/rfc9370/

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 the first 
argument (PPK) is uniformly random key.
2. The first argument to prf is usually a key while the second is usually a 
(public) data, some API to crypto libraries may not
 allow use of a secret key as a data and may not allow export it, so the 
current use of PPK is generally easier to implement.
3. The draft can be seen as an successor to RFC 8784, and it is believed that 
these two will be implemented together,
thus re-using the computation method from RFC 8784 makes sense. In 
contrast, the draft is completely independent from RFC 9370.

Regards,
Valery.

> --
> kivi...@iki.fi
> 
> ___
> IPsec mailing list -- ipsec@ietf.org
> To unsubscribe send an email to ipsec-le...@ietf.org

___
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org

[IPsec] Re: I-D Action: draft-ietf-ipsecme-ikev2-qr-alt-03.txt

[Valery Smyslov]

Hi,

this version contains more changes as a result of discussion with Tero.

Regards,
Valery.

> -Original Message-
> From: internet-dra...@ietf.org 
> Sent: Friday, July 26, 2024 5:00 PM
> To: i-d-annou...@ietf.org
> Cc: ipsec@ietf.org
> Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-qr-alt-03.txt
> 
> Internet-Draft draft-ietf-ipsecme-ikev2-qr-alt-03.txt is now available. It is 
> a work
> item of the IP Security Maintenance and Extensions (IPSECME) WG of the IETF.
> 
>Title:   Mixing Preshared Keys in the IKE_INTERMEDIATE and in the
> CREATE_CHILD_SA Exchanges of IKEv2 for Post-quantum Security
>Author:  Valery Smyslov
>Name:draft-ietf-ipsecme-ikev2-qr-alt-03.txt
>Pages:   11
>Dates:   2024-07-26
> 
> Abstract:
> 
>An Internet Key Exchange protocol version 2 (IKEv2) extension defined
>in RFC8784 allows IPsec traffic to be protected against someone
>storing VPN communications today and decrypting it later, when (and
>if) cryptographically relevant quantum computers are available.  The
>protection is achieved by means of Post-quantum Preshared Key (PPK)
>which is mixed into the session keys calculation.  However, this
>protection doesn't cover an initial IKEv2 SA, which might be
>unacceptable in some scenarios.  This specification defines an
>alternative way to get protection against quantum computers, which is
>similar to the solution defined in RFC8784, but protects the initial
>IKEv2 SA too.
> 
>Besides, RFC8784 assumes that PPKs are static and thus they are only
>used when an initial IKEv2 Security Association (SA) is created.  If
>a fresh PPK is available before the IKE SA is expired, then the only
>way to use it is to delete the current IKE SA and create a new one
>from scratch, which is inefficient.  This specification also defines
>a way to use PPKs in active IKEv2 SA for creating additional IPsec
>SAs and for rekeys operations.
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-qr-alt/
> 
> There is also an HTMLized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-ikev2-qr-alt-03
> 
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-ipsecme-ikev2-qr-alt-03
> 
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
> 
> 
> ___
> IPsec mailing list -- ipsec@ietf.org
> To unsubscribe send an email to ipsec-le...@ietf.org

___
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org

[IPsec] Re: Review of draft-ietf-ipsecme-ikev2-qr-alt

[Valery Smyslov]

> > > This is not really correct. At the time it was seen that doing
> > > IKEv2 rekey immediately after IKE SA is created will solve this
> > > problem and it is already standardized how it can be done, so there
> > > was no need to make special case for those users who happen to use
> > > IKEv2 sending their propriatery data that needs protection.
> >
> > Besides proprietary data there are peers' identities that are
> > transmitted in IKE_AUTH and immediate rekey won't help protecting
> > them. If my memory serves me, the WG decided to sacrifice their
> > protection in favor of protocol simplicity, emphasizing that PPK is a
> > short-term solution until post-quantum KE methods are standardized.
> 
> Yes. And I do remember saying that there are ways to protect them with
using
> pseudo ID metchanism if such is needed, and for other data we also saw
there was
> a ways to protect it if needed.

Anyway, those were only proposals.

> > This wouldn't solve the problem when sensitive data is transmitted in
> > IKE_AUTH (e.g. in G-IKEv2). The way to circumvent this with immediate
> > G-IKEv2 rekey is described in the G-IKEv2 draft and is really ugly.
> 
> I currently only on section 3.1 so I have not yet seen what is there, but
on the other
> hand g-ikev2 is one of those rare cases, that are not seen in the internet
regularly
> today :-)

Alas :-)

> > I don't think your proposed text is accurate. Immediate IKE SA rekey
> > wouldn't completely solve the problem (IKE_AUTH content would still be
> > vulnerable, including peers' identities).
> 
> Yes, but it was seen at the time that we do not need special protocol, as
there are
> ways to solve the issues other ways, so the text is accurate describing
what was
> happening at that time. This is the reason why original PPK did not do
what you do
> now.
> 
> > https://mailarchive.ietf.org/arch/msg/ipsec/saNRET_aNkITI5jQ46pOI2e-WG
> > 0/
> 
> And the discussion from this was that we decided to go on with the PPK as
defined
> now because we saw that immediately rekeying IKE SA would solve some
> problems, and using pseudonyms etc would solve identity problems.
> 
> Btw, people did not seem to care about identity protection so much, that
they
> would have written draft about how to do pseudonyms...

That's true.

> > I think that the current text better reflects the situation. I can
> > modify it a bit as follows:
> >
> >At the time this extension was being developed, it was a
> >consensus in the IPSECME WG that it is the IPsec traffic that
> >mostly needs to have such a protection. It was believed that
> >information transferred over IKE SA (including peers' identities)
> >is less important and extending the protection to also cover
> >initial IKE SA would require serious modifications to core IKEv2
> >protocol, that contradicted to one of the goals to minimize such
> >changes. It was also decided that immediate rekey of initial IKE
> >SA would add this protection to the new IKE SA (albeit it
> >wouldn't provide identity protection of the peers).
> 
> This seems to be correct, and I can accept that, except I can't accept
that spelling
> of IPsecME... :-) If you fix the spelling then that text is perfect.

I've been always thinking that only "IPSec" is a form
for which one would get punished by the chairs since Paul's H. chairing :-)
Nowadays even SEC ADs use "IPSECME" in their slides:
https://datatracker.ietf.org/meeting/120/materials/slides-120-saag-chair-sli
des
Perhaps let them know this is unacceptable? :-)

Kidding aside, I've changed to "IPsecME".

> > Changed to:
> >
> >Another issue with use of PPKs as it is defined in [RFC8784] is that
this
> >approach assumes that PPKs are static entities, which are changed
> >very infrequently.  For this reason PPKs are only used once - when an
> >initial IKE SA is established.  This restriction makes it difficult
> >to use PPKs as defined in [RFC8784] when they are changed relatively
> >frequently, for example as a result of Quantum Key Distribution
> >(QKD).
> >
> > I looked through the draft and I don't think we have to preface
> > [RFC8784] with its name in *all* cases - in most cases the context is
> > clear and it is referenced a lot of times.
> 
> I think you should remove the RFC8784 reference in most of case as instead
just
> talk old / previous etc PPK method. I consider everything that is inside
[] to be
> something that can be safely changed to [1] [2] [3] etc and the text still
needs to be
> readable. In your case it would not be in all cases. Thats why adding some
name in
> front of the [RFC12312] reference is important. Even if the RFC8721 is
used so
> many times in the draft, I still do not have that mapping in my head, so I
will use
> random RFC8751 instead of it...

I did my best to address this. Please check.

> > In this case additional checks should be performed to make sure that
> > only PPK_ID formats with confirmation are used for t

[IPsec] Re: I-D Action: draft-ietf-ipsecme-ikev2-qr-alt-02.txt

[Valery Smyslov]

Hi,

this version addresses Tero's review.

Regards,
Valery.

> -Original Message-
> From: internet-dra...@ietf.org 
> Sent: Thursday, July 25, 2024 5:02 PM
> To: i-d-annou...@ietf.org
> Cc: ipsec@ietf.org
> Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-qr-alt-02.txt
> 
> Internet-Draft draft-ietf-ipsecme-ikev2-qr-alt-02.txt is now available. It is 
> a work
> item of the IP Security Maintenance and Extensions (IPSECME) WG of the IETF.
> 
>Title:   Alternative Approach for Mixing Preshared Keys in IKEv2 for Post-
> quantum Security
>Author:  Valery Smyslov
>Name:draft-ietf-ipsecme-ikev2-qr-alt-02.txt
>Pages:   11
>Dates:   2024-07-25
> 
> Abstract:
> 
>An Internet Key Exchange protocol version 2 (IKEv2) extension defined
>in RFC8784 allows IPsec traffic to be protected against someone
>storing VPN communications today and decrypting it later, when (and
>if) cryptographically relevant quantum computers are available.  The
>protection is achieved by means of Post-quantum Preshared Key (PPK)
>which is mixed into the session keys calculation.  However, this
>protection doesn't cover an initial IKEv2 SA, which might be
>unacceptable in some scenarios.  This specification defines an
>alternative way to get protection against quantum computers, which is
>similar to the solution defined in RFC8784, but protects the initial
>IKEv2 SA too.
> 
>Besides, RFC8784 assumes that PPKs are static and thus they are only
>used when an initial IKEv2 Security Association (SA) is created.  If
>a fresh PPK is available before the IKE SA is expired, then the only
>way to use it is to delete the current IKE SA and create a new one
>from scratch, which is inefficient.  This specification also defines
>a way to use PPKs in active IKEv2 SA for creating additional IPsec
>SAs and for rekeys operations.
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-qr-alt/
> 
> There is also an HTMLized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-ikev2-qr-alt-02
> 
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-ipsecme-ikev2-qr-alt-02
> 
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
> 
> 
> ___
> IPsec mailing list -- ipsec@ietf.org
> To unsubscribe send an email to ipsec-le...@ietf.org

___
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org

[IPsec] Re: Review of draft-ietf-ipsecme-ikev2-qr-alt

[Valery Smyslov]

Hi Tero,

thank you for your review. Please see inline.

> When checking whether this document is ready for WGLC I did quick review of 
> it.
> Here are my comments:
> 
> --
> 1.  Introduction
> ...
>[RFC8784] defines an IKEv2 extension for protecting
>today's IPsec traffic against future quantum computers.
> 
> When referencing to numbers always use the "name" of the document and only
> add RFC number as a reference. This will help readers to read the document,
> when they do not need to keep mapping from RFC number to name of the
> document in their head.
> 
> I.e., change to:
> 
>Mixing PPKs in the IKEv2 for post-quantum security [RFC8784]
>defines an IKEv2 extension for protecting today's IPsec traffic
>against future quantum computers.

Changed to

   Extension to IKEv2 for mixing preshared keys for post-
   quantum security defined in [RFC8784] allows today's IPsec traffic to
   be protected against future quantum computers.

> --
> 1.  Introduction
> 
> 
>   At the time
>this extension was being developed, it was a consensus in the IPSECME
>WG that only IPsec traffic needs to have such a protection.  It was
>believed that no sensitive information is transferred over IKE SA and
>extending the protection to also cover IKE SA traffic would require
>serious modifications to core IKEv2 protocol, that contradicted to
>one of the goals to minimize such changes.
> 
> This is not really correct. At the time it was seen that doing IKEv2 rekey
> immediately after IKE SA is created will solve this problem and it is already
> standardized how it can be done, so there was no need to make special case for
> those users who happen to use IKEv2 sending their propriatery data that needs
> protection.

Besides proprietary data there are peers' identities that are transmitted in 
IKE_AUTH
and immediate rekey won't help protecting them.
If my memory serves me, the WG decided to sacrifice their protection
in favor of protocol simplicity, emphasizing that PPK is 
a short-term solution until post-quantum KE methods are standardized.

https://mailarchive.ietf.org/arch/msg/ipsec/Mjp2picLCfy8zhb9g3XebmbvekM/

> I still think adding special mode for those rare use cases will just cause 
> more
> problems than what it solves. If the users who required this would simply have
> added few lines to their code to use childless initial SA (RFC6023) and then
> immediately trigger standard IKE SA rekey they could have been protected since
> PPK rfc was published.

This wouldn't solve the problem when sensitive data is transmitted in IKE_AUTH
(e.g. in G-IKEv2). The way to circumvent this with immediate G-IKEv2 rekey
is described in the G-IKEv2 draft and is really ugly.

> More correct way of saying this would be:
> 
>   At the time of this extension was developed it was a consensus that
>   doing the IKE SA rekey immediately after IKE SA is created would
>   provide protection for the IKE SA itself and solve the situations
>   where sensitive information would be transferred over IKE SA. It was
>   considered that special protocol just for that was not needed, as
>   there was already existing standard way to achieve same result.

I don't think your proposed text is accurate. Immediate IKE SA rekey
wouldn't completely solve the problem (IKE_AUTH content would
still be vulnerable, including peers' identities).

https://mailarchive.ietf.org/arch/msg/ipsec/saNRET_aNkITI5jQ46pOI2e-WG0/

I think that the current text better reflects the situation. I can modify it a 
bit as follows:

   At the time this
   extension was being developed, it was a consensus in the IPSECME WG
   that it is the IPsec traffic that mostly needs to have such a
   protection.  It was believed that information transferred over IKE SA
   (including peers' identities) is less important and extending the
   protection to also cover initial IKE SA would require serious
   modifications to core IKEv2 protocol, that contradicted to one of the
   goals to minimize such changes.  It was also decided that immediate
   rekey of initial IKE SA would add this protection to the new IKE SA
   (albeit it wouldn't provide identity protection of the peers).
 
> Now, when we already have IKE_INTERMEDIATE that means we do not need
> another special exchange, and can use it, so making this method now is easier.

> --
> 
>Since [RFC8784] was written, a new IKE_INTERMEDIATE exchange for
>IKEv2 was defined in [RFC9242].  While the primary motivation for
>developing this exchange was to allow multiple key exchanges to be
>used in IKEv2 (which is defined in [RFC9370]), the IKE_INTERMEDIATE
>exchange itself can be used for other purposes too.
> 
> Expand the names of the RFCs in this paragraph too.

Changed to:

   Some time after the protocol extension for mixing preshared keys in IKEv2 
for post-
   quantum sec

[IPsec] Re: draft-ietf-ipsecme-g-ikev2, public implementation availability query

[Valery Smyslov]

Hi Steffen,

 

I'm going to implement it in our IPsec product, but it is not public
implementation.

Perhaps strongswan or libreswan will implement it too, but I don't know.

 

Regards,

Valery.

 

Regards,

Valery.

 

From: Fries, Steffen  
Sent: Tuesday, July 23, 2024 7:39 PM
To: Valery Smyslov ; ipsec@ietf.org
Subject: RE: [IPsec] Re: draft-ietf-ipsecme-g-ikev2, public implementation
availability query

 

Hi Valery,

 

Thank you for the update. Is there any intention to provide an
implementation?

 

Best regards

Steffen

 

From: Valery Smyslov mailto:smyslov.i...@gmail.com>
> 
Sent: Tuesday, July 16, 2024 9:51 AM
To: Fries, Steffen (T CST) mailto:steffen.fr...@siemens.com> >; ipsec@ietf.org <mailto:ipsec@ietf.org>

Subject: RE: [IPsec] Re: draft-ietf-ipsecme-g-ikev2, public implementation
availability query

 

Hi Steffen,

 

Hi Valery, hi Brian, 

 

I just wanted to restate my question if you are aware of a potential
implementation of G-IKEv2, which is publicly available and which we could
use for further investigation regarding extendibility?

I found information about a minimal implementation in the WG slides of
IETF-99
(https://www.ietf.org/proceedings/99/slides/slides-99-ipsecme-minimal-g-ikev
2-implementation-01.pdf) but could not find an associated project. There is
one related project on gihub (https://github.com/krizki/Group-IKEv2), but
the last change was 7 years ago, so it does not look like being maintained. 

 

To my best knowledge there are no implementations of the current version of
the draft.

 Your findings are concerned with the older versions.

 

 Regards,

 Valery.

 

Any hint in that respect is appreciated.

 

Best regards

Steffen

 

From: IPsec mailto:ipsec-boun...@ietf.org> > On
Behalf Of Fries, Steffen
Sent: Friday, April 12, 2024 6:09 PM
To: ipsec@ietf.org <mailto:ipsec@ietf.org> 
Subject: [IPsec] draft-ietf-ipsecme-g-ikev2, public implementation
availability query

 

Hi Valery, hi Brian, 

 

While looking at the latest version of draft-ietf-ipsecme-g-ikev2, I was
wondering if a public implementation is available? It would be interesting
to have a look at the implementation to get a better impression regarding
the take over of enhancements done for GDOI into G-IKE-v2. 

 

Bets regards

Steffen

--
Steffen Fries

 

___
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org

[IPsec] Re: draft-smyslov-ipsecme-ikev2-qr-alt update

[Valery Smyslov]

Hi Paul,

as author I fully agree that the document is ready for WGLC. Actually,
that's what I said at the meeting.
Thank you for repeating this in the ML (it was too late for me to do it
myself yesterday).

Regards,
Valery.

> Hi,
> 
> Valery and Vukasin worked on interop testing a few weeks ago of draft-
> smyslov-ipsecme-ikev2-qr-alt-09 and after some code fixes on both
> implementations we got successful interop on the success and failure
paths.
> 
> We believe this document is ready for WGLC
> 
> Paul

___
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org

[IPsec] Re: The ESP Echo Protocol document for IPsecME

[Valery Smyslov]

Hi,

 

thank you for providing use cases in the new version of the draft.

I still have some questions about the intended use of the ESP Ping protocol.

 

I understand from the draft that one of the use cases is a manual check

for ESP connectivity by network operators. This use case is clear for me.

 

The unclear part is how the ESP Ping is intended to be used for IPsec SA 
establishment process.

Should it always be initiated before starting IKE? Should it be periodically 
initiated 

after the ESP SA is established to check for the network connectivity change?

What about MOBIKE – should it be initiated before MOBIKE starts changing IP 
addresses?

These all is not clear from the draft.

 

My another concern is that the draft seems to confirm my suspicions that 

the usefulness of this protocol is limited. After reading the draft it seems 
that

the algorithm for establishing IPsec SA is as follows:

 

1. Send ESP Echo Request

2. If ESP Echo Reply is received, start IKE

3. If no ESP Echo Reply is received start IKE (*) 

 

(*) possibly with UDP encapsulation, or without it.

 

So, the draft says that you SHOULD start creating ESP regardless of the result 
of ESP Ping.

Thus, why to delay SA establishment (you should wait for some time for the 
response) with ESP Ping?

 

Perhaps the better alternative would be to use mechanism described in 

draft-antony-ipsecme-encrypted-esp-ping in combination with ESP-in-UDP 
encapsulation. 

The peers can establish ESP with forced UDP encapsulation (regardless of the 
presence of NAT) 

and then immediately start encrypted ESP ping on the established ESP SA with no 
UDP encapsulation. 

If it succeeds, then the peers continue to use this ESP SA with no UDP 
encapsulation,

if not – with it. Note, that RFC 7296 requires that if UDP encapsulation is 
negotiated,

then peers are free to either use it or not (even on per-packet basis), unless 
NAT is detected.

 

Regards,

Valery.

 

 

 

 

From: Yoav Nir  
Sent: Tuesday, June 11, 2024 7:44 AM
To: ipsec 
Cc: Jen Linkova 
Subject: [IPsec] The ESP Echo Protocol document for IPsecME

 

Hi, folks

 

At IETF 119, Jen Likova presented [1] the ESP Echo Protocol draft [2].

 

The conversation in the room was lively, but did not look like the kind of 
consensus that we just confirm on the list.

 

So rather than starting an adoption call now, we’d like to encourage people to 
discuss it on the list, to see if we are approaching such a consensus.

 

Regards,

 

Yoav on behalf of the chairs

 

[1] https://youtu.be/n-yH3jtQmdQ?t=1205  (presentation starts at the 20:10 mark)

[2] https://datatracker.ietf.org/doc/draft-colitti-ipsecme-esp-ping/

___
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org

[IPsec] Re: draft-ietf-ipsecme-g-ikev2, public implementation availability query

[Valery Smyslov]

Hi Steffen,

 

Hi Valery, hi Brian, 

 

I just wanted to restate my question if you are aware of a potential
implementation of G-IKEv2, which is publicly available and which we could
use for further investigation regarding extendibility?

I found information about a minimal implementation in the WG slides of
IETF-99
(https://www.ietf.org/proceedings/99/slides/slides-99-ipsecme-minimal-g-ikev
2-implementation-01.pdf) but could not find an associated project. There is
one related project on gihub (https://github.com/krizki/Group-IKEv2), but
the last change was 7 years ago, so it does not look like being maintained. 

 

To my best knowledge there are no implementations of the current version of
the draft.

 Your findings are concerned with the older versions.

 

 Regards,

 Valery.

 

Any hint in that respect is appreciated.

 

Best regards

Steffen

 

From: IPsec mailto:ipsec-boun...@ietf.org> > On
Behalf Of Fries, Steffen
Sent: Friday, April 12, 2024 6:09 PM
To: ipsec@ietf.org  
Subject: [IPsec] draft-ietf-ipsecme-g-ikev2, public implementation
availability query

 

Hi Valery, hi Brian, 

 

While looking at the latest version of draft-ietf-ipsecme-g-ikev2, I was
wondering if a public implementation is available? It would be interesting
to have a look at the implementation to get a better impression regarding
the take over of enhancements done for GDOI into G-IKE-v2. 

 

Bets regards

Steffen

--
Steffen Fries

 

___
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org

[IPsec] Re: I-D Action: draft-ietf-ipsecme-ikev2-qr-alt-01.txt

[Valery Smyslov]

Hi,

this version contains the clarification for using PPKs in CREATE_CHILD_SA
(based on discussion with Vukašin).

Regards,
Valery.

> -Original Message-
> From: internet-dra...@ietf.org 
> Sent: Monday, July 1, 2024 11:20 AM
> To: i-d-annou...@ietf.org
> Cc: ipsec@ietf.org
> Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-qr-alt-01.txt
> 
> Internet-Draft draft-ietf-ipsecme-ikev2-qr-alt-01.txt is now available. It is 
> a work
> item of the IP Security Maintenance and Extensions (IPSECME) WG of the IETF.
> 
>Title:   Alternative Approach for Mixing Preshared Keys in IKEv2 for Post-
> quantum Security
>Author:  Valery Smyslov
>Name:draft-ietf-ipsecme-ikev2-qr-alt-01.txt
>Pages:   11
>Dates:   2024-07-01
> 
> Abstract:
> 
>An Internet Key Exchange protocol version 2 (IKEv2) extension defined
>in RFC8784 allows IPsec traffic to be protected against someone
>storing VPN communications today and decrypting it later, when (and
>if) cryptographically relevant quantum computers are available.  The
>protection is achieved by means of Post-quantum Preshared Key (PPK)
>which is mixed into the session keys calculation.  However, this
>protection doesn't cover an initial IKEv2 SA, which might be
>unacceptable in some scenarios.  This specification defines an
>alternative way to get protection against quantum computers, which is
>similar to the solution defined in RFC8784, but protects the initial
>IKEv2 SA too.
> 
>Besides, RFC8784 assumes that PPKs are static and thus they are only
>used when an initial IKEv2 Security Association (SA) is created.  If
>a fresh PPK is available before the IKE SA is expired, then the only
>way to use it is to delete the current IKE SA and create a new one
>from scratch, which is inefficient.  This specification also defines
>a way to use PPKs in active IKEv2 SA for creating additional IPsec
>SAs and for rekeys operations.
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-qr-alt/
> 
> There is also an HTMLized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-ikev2-qr-alt-01
> 
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-ipsecme-ikev2-qr-alt-01
> 
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
> 
> 
> ___
> IPsec mailing list -- ipsec@ietf.org
> To unsubscribe send an email to ipsec-le...@ietf.org

___
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org

[IPsec] Re: Clarification questions about Intended behavior draft-ietf-ipsecme-ikev2-qr-alt-00

[Valery Smyslov]

Hi Vukašin,

 

Hi Valery,

 

While updating the code logic to the latest version of the draft some questions 
came up to me: 

 

1. Assume the initiator and responder both already support RFC 8784.

If the initiator sends USE_PPK_ALT notify, and does not support 
IKE_INTERMEDIATE exchange, will the initiator and responder be able to use the 
alternative PPK rotation for rekeying the SA's and creating new PPK-protected 
SA's?

 

That is, can this alternative approach be used independent of the 
IKE_INTERMEDIATE exchange support?

 

A sentence in the draft "The initiator that supports both RFC8784 and this 
specification MAY include both the USE_PPK_ALT (along with the 
INTERMEDIATE_EXCHANGE_SUPPORTED) and the USE_PPK notifications if it is 
configured to use either specification." makes me think the alternative 
approach, thus also the PPK rotation and rekeying, must be used only if the 
INTERMEDIATE exchange occurs.

 

2. Similarly, assume neither the initiator nor the responder support RFC 8784 
and INTERMEDIATE exchange. Can they implement the alternative approach and use 
it for, e.g. rekeying (and adding PPK protection to the original unprotected 
IKE SA) and creating new PPK-protected SA's?

 

 The current draft assumes that alternative use of PPK is only possible 
if peers support the IKE_INTERMEDIATE exchange:

 

The IKE initiator which supports the IKE_INTERMEDIATE exchange and

 wants to use PPK to protect initial IKE SA includes the

 INTERMEDIATE_EXCHANGE_SUPPORTED notification and a notification of

   type USE_PPK_ALT in the IKE_SA_INIT request.

 

 Thus, peers may only negotiate support for the alternative approach if 
they also support IKE_INTERMEDIATE.

 

 However, the situation with the CREATE_CHILD_SA exchange is a bit 
trickier.

 Actually, the initiator may include PPK_IDENTITY_KEY notification in 
this exchange 

 even if it didn’t negotiate the support for this extension in the 
IKE_SA_INIT.

 In this case, if the responder doesn’t support use of PPKs in 
CREATE_CHILD_SA

 (even if it supports use PPKS in the initial exchange) or is 
configured to tie

 these two cases (don’t use it in CREATE_CHILD_SA unless negotiation is 
successful in IKE_SA_INIT),

 then the responder will ignore this notification and the SA will be 
created with no PPK.

 This may also happen even if the responder supports use of PPKs in 
CREATE_CHILD_SA,

 but for any reason cannot use them right now, e.g. no proposed PPKs 
are available.

 

The two situations may look unrealistic, but clarity on the issues would be 
better for cleaner code logic. I suggest a sentence or two are added somewhere 
(with MUST, SHOULD, etc. wording) that would clarify how implementations should 
behave in the above two situations. In the case I missed something in the draft 
about this, I apologize.

 

 I think some clarification may be added, that the use of PPKs in 
CREATE_CHILD_SA

 is somewhat independent from initial exchanges, however, the initiator 
must be prepared

 to the situation, when the responder doesn’t support this 
functionality or refuses to use it.

 

 Any thoughts whether this approach is OK?

 

 Regards,

 Valery.

 

Thank you in advance!

 

Regards,

Vukašin

___
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org

[IPsec] Review of draft-ietf-ipsecme-ikev2-sa-ts-payloads-opt

[Valery Smyslov]

Hi,

I reviewed draft-ietf-ipsecme-ikev2-sa-ts-payloads-opt.
The document is in a good shape, however it has some issues that need to be
fixed.

1. Section 3. 

   To indicate support for the optimized rekey negotiation, the
   initiator includes the OPTIMIZED_REKEY_SUPPORTED notify payload in
   the IKE_AUTH exchange request.  If multiple IKE_AUTH exchanges are
   sent, the OPTIMIZED_REKEY_SUPPORTED notify payload should be in the
   last IKE_AUTH exchange, which is the exchange that also contains the
   TS payloads.

This is not correct, If multiple IKE_AUTH exchanges take place,
then TS payloads are in the very _first_ IKE_AUTH request and 
in the very _last_ IKE_AUTH response. See Section 2.16 of RFC 7296, 
Section 4 of RFC 6467 and Section 2 of RFC 4739.

2. Section 6.2

   The Critical bit MUST be 1.  A value of 0 MUST be ignored.

This is wrong. The Critical bit refers to the Payload Type and not to the
payload content. 
In this case the type of payload is Notify Payload, that was defined in RFC
7296. 
And all payloads types defined in RFC 7296 must not have the Critical bit
set.

3. Section 6.1.

   The Critical bit MUST be 0.  A non-zero value MUST be ignored.

While this is correct, the requirement is already present in RFC 7296
(Section 3.2),
and I see no need to repeat it here. This is a generic rule of payload
processing in IKEv2 
and the optimized rekey extension doesn't change it, so no need to repeat.

4. Section 6.2

The format of the OPTIMIZED_REKEY notification makes use of 
Protocol ID, SPI Size and SPI fields of the Notify Payload to specify 
SPI of the new (not yet created) SA. This use contradicts RFC 7296.
Section 3.10 of RFC 7296 says:

   o  Protocol ID (1 octet) - If this notification concerns an existing
  SA whose SPI is given in the SPI field, this field indicates the
  type of that SA.  

Note, that these fields are concerned with _existing_ SA,
which is not the case for the OPTIMIZED_REKEY notification.
I propose to leave SPI fields empty, set both Protocol ID and SPI Size to
zero
and move the SPI for the new SA to the Notification Data.
Note, that there is no ambiguity as to what protocol (AH or ESP) this new
SPI 
should be used with, since the REKEY_SA notification contains this
information.

Regards,
Valery.



___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-auth-announce-10.txt

[Valery Smyslov]

Hi,

this version of the draft addresses comments made during IESG evaluation.

Regards,
Valery.

> Internet-Draft draft-ietf-ipsecme-ikev2-auth-announce-10.txt is now
available.
> It is a work item of the IP Security Maintenance and Extensions (IPSECME)
WG of
> the IETF.
> 
>Title:   Announcing Supported Authentication Methods in IKEv2
>    Author:  Valery Smyslov
>Name:draft-ietf-ipsecme-ikev2-auth-announce-10.txt
>Pages:   14
>Dates:   2024-04-18
> 
> Abstract:
> 
>This specification defines a mechanism that allows the Internet Key
>Exchange version 2 (IKEv2) implementations to indicate the list of
>supported authentication methods to their peers while establishing
>IKEv2 Security Association (SA).  This mechanism improves
>interoperability when IKEv2 partners are configured with multiple
>credentials of different type to authenticate each other.
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-auth-announce/
> 
> There is also an HTMLized version available at:
>
https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-ikev2-auth-announce
-10
> 
> A diff from the previous version is available at:
>
https://author-tools.ietf.org/iddiff?url2=draft-ietf-ipsecme-ikev2-auth-anno
unce-10
> 
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
> 
> 
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Murray Kucherawy's No Objection on draft-ietf-ipsecme-ikev2-auth-announce-09: (with COMMENT)

[Valery Smyslov]

Hi Murray,

> Murray Kucherawy has entered the following ballot position for
> draft-ietf-ipsecme-ikev2-auth-announce-09: No Objection
> 
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
> 
> 
> Please refer to 
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-
> positions/
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-auth-announce/
> 
> 
> 
> --
> COMMENT:
> --
> 
> The shepherd writeup says there are implementers, but no implementations.  Is
> that right?

Yes, that's right. We are in the process of implementing it.

Regards,
Valery.

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Paul Wouters' Yes on draft-ietf-ipsecme-ikev2-auth-announce-09: (with COMMENT)

[Valery Smyslov]

Hi Paul,

> >> Note that the IANA registry involved here was renamed since the
> >> latest draft was written :)
> >>
> >> Notify Message Type  -> Notify Message Status Type
> >>
> >> "IKEv2 Notify Message Types - Status Types" -> IKEv2 Notify Message
> >> Status Type
> >
> > This is already fixed in my local copy (the IANA was so kind to remind
> > me about this change in a personal message :-))
> 
> Good :)
> 
> >
> >> I wonder if it would make sense to somewhere explain that the
> >> authentication method refers to the AUTH payload,
> >
> > Hmm... I'm not sure where to put this clarification and in which form.
> > I think that there is a chance of over-specification, that might add 
> > confusion.
> > You are talking only about signature authentication, and besides that
> > we have PSK. In addition, IKEv2 doesn't require peer ID to match
> > X.509 identity, since they are linked via the local security policy
> > (i.e., it is the policy, which specify which IDs are acceptable and
> > which X.509 identities they correspond to, so the strict matching of
> > them is just a one particular case).
> >
> > If think that this is a real concern, then do you have any concrete text in 
> > mind?
> 
> Maybe somewhere say it is the “authentication method used for the AUTH
> payload”.

OK, then how about (Section 3):

CURRENT:
   The receiving party may take this
   information into consideration when selecting an algorithm for its
   authentication if several alternatives are available.

NEW:
   The receiving party may take this
   information into consideration when selecting an algorithm for its
   authentication (i.e., the algorithm used for calculation of the AUTH
   payload) if several alternatives are available.

Does this help?

Regards,
Valery.

> Paul=

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Paul Wouters' Yes on draft-ietf-ipsecme-ikev2-auth-announce-09: (with COMMENT)

[Valery Smyslov]

HI Paul,

thank you for your comments, please see inline.

> Paul Wouters has entered the following ballot position for
> draft-ietf-ipsecme-ikev2-auth-announce-09: Yes
> 
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
> 
> 
> Please refer to 
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-
> positions/
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-auth-announce/
> 
> 
> 
> --
> COMMENT:
> --
> 
> Note that the IANA registry involved here was renamed since the latest draft
> was written :)
> 
> Notify Message Type  -> Notify Message Status Type
> 
> "IKEv2 Notify Message Types - Status Types" -> IKEv2 Notify Message Status
> Type

This is already fixed in my local copy (the IANA was so kind to remind me about 
this change in a personal message :-))

> I wonder if it would make sense to somewhere explain that the authentication
> method refers to the AUTH payload, but that a separate peer ID check with its
> X.509 identity might need to be done, for which the CA cert that signed the EE
> cert could be using a different signature method? For example, the EE-cert
> could be using RSA-v1.5 while the AUTH payload could be using RSA-PSS. Or in
> some other way explain that peer ID proof checking is not "authentication" as
> used in this document?

Hmm... I'm not sure where to put this clarification and in which form.
I think that there is a chance of over-specification, that might add confusion.
You are talking only about signature authentication, and besides that
we have PSK. In addition, IKEv2 doesn't require peer ID to match 
X.509 identity, since they are linked via the local security policy
(i.e., it is the policy, which specify which IDs are acceptable and
which X.509 identities they correspond to, so the strict matching
of them is just a one particular case).
 
If think that this is a real concern, then do you have any concrete text in 
mind? 

Regards,
Valery.

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-qr-alt-00.txt

[Valery Smyslov]

Hi,

the name of the draft was changed to draft-ietf-ipsecme-...
No more changes.

Regards,
Valery.

> -Original Message-
> From: IPsec  On Behalf Of internet-dra...@ietf.org
> Sent: Tuesday, April 16, 2024 9:49 PM
> To: i-d-annou...@ietf.org
> Cc: ipsec@ietf.org
> Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-qr-alt-00.txt
> 
> Internet-Draft draft-ietf-ipsecme-ikev2-qr-alt-00.txt is now available. It
is a work
> item of the IP Security Maintenance and Extensions (IPSECME) WG of the
IETF.
> 
>Title:   Alternative Approach for Mixing Preshared Keys in IKEv2 for
Post-
> quantum Security
>Author:  Valery Smyslov
>Name:draft-ietf-ipsecme-ikev2-qr-alt-00.txt
>Pages:   11
>Dates:   2024-04-12
> 
> Abstract:
> 
>An Internet Key Exchange protocol version 2 (IKEv2) extension defined
>in RFC8784 allows IPsec traffic to be protected against someone
>storing VPN communications today and decrypting it later, when (and
>if) cryptographically relevant quantum computers are available.  The
>protection is achieved by means of Post-quantum Preshared Key (PPK)
>which is mixed into the session keys calculation.  However, this
>protection doesn't cover an initial IKEv2 SA, which might be
>unacceptable in some scenarios.  This specification defines an
>alternative way to get protection against quantum computers, which is
>similar to the solution defined in RFC8784, but protects the initial
>IKEv2 SA too.
> 
>Besides, RFC8784 assumes that PPKs are static and thus they are only
>used when an initial IKEv2 Security Association (SA) is created.  If
>a fresh PPK is available before the IKE SA is expired, then the only
>way to use it is to delete the current IKE SA and create a new one
>from scratch, which is inefficient.  This specification also defines
>a way to use PPKs in active IKEv2 SA for creating additional IPsec
>SAs and for rekeys operations.
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-qr-alt/
> 
> There is also an HTMLized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-ikev2-qr-alt-00
> 
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
> 
> 
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Éric Vyncke's No Objection on draft-ietf-ipsecme-ikev2-auth-announce-09: (with COMMENT)

[Valery Smyslov]

Hi Éric,

 

please see inline (I removed parts of the message where we are in
agreement).

 

Thank you, Valery, for your 2nd reply and for allowing me to reply w/o
on-line access to the I-D when I replied.

 

One last comment below as EVY2>

 

All comments were non-blocking anyway :)

 

-éric

 

[…]

> ## Section 3.1
> 
> `Regardless of whether the notification is received,` may be I am
mis-reading
> this, but why would the responder send the notification if the initiator
does
> not care anyway ?

The responder doesn't know if the initiator cares or not.
There is no negotiation of this feature, each party just makes its mind 
whether to send and whether to process this notification (if it is ever
supported). 

EVY> sure it will work like described in the I-D, but I find it really weird
that the initiator does not send its own list.

 In fact it does, but it sends this after the responder, in the
following exchange. So, the responder sends its list first.
 This is to have the announcements and the list of trust anchors (in
the CERTREQ payload) co-located in the same message.

 

EVY2> then this may be useful to write the above justification in the
document itself.

   I’ve added the following text in the Section 3:

To simplify
  the receiver's task of linking the announced authentication methods
  with the trust anchors, the protocol ensures that the
  SUPPORTED_AUTH_METHODS notification is always co-located with the
  CERTREQ payload in the same message.

   Does it help?

   Regards,
   Valery.


[…]

 

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Mahesh Jethanandani's No Objection on draft-ietf-ipsecme-ikev2-auth-announce-09: (with COMMENT)

[Valery Smyslov]

Hi Mahesh,

 

please, see inline.

 

HI Valery,

 

Thanks for responding to my comments. 

 

Some of these comments are generated by a tool we use, and as it says, you
should feel free to ignore them if they are not applicable. Please see
inline for the remaining.





On Apr 11, 2024, at 12:56 AM, Valery Smyslov mailto:s...@elvis.ru> > wrote:

 

Hi Mahesh,

thank you for your comments, please see inline.




Mahesh Jethanandani has entered the following ballot position for
draft-ietf-ipsecme-ikev2-auth-announce-09: No Objection

When responding, please keep the subject line intact and reply to all email
addresses included in the To and CC lines. (Feel free to cut this
introductory
paragraph, however.)


Please refer to
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-
positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-auth-announce/



--
COMMENT:
--

Thanks to Reese Enghardt for the General Area Review Team (Gen-ART) review
to Rifaat for the SECDIR review, and to Marc for the ARTART review.

Section 3.1, paragraph 14



  If the responder has sent any CERTREQ payload in the IKE_SA_INIT,
  then it MUST re-send the same payload(s) in the IKE_INTERMEDIATE
  response containing the SUPPORTED_AUTH_METHODS notification if any of
  the included Announcements has a non-zero Cert Link field (see
  Section 3.2.2 and Section 3.2.3).  This requirement allows peers to
  have a list of Announcements and a list of CAs in the same message,
  which simplifies their linking (note, that this requirement is always
  fulfilled for the IKE_SA_INIT and IKE_AUTH exchanges).  However, if
  for any reason the responder doesn't re-send CERTREQ payload(s) in
  the IKE_INTERMEDIATE exchange, then the initiator MUST NOT abort
  negotiation.  Instead, the initiator MAY either link the
  Announcements to the CAs received in the IKE_SA_INIT response, or MAY
  ignore the Announcements containing links to CAs.


I am a little puzzled by the MUST at the beginning of the paragraph which
insists that CERTREQ payload should be sent in IKE_INTERMEDIATE response
and
the MUST NOT/MAY at the bottom of the paragraph, which seems to be ok with
not
re-sending the CERTREQ payload. Is it possible that the CERTREQ payloads are
not re-send and at the same time they do not fit in IKE_SA_INIT (without
being
fragmented)?


Good point, thank you. We can s/MUST/SHOULD.

The idea is to make initiator's task of linking auth announcements to CAs
simpler,
by always having them in one message. On the other hand, responder may
have its own considerations about re-sending CERTREQ in the
IKE_INTERMEDIATE.




The IANA review of this document seems to not have concluded yet.


Hmm, from my understanding, the IANA has already reviewed the draft...

 

You are right. In most cases, IANA will take a look at the IANA
Considerations section, and say they understand the request. I on the other
hand, tend to err on the side of giving more information than less. For
example, in this case what does RFC refer to? A short note to the RFC
Editor (with another note to say please remove it before publication), would
inform them that RFC refers to the RFC number that will be assigned to
this document. 

 

 Well, I see your point, but do you think that the current text
would confuse the IANA and the RFC Editor?

 The current text is:

 

   This document defines a new Notify Message Type in the "IKEv2 Notify

   Message Status Types" registry referencing this RFC:

 

SUPPORTED_AUTH_METHODS[RFC]





  It seems to me that the current text is clear enough that RFC
is this RFC. 

 Do you think more instructions for the RFC Editor are needed?





No reference entries found for these items, which were mentioned in the
text:
[RFC].


I believe the RFC Editor will change  this to the appropriate value.




Possible DOWNREF from this Standards Track doc to [IKEV2-IANA]. If so, the
IESG
needs to approve it.


I think that referencing IANA registries is not a DOWNREF.

 

This is an example of the tool trying to figure out where is the reference
(possibly because of the square brackets). You can ignore it.


  OK.





Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

* Term "his"; alternatives might be "they", "them", "their"



Paul Wouters is definitely "he" :-)

 

Another case of the tool giving a false positive. But in general the

Re: [IPsec] Éric Vyncke's No Objection on draft-ietf-ipsecme-ikev2-auth-announce-09: (with COMMENT)

[Valery Smyslov]

Hi Éric,

 

please see inline.

 

Thank you, Valery, for the prompt reply.

 

See below for EVY>

 

Regards

 

-éric

 

From: Valery Smyslov mailto:s...@elvis.ru> >
Date: Thursday, 11 April 2024 at 15:23
To: Eric Vyncke (evyncke) mailto:evyn...@cisco.com> >,
'The IESG' mailto:i...@ietf.org> >
Cc: draft-ietf-ipsecme-ikev2-auth-annou...@ietf.org
<mailto:draft-ietf-ipsecme-ikev2-auth-annou...@ietf.org>
mailto:draft-ietf-ipsecme-ikev2-auth-annou...@ietf.org> >,
ipsecme-cha...@ietf.org <mailto:ipsecme-cha...@ietf.org>
mailto:ipsecme-cha...@ietf.org> >, ipsec@ietf.org
<mailto:ipsec@ietf.org>  mailto:ipsec@ietf.org> >,
kivi...@iki.fi <mailto:kivi...@iki.fi>  mailto:kivi...@iki.fi> >
Subject: RE: Éric Vyncke's No Objection on
draft-ietf-ipsecme-ikev2-auth-announce-09: (with COMMENT)

Hi Éric,

thank you for your comments, please see inline.

> Éric Vyncke has entered the following ballot position for
> draft-ietf-ipsecme-ikev2-auth-announce-09: No Objection
> 
> When responding, please keep the subject line intact and reply to all
email
> addresses included in the To and CC lines. (Feel free to cut this
introductory
> paragraph, however.)
> 
> 
> Please refer to
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-
> positions/
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-auth-announce/
> 
> 
> 
> --
> COMMENT:
> --
> 
> 
> # Éric Vyncke, INT AD, comments
fordraft-ietf-ipsecme-ikev2-auth-announce-09
> 
> Thank you for the work put into this document.
> 
> Please find below some non-blocking COMMENT points (but replies would be
> appreciated even if only for my own education), and some nits.
> 
> Special thanks to Tero Kivinen for the shepherd's detailed write-up
including
> the WG consensus and the justification of the intended status.
> 
> I hope that this review helps to improve the document,
> 
> Regards,
> 
> -éric
> 
> # COMMENTS (non-blocking)
> 
> ## Abstract
> 
> As the I-D is about authentication methods, I wonder whether `with
multiple
> different credentials` is the right wording, should it rather be
"different
> authentication methods" ? (of course with some text repetition).

I believe "different credentials" may include "different authentication
methods"?
There are may also be some subtleties. For example, consider the situation
when user has 2 certificates: RSA and ECDSA. In this case he/she has
different credentials, but from IKEv2 point of view, both use the same
authentication method, "Digital Signature", with different signature
algorithms.

I make the following change:
s/multiple different credentials/multiple credentials of different type

Is this better?

EVY> I think so

  Great!



> ## Section 3.1
> 
> `Regardless of whether the notification is received,` may be I am
mis-reading
> this, but why would the responder send the notification if the initiator
does
> not care anyway ?

The responder doesn't know if the initiator cares or not.
There is no negotiation of this feature, each party just makes its mind 
whether to send and whether to process this notification (if it is ever
supported). 

EVY> sure it will work like described in the I-D, but I find it really weird
that the initiator does not send its own list.

 In fact it does, but it sends this after the responder, in the
following exchange. So, the responder sends its list first.
 This is to have the announcements and the list of trust anchors (in
the CERTREQ payload) co-located in the same message.


> ## Section 3.2
> 
> While the readers may guess some details, but let's be clear in a proposed
> standard I-D:
> 
> 1) `Notification Data field` does not appear in figure 4
> 2) role of C flag and its value
> 3) value of Protocol ID
> 4) saying that reserved field must be set to 0 by sender and ignored on
the
> receiver

There is a reference to Section 3.10 of RFC 7296, which contains 
details of how a generic payload header should be filled in.
The Protocol ID and SPI Size values are defined in this document (zero).

 

EVY> I am off-line now so cannot check in the I-D whether the reference is
there. But, may I suggest to state somewhere that the fields C/protocol
id/reserved are specified in RFC 7296 ?

I think that since we explicitly reference the description of the Notify
Payload in RFC 7296, 
readers will be able to know how the generic payload header fields shoul

Re: [IPsec] Éric Vyncke's No Objection on draft-ietf-ipsecme-ikev2-auth-announce-09: (with COMMENT)

[Valery Smyslov]

Hi Éric,

thank you for your comments, please see inline.

> Éric Vyncke has entered the following ballot position for
> draft-ietf-ipsecme-ikev2-auth-announce-09: No Objection
> 
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
> 
> 
> Please refer to 
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-
> positions/
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-auth-announce/
> 
> 
> 
> --
> COMMENT:
> --
> 
> 
> # Éric Vyncke, INT AD, comments fordraft-ietf-ipsecme-ikev2-auth-announce-09
> 
> Thank you for the work put into this document.
> 
> Please find below some non-blocking COMMENT points (but replies would be
> appreciated even if only for my own education), and some nits.
> 
> Special thanks to Tero Kivinen for the shepherd's detailed write-up including
> the WG consensus and the justification of the intended status.
> 
> I hope that this review helps to improve the document,
> 
> Regards,
> 
> -éric
> 
> # COMMENTS (non-blocking)
> 
> ## Abstract
> 
> As the I-D is about authentication methods, I wonder whether `with multiple
> different credentials` is the right wording, should it rather be "different
> authentication methods" ? (of course with some text repetition).

I believe "different credentials" may include "different authentication 
methods"?
There are may also be some subtleties. For example, consider the situation
when user has 2 certificates: RSA and ECDSA. In this case he/she has
different credentials, but from IKEv2 point of view, both use the same
authentication method, "Digital Signature", with different signature algorithms.

I make the following change:
s/multiple different credentials/multiple credentials of different type

Is this better?

> ## Section 3.1
> 
> `Regardless of whether the notification is received,` may be I am mis-reading
> this, but why would the responder send the notification if the initiator does
> not care anyway ?

The responder doesn't know if the initiator cares or not.
There is no negotiation of this feature, each party just makes its mind 
whether to send and whether to process this notification (if it is ever 
supported). 

> ## Section 3.2
> 
> While the readers may guess some details, but let's be clear in a proposed
> standard I-D:
> 
> 1) `Notification Data field` does not appear in figure 4
> 2) role of C flag and its value
> 3) value of Protocol ID
> 4) saying that reserved field must be set to 0 by sender and ignored on the
> receiver

There is a reference to Section 3.10 of RFC 7296, which contains 
details of how a generic payload header should be filled in.
The Protocol ID and SPI Size values are defined in this document (zero).

What about 1), well, the "Notification Data" is the generic name
of this field in the Notify Payload. Its content depends on the type of the 
notify message.
I quickly scanned other RFCs which defined new notifications and they all
renamed the "Notification Data" to some name specific to the 
type of notification. So, to avoid confusion, I changed the text as follows:

s/The Notification Data field/ Notification data

Hope this eliminates the possible confusion.

> ## Section 3.2.1
> 
> Let's be crisp and specify that the length is in octets.

Done.

> Is there a registry for authentication method ? or should this specification 
> be
> updated for every new authentication method ?

https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-12

I hope no, but I cannot predict how IKEv2 would be tweaked in the future :-)

> # NITS (non-blocking / cosmetic)
> 
> ## Section 1
> 
> The last sentence of the 2nd paragraph is rather long and I think that "that"
> should be used in `the peer which supports wider range of`.

Thank you, I've been always mixing when to use "which" or "that" :-)

I changed s/which/that

> ## Section 3.2.1
> 
> Missing closing parenthesis in the last paragraph.

Fixed.

Regards,
Valery.


___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Mahesh Jethanandani's No Objection on draft-ietf-ipsecme-ikev2-auth-announce-09: (with COMMENT)

[Valery Smyslov]

Hi,

for some reason I didn't receive a message with comments from Gunter, but I 
noticed his comments at the ballot page
(it seems that the e-mail wasn't requested to be sent, as indicated in the 
datatracker).

I'm not sure if the message will be sent later and I want to respond to these 
comments, so I take the opportunity
to reply to the Mahesh's e-mail once again and comment on Gunter's comments :-)

First, thanks for these comments, I copy-pasted them from the datatracker. 
Plese, see inline.

> Document reviewed: draft-ietf-ipsecme-ikev2-auth-announce-09.txt
>
> Many thanks for this write-up. I see no issues from my side to progress this 
> document.
> During my review cycle i noted some observations that you may consider if you 
> find beneficial
>
> typos:
> s/overriden/overridden/

Fixed, thanks.

> [idnits] entries when runing idnits captured by shepherd review
>
> Review comments:
> 14   supported authentication methods to their peers while establishing
> 15   IKEv2 Security Association (SA).  This mechanism improves
>
> This draft is written for IKEv2, however would the proposed technology be 
> used potentially by newer IKE flavors?
> (as networking generalist i am unclear about dynamics of IKE evolutions). If 
> the IKEv2 is 'always' implicit 
> implied, then does it add value to mention IKEv2 here again? (i am ok with it 
> either way, only questioning the extra characters in the abstract)

I agree that using both 'IKE' and 'IKEv2' adds some confusion for readers, but 
this is a long habit in IPsec.
To the point - this draft is written for IKEv2 (we don't know what IKEv3 would 
look like),
so it is always implicitly implied. Sometimes it is also stated explicitly.

> 84   selecting authentication credentials.  The problem may arise when
> 85   there are several credentials of different types configured on one
> 86   peer, while only some of them are supported on the other peer.
>
> Not sure that saying "The problem" is accurate? there is added complexity or 
> credential 
> inconsistency, but by itself that is not a problem.
>
> What about this rewrite suggestion to nail this down: 
>
> "SA establishment failure between peers may arise when there are several 
> credentials of different types
> configured on one peer, while only some of them are supported on the other 
> peer."

I used this text, thank you.

> 116  When establishing IKE SA each party may send a list of authentication
> 117  methods it supports and is configured to use to its peer.  For this
>
> Here is mentioning of IKE and not IKEv2. was this intentional. Is there a 
> benefit in being consistent in terminology wrt IKE vs IKEv2?

As I said, there is a habit to mix 'IKE' and 'IKEv2' in IPsec world.

> 121  the party sending it.  The sending party may additionally specify
> 122  that some of the authentication methods are only for use with the
> 123  particular trust anchors.  Upon receiving this information the peer
>
> what does 'the' in the above phrase "**the** particular trust anchors" refer 
> towards? 
> (i am not so familiar with IKE so much, so am trying to understand how 
> SUPPORTED_AUTH_METHODS is correlated, and trust anchors was not mentioned 
> before. 
> (i do assume its well known terminology  though)

List of trust anchors are sent in the CERTREQ payload.
This extension allows to link each of the announced digital signature auth 
method with the particular
trust anchor (meaning that *this* algorithm should be used with *this* CA).

> 132  message.  This notification contains a list of authentication methods
> 133  supported by the responder, ordered by their preference.
>
> how is this correlating towards the trust anchor mentioned in above comment?

The order of preference is not correlated with the trust anchors.
The correlation is described above.

> 287  announcements for these methods.  Implementations MUST ignore
> 288  announcements which semantics they don't understand.
>
> s/which/with/

Changed to s/which/whose as Mahesh proposed.

> 390   4.  Interaction with IKE Extensions concerning Authentication
>
> is there a reason why IKE is mentioned instead of IKEv2 ?

Changed to 'IKEv2'.

Regards,
Valery.

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Mahesh Jethanandani's No Objection on draft-ietf-ipsecme-ikev2-auth-announce-09: (with COMMENT)

[Valery Smyslov]

Hi Mahesh,

thank you for your comments, please see inline.

> Mahesh Jethanandani has entered the following ballot position for
> draft-ietf-ipsecme-ikev2-auth-announce-09: No Objection
> 
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
> 
> 
> Please refer to 
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-
> positions/
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-auth-announce/
> 
> 
> 
> --
> COMMENT:
> --
> 
> Thanks to Reese Enghardt for the General Area Review Team (Gen-ART) review
> to Rifaat for the SECDIR review, and to Marc for the ARTART review.
> 
> Section 3.1, paragraph 14
> >If the responder has sent any CERTREQ payload in the IKE_SA_INIT,
> >then it MUST re-send the same payload(s) in the IKE_INTERMEDIATE
> >response containing the SUPPORTED_AUTH_METHODS notification if any of
> >the included Announcements has a non-zero Cert Link field (see
> >Section 3.2.2 and Section 3.2.3).  This requirement allows peers to
> >have a list of Announcements and a list of CAs in the same message,
> >which simplifies their linking (note, that this requirement is always
> >fulfilled for the IKE_SA_INIT and IKE_AUTH exchanges).  However, if
> >for any reason the responder doesn't re-send CERTREQ payload(s) in
> >the IKE_INTERMEDIATE exchange, then the initiator MUST NOT abort
> >negotiation.  Instead, the initiator MAY either link the
> >Announcements to the CAs received in the IKE_SA_INIT response, or MAY
> >ignore the Announcements containing links to CAs.
> 
> I am a little puzzled by the MUST at the beginning of the paragraph which
> insists that CERTREQ payload should be sent in IKE_INTERMEDIATE response
> and
> the MUST NOT/MAY at the bottom of the paragraph, which seems to be ok with
> not
> re-sending the CERTREQ payload. Is it possible that the CERTREQ payloads are
> not re-send and at the same time they do not fit in IKE_SA_INIT (without being
> fragmented)?

Good point, thank you. We can s/MUST/SHOULD.

The idea is to make initiator's task of linking auth announcements to CAs 
simpler,
by always having them in one message. On the other hand, responder may
have its own considerations about re-sending CERTREQ in the IKE_INTERMEDIATE.

> The IANA review of this document seems to not have concluded yet.

Hmm, from my understanding, the IANA has already reviewed the draft...

> No reference entries found for these items, which were mentioned in the text:
> [RFC].

I believe the RFC Editor will change  this to the appropriate value.

> Possible DOWNREF from this Standards Track doc to [IKEV2-IANA]. If so, the
> IESG
> needs to approve it.

I think that referencing IANA registries is not a DOWNREF.

> Found terminology that should be reviewed for inclusivity; see
> https://www.rfc-editor.org/part2/#inclusive_language for background and more
> guidance:
> 
>  * Term "his"; alternatives might be "they", "them", "their"


Paul Wouters is definitely "he" :-)

> ---
> NIT
> ---
> 
> All comments below are about very minor potential issues that you may choose 
> to
> address in some way - or ignore - as you see fit. Some were flagged by
> automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
> will likely be some false positives. There is no need to let me know what you
> did with these suggestions.
> 
> Section 1, paragraph 3
> 
> s/each peer uses/each peer use/

I think the current text is correct.

> Section 3, paragraph 1
> >particular trust anchors.  Upon receiving this information the peer
> >may take it into consideration while selecting an algorithm for its
> >authentication if several alternatives are available.
> 
> This sentence does not parse for me. When it says, "the peer may take it into
> consideration while ...", I seem to be missing what needs to be taken into
> consideration.

Perhaps:

NEW:

   The receiving party may take this information into consideration when 
selecting an algorithm for its
   authentication if several alternatives are available.

Is this better?

> Section 3.2, paragraph 6
> >If more authentication methods are defined in future, the
> >corresponding documents must describe the semantics of the
> >announcements for these methods.  Implementations MUST ignore
> >announcements which semantics they don't understand.
> 
> s/announcements which semantics/announcements 

Re: [IPsec] Orie Steele's No Objection on draft-ietf-ipsecme-ikev2-auth-announce-09: (with COMMENT)

[Valery Smyslov]

Hi Orie,

thank you for your comments, please see inline.

> Orie Steele has entered the following ballot position for
> draft-ietf-ipsecme-ikev2-auth-announce-09: No Objection
> 
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
> 
> 
> Please refer to 
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-
> positions/
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-auth-announce/
> 
> 
> 
> --
> COMMENT:
> --
> 
> # Orie Steele, ART AD, comments for draft-ietf-ipsecme-ikev2-auth-announce-09
> CC @OR13
> 
> https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-
> ipsecme-ikev2-auth-announce-09.txt&submitcheck=True
> 
> ## Comments
> 
> Thanks to Marc Blanchet for the ARTART review, and to Valery for addressing 
> his
> feedback.
> 
> ```
> 175  then the responder MAY choose not to send actual list of the
> 176  supported authentication methods in the IKE_SA_INIT exchange and
> 177  instead ask the initiator to start the IKE_INTERMEDIATE exchange for
> 178  the list to be sent in.
> ```
> 
> Why not "SHOULD not send..."?

Because we don't want to give one of the option more weight than the other.
The responder is free to act either way, since the possible issues with IP 
fragmentation 
are sometimes subtle and additional considerations can be evaluated by the 
responder.
With "SHOULD" the responder would have to almost always ask for 
IKE_INTERMEDIATE (since SHOULD is very close to MUST).

> ```
> 189  the SUPPORTED_AUTH_METHODS notification.  Otherwise, the initiator
> 190  MAY start the IKE_INTERMEDIATE exchange just for this sole purpose by
> 191  sending an empty IKE_INTERMEDIATE request.  The initiator MAY also
> 192  indicate its identity (and possibly the perceived responder's
> 193  identity too) by including the IDi payload (possibly along with the
> 194  IDr payload) into the IKE_INTERMEDIATE request.  This information
> 195  could help the responder to send back only those authentication
> 196  methods, that are configured to be used for authentication of this
> 197  particular initiator.  If these payloads are sent, they MUST be
> 198  identical to the IDi/IDr payloads sent later in the IKE_AUTH request.
> ```
> 
> Why not SHOULD instead of MAY?

For the same reason - to leave an initiator a freedom of choice.
For example, the initiator can be not interested in receiving 
the responder's list of supported auth methods (e.g., the initiator
itself may be able to authenticate itself with the only one method, 
thus no point to know that the responder supports more, thus
no point to waste a round trip). The same for the second "MAY" - 
the initiator may be not willing to send its identity in the 
IKE_INTERMEDIATE exchange for the same reason 
(in case the IKE_INTERMEDIATE is started anyway for some
other purposes).

Using "SHOULD" here would have left the initiator with less freedom of choice.

> ```
> 226  HDR, SAi1, KEi, Ni -->
> 227 <-- HDR, SAr1, KEr, Nr, [CERTREQ,]
> 228 [N(SUPPORTED_AUTH_METHODS)()]
> 
> 230  HDR, SK {..., [IDi, [IDr,]]}  -->
> 231 <-- HDR, SK {..., [CERTREQ,]
> 232 [N(SUPPORTED_AUTH_METHODS)(...)] }
> ```
> 
> Is the "()" vs "(...)" significant, or meant to indicate the empty 
> IKE_INTERMEDIATE
> ?
> What does "(...)" expand to?

"()" means an empty SUPPORTED_AUTH_METHODS notification,
while "(...)" means a non-empty one (containing some auth methods).

> ```
> 347  Signature" (1), "DSS Digital Signature" (3), "ECDSA with SHA-256 on
> 348  the P-256 curve" (9), "ECDSA with SHA-384 on the P-384 curve" (10)
> 349  and "ECDSA with SHA-512 on the P-512 curve" (11).  Note however, that
> 350  these authentication methods are currently superseded by the "Digital
> 351  Signature" (14) authentication method, which has a different
> ```
> 
> I think you mean P-521 curve, also known as secp521r1.

You are right, this is a typo. Fixed in my local copy, thank you.

> ## Nits
> 
> ```
> 531  This appendix shows some examples of announcing authentication
> 532  methods.  This appendix is purely informative; if it disagrees with
> 533  the body of this document, the other text is considered correct.
> ```
> 
> You will see errata filed either way...
> I recommend omitting the second sentence.

This is more or less standard text copied from other RFCs. 
See, for ex

Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-auth-announce-09.txt

[Valery Smyslov]

Hi,

this version clarifies the security considerations as per Reese's last
comment.

Regards,
Valery.

> Internet-Draft draft-ietf-ipsecme-ikev2-auth-announce-09.txt is now
available.
> It is a work item of the IP Security Maintenance and Extensions (IPSECME)
WG of
> the IETF.
> 
>Title:   Announcing Supported Authentication Methods in IKEv2
>Author:  Valery Smyslov
>Name:draft-ietf-ipsecme-ikev2-auth-announce-09.txt
>Pages:   13
>Dates:   2024-04-04
> 
> Abstract:
> 
>This specification defines a mechanism that allows the Internet Key
>Exchange version 2 (IKEv2) implementations to indicate the list of
>supported authentication methods to their peers while establishing
>IKEv2 Security Association (SA).  This mechanism improves
>interoperability when IKEv2 partners are configured with multiple
>different credentials to authenticate each other.
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-auth-announce/
> 
> There is also an HTMLized version available at:
>
https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-ikev2-auth-announce
-09
> 
> A diff from the previous version is available at:
>
https://author-tools.ietf.org/iddiff?url2=draft-ietf-ipsecme-ikev2-auth-anno
unce-09
> 
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
> 
> 
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] [***SPAM***] Re: Genart last call review of draft-ietf-ipsecme-ikev2-auth-announce-06

[Valery Smyslov]

Hi Reese,

I snipped most of the text for readability.

> Hi Valery,
> 
> Thank you for the response and updates.
> 
> Please see inline:

[...]
 
> >> Section 5:
> >>
> >> "Note, that this is not a real attack, since NULL authentication
> >> should be allowed by local security policy." Why is it not a real
> >> attack then? If NULL authentication is allowed among other methods,
> >> surely downgrading to NULL authentication is still a problem? Or
> >> should the second sentence instead say "NULL authentication should NOT be
> allowed by local security policy"?
> > There is no negotiation of the authentication method to be used in
> > IKEv2, thus this is not a "downgrade". If your local policy allows
> > peers to not authenticate on their discretion, then it is your choice.
> > If they use NULL authentication in this case, they don't violate your 
> > policy, thus
> this is not an real attack.
> 
> Thanks, that's a great clarification, I initially missed the "there is no 
> negotiation"
> part. Would you mind adding a sentence to the section, please?


I've rephrased the text as follows:

   Note, that this is not a real "downgrade"
   attack, since authentication methods in IKEv2 are not negotiated and
   in this case NULL authentication should be allowed by local security
   policy.

Is this OK?

Regards,
Valery.

> Best,
> Reese

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-auth-announce-08.txt

[Valery Smyslov]

Hi,

this version addresses Paul's comment on the imprecise wording used in the
-07.

Regards,
Valery.

> -Original Message-
> From: IPsec  On Behalf Of internet-dra...@ietf.org
> Sent: Tuesday, April 2, 2024 4:10 PM
> To: i-d-annou...@ietf.org
> Cc: ipsec@ietf.org
> Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-auth-announce-08.txt
> 
> Internet-Draft draft-ietf-ipsecme-ikev2-auth-announce-08.txt is now
available.
> It is a work item of the IP Security Maintenance and Extensions (IPSECME)
WG of
> the IETF.
> 
>Title:   Announcing Supported Authentication Methods in IKEv2
>Author:  Valery Smyslov
>Name:draft-ietf-ipsecme-ikev2-auth-announce-08.txt
>Pages:   13
>Dates:   2024-04-02
> 
> Abstract:
> 
>This specification defines a mechanism that allows the Internet Key
>Exchange version 2 (IKEv2) implementations to indicate the list of
>supported authentication methods to their peers while establishing
>IKEv2 Security Association (SA).  This mechanism improves
>interoperability when IKEv2 partners are configured with multiple
>different credentials to authenticate each other.
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-auth-announce/
> 
> There is also an HTMLized version available at:
>
https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-ikev2-auth-announce
-08
> 
> A diff from the previous version is available at:
>
https://author-tools.ietf.org/iddiff?url2=draft-ietf-ipsecme-ikev2-auth-anno
unce-08
> 
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
> 
> 
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Genart last call review of draft-ietf-ipsecme-ikev2-auth-announce-06

[Valery Smyslov]

Hi Paul,

 

On Mon, Apr 1, 2024 at 9:08 AM Valery Smyslov < <mailto:s...@elvis.ru> 
s...@elvis.ru> wrote:

 

I've added the following sentence to the Introduction:

   Since IKEv2 doesn't allow to use multiple
   authentication methods and doesn't provide means for peers to
   indicate to the other side which authentication methods they support,
   it is possible that in these situations the peer which supports wider
   range of authentication methods (or authentication token formats)
   improperly selects the method (or format) which is not supported by
   the other side.

 

I wouldn't phrase it like it, since if we are talking about the peers using 
different authentication

methods (eg client EAPTLS and server X.509 cert) then there are "multiple 
authentication methods".

 

Also, the server could have multiple configurations for the same peer so a peer 
could come in using X509 or PSK.

 

I think the core case is that the peers cannot dictate the auth method the peer 
must use. But this document allows

them to inform the peer or what they are going to allow? Although a bit limited 
because in IKE_SA_INIT, one does

not have the peer's identity yet, and different peers might only be allowed 
specific auth methods.

 

 I believe the issue Reese raised was: why we didn’t modify IKEv2 so 
that 

 each peer was able to try to authenticate with all auth methods it had 
credentials for – with signature(s), PSK etc.,

 and the SA would be established if at least one of these methods 
succeeded.

 

 I agree that the wording above is imperfect and imprecise. Perhaps:

 

   Since IKEv2 requires that each peer uses exactly one authentication method 

   and doesn't provide means for peers to
   indicate to the other side which authentication methods they support,
   it is possible that in these situations the peer which supports wider
   range of authentication methods (or authentication token formats)
   improperly selects the method (or format) which is not supported by
   the other side.

 

 This is still imprecise since with EAP the server actually 
authenticates itself with two methods.

 But perhaps we can leave with this? Or can you propose a better 
wording?

 

 Regards,

 Valery.

 

Paul

 

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Secdir last call review of draft-ietf-ipsecme-ikev2-auth-announce-06

[Valery Smyslov]

Hi Rifaat,

 

I snipped parts where we are in agreement.

 

Hi Valery,

 

See my replies below.

 

Regards,

 Rifaat

 

 

[…]

 

> * "Since the responder sends the SUPPORTED_AUTH_METHODS notification in
> the IKE_SA_INIT exchange, it must take care that the size of the response
> message wouldn't grow too much so that IP fragmentation takes place."
> 
> Is this limited to the responder? or should the initiator too take that into
> considerations?

It is not limited to the responder in general, but in the context of this 
document
it is the responder who is going to send a message that could be fragmented at 
IP level.
Usually the response is smaller than the request. In this case it can be larger
and thus the responder should take care of IP fragmentation.

 

Got it. 

I am assuming that the fragmentation issue with the initiator request is 
captured in a different document. 

If that is the case, then I think it is reasonable to leave this text as is.

 

 It is described in the IKE fragmentation document (RFC 7383).

 I’ve added a reference to it in the -07 version.

 

 

> # Section 5
> 
> Second paragraph: I guess the potential for downgrade attack is not limited 
> to the
> NULL use case. If one of the supported methods is consider to be weaker than 
> the
> others, then an active attacker in the path could force the parties to use 
> that
> weaker method.

This is not a "downgrade" in a common sense. Downgrade assumes that there 
is a negotiation between the peers and an attacker may influence this process 
forcing
peers to use weaker option. In IKEv2 authentication methods are not negotiated.
This specification doesn't provide negotiation too, since each party
still chooses what it thinks is appropriate on its own. It only allows peers
to select authentication method more consciously.

 

Thanks for the clarification, as I am not an IKE expert.

Having said that, I wonder why you are specifically calling out the NULL use 
case. 

Would not the NULL use case be also applicable to weaker authentication 
methods? 

Meaning that the attacker in the middle would be able to remove the stronger 
methods and leave the weaker ones?

 

 Yes, it is possible. NULL authentication is just the easiest way for 
an attacker to do it.

 I can add the following text in the Security Considerations (right 
after the NULL authentication discussion):

 

   Similarly, if an attacker on the path can break some of the announced

   authentication methods, then the attacker can encourage peers to use

   one of these weaker methods by removing all other announcements, and

if this succeeds, then impersonate one of the peers.

 

 Does this help?

 

 Regards,

 Valery.

 

 

Regards,

 Rifaat

 

 

Regards,
Valery.

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-auth-announce-07.txt

[Valery Smyslov]

Hi,

this version addresses comments received during IETF LC and directorate
reviews.

Regards,
Valery.

> -Original Message-
> From: IPsec  On Behalf Of internet-dra...@ietf.org
> Sent: Monday, April 1, 2024 4:41 PM
> To: i-d-annou...@ietf.org
> Cc: ipsec@ietf.org
> Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-auth-announce-07.txt
> 
> Internet-Draft draft-ietf-ipsecme-ikev2-auth-announce-07.txt is now
available.
> It is a work item of the IP Security Maintenance and Extensions (IPSECME)
WG of
> the IETF.
> 
>Title:   Announcing Supported Authentication Methods in IKEv2
>Author:  Valery Smyslov
>Name:draft-ietf-ipsecme-ikev2-auth-announce-07.txt
>Pages:   13
>Dates:   2024-04-01
> 
> Abstract:
> 
>This specification defines a mechanism that allows the Internet Key
>Exchange version 2 (IKEv2) implementations to indicate the list of
>supported authentication methods to their peers while establishing
>IKEv2 Security Association (SA).  This mechanism improves
>interoperability when IKEv2 partners are configured with multiple
>different credentials to authenticate each other.
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-auth-announce/
> 
> There is also an HTMLized version available at:
>
https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-ikev2-auth-announce
-07
> 
> A diff from the previous version is available at:
>
https://author-tools.ietf.org/iddiff?url2=draft-ietf-ipsecme-ikev2-auth-anno
unce-07
> 
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
> 
> 
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Secdir last call review of draft-ietf-ipsecme-ikev2-auth-announce-06

[Valery Smyslov]

Hi Rifaat,

thank you for your review. Please, see inline.

> Reviewer: Rifaat Shekh-Yusef
> Review result: Has Issues
> 
> # Section 3.1
> 
> * The description of the exchange seems odd, as it starts with the responder,
> instead of the initiator. I suggest that the description of the exchange 
> starts with
> the initiator, followed by the responder.

OK, I've added the following sentence:

The initiator starts the IKE_SA_INIT exchange as usual.

> * I think it would make it easier for the reader if you explicitly describe 
> the new
> notify payload. How about adding the following text to the beginning of 
> section 3.1?
> 
> "This specification introduces a new IKE_SA_INIT packets Notify payload of 
> type
> SUPPORTED_AUTH_METHODS. This payload is utilized to convey the supported
> authentication methods of the party sending the message, thereby facilitating 
> the
> negotiation of authentication mechanisms during IKE SA establishment."

Text in the Section 3 is changed to:

   When establishing IKE SA each party may send a list of authentication
   methods it supports and is configured to use to its peer.  For this
   purpose this specification introduces a new Notify Message Type
   SUPPORTED_AUTH_METHODS.  The Notify payload with this Notify Message
   Type is utilized to convey the supported authentication methods of
   the party sending it.  The sending party may additionally specify
   that some of the authentication methods are only for use with the
   particular trust anchors.  Upon receiving this information the peer
   may take it into consideration while selecting an algorithm for its
   authentication if several alternatives are available.

> * "Since the responder sends the SUPPORTED_AUTH_METHODS notification in
> the IKE_SA_INIT exchange, it must take care that the size of the response
> message wouldn't grow too much so that IP fragmentation takes place."
> 
> Is this limited to the responder? or should the initiator too take that into
> considerations?

It is not limited to the responder in general, but in the context of this 
document
it is the responder who is going to send a message that could be fragmented at 
IP level.
Usually the response is smaller than the request. In this case it can be larger
and thus the responder should take care of IP fragmentation.

> # Section 5
> 
> Second paragraph: I guess the potential for downgrade attack is not limited 
> to the
> NULL use case. If one of the supported methods is consider to be weaker than 
> the
> others, then an active attacker in the path could force the parties to use 
> that
> weaker method.

This is not a "downgrade" in a common sense. Downgrade assumes that there 
is a negotiation between the peers and an attacker may influence this process 
forcing
peers to use weaker option. In IKEv2 authentication methods are not negotiated.
This specification doesn't provide negotiation too, since each party
still chooses what it thinks is appropriate on its own. It only allows peers
to select authentication method more consciously.

Regards,
Valery.

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Genart last call review of draft-ietf-ipsecme-ikev2-auth-announce-06

[Valery Smyslov]

Hi Reese,

thank you for your review. Please see inline.

> Reviewer: Reese Enghardt
> Review result: Ready with Nits
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area Review
> Team (Gen-ART) reviews all IETF documents being processed by the IESG for the
> IETF Chair.  Please treat these comments just like any other last call 
> comments.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-ipsecme-ikev2-auth-announce-06
> Reviewer: Reese Enghardt
> Review Date: 2024-03-29
> IETF LC End Date: 2024-03-31
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary: The document is clear and concise, and it is ready for publication. I
> have a few minor suggestion to make the document more comprehensible to non-
> expert readers.
> 
> Major issues: None.
> 
> Minor issues:
> 
> Abstract:
> 
> As a non-expert reader, the following phrases appear to contradict each other:
> "indicate the list of supported authentication methods" sounds like different
> algorithms, "configured with multiple different credentials  to authenticate 
> each
> other" sounds like different certificates but potentially using the same 
> algorithm. If
> this proposal is most applicable to scenarios where IKEv2 partners use 
> different
> algorithms or methods, please consider saying so explicitly in the abstract.

I'm a bit confused here. My interpretation is that "different credentials" 
includes the situation 
when these credentials can only be used with specific authentication methods
(e.g., user may have a certificate and a PSK). So, I believe that the current 
text
is adequate, but as a non-native speaker I might have missed some nuances.
If this is the case, then can you propose a better wording?

> Section 1:
> 
> If there are several credentials, why not just try them one by one - is it 
> just
> performance reasons (key exchange takes longer), or is there another
> reason? 

This would be a major change in the protocol, which doesn't seem appropriate.
And yes, performance also matters.

> Please consider adding a sentence as additional motivation for this new
> mechanism.

I've added the following sentence to the Introduction:

   Since IKEv2 doesn't allow to use multiple
   authentication methods and doesn't provide means for peers to
   indicate to the other side which authentication methods they support,
   it is possible that in these situations the peer which supports wider
   range of authentication methods (or authentication token formats)
   improperly selects the method (or format) which is not supported by
   the other side.

> Section 3.1:
> 
> "it includes a new status type notify SUPPORTED_AUTH_METHODS in the
> IKE_SA_INIT response message" Have a hard time parsing this sentence. Is
> "notify" part of the name of the new status type? Please consider rephrasing 
> this
> sentence.

I've changed this to:

"it includes a new notification SUPPORTED_AUTH_METHODS in the IKE_SA_INIT 
response message".

Actually, the fact that the type of this notification is "status" (and not 
"error")
is pointed out in the IANA considerations section.

> "If the following conditions are met:"
> Either of the conditions or both of the conditions?

Changed to:

" If both of the following conditions are met:"

> "[…] then the responder may choose not to send actual list of the supported
> authentication methods in the IKE_SA_INIT exchange and instead ask the 
> initiator
> to start the IKE_INTERMEDIATE exchange for the list to be sent in" Is this a 
> MAY?
> Why is it not a MUST, as above it says "the responder […] must take care that 
> the
> size of the response message wouldn't grow too much so that IP fragmentation
> takes place"?

I agree that s/may/MAY may make sense here (done). But is definitely not MUST,
since there are a number of considerations that should be taken into.
Even if both conditions are met, the responder might have known for sure
that no IP fragmentation would take place (e.g. TCP transport is used)
or it is not an issue (e.g. provider's network doesn't drop IP fragmented UDP 
datagrams).
In these cases there is no point to do an additional round trip.

> Why does using the IKE_INTERMEDIATE exchange fix the problem of IP
> fragmentation? Please consider adding a brief explanation here.

Changed the text to:

   [...] then the responder MAY choose not to send actual list of the
   supported authentication methods in the IKE_SA_INIT exchange and
   instead ask the initiator to start the IKE_INTERMEDIATE exchange for
   the list to be sent in.  This would allow to use IKE fragmentation
   [RFC7383] for long messages (which cannot be used in the IKE_SA_INIT
   exchange), thus avoiding IP fragmentation.

> Section 5:
> 
> "Note, that this is not a real attack, since NULL authentication should be 
> allowed by
> local security policy." Why is it not a real attack then? If NULL 
> authentication is
> allowed among other me

Re: [IPsec] Artart last call review of draft-ietf-ipsecme-ikev2-auth-announce-06

[Valery Smyslov]

Hi Marc,

thank you for your review. 

> Reviewer: Marc Blanchet
> Review result: Ready with Nits
> 
> I'm the assigned ART reviewer for this document. While I'm aware of IPSEC-IKE
> and its use, I have no competency in this technology, therefore I have not 
> verified
> the substantive protocol specification itself.
> 
> Comment 1)
> The draft does not specify any fallback procedure or how to handle the 
> situation
> when no proper authentication  method can be chosen by one of the peers. Maybe
> it is specified elsewhere? Or maybe it is so obvious there is no point in 
> saying? Or
> it may be useful to specify some?

The draft doesn't change the auth method selection mechanism from IKEv2.
In particular - each party used whatever authentication method it thinks is 
appropriate to authenticate itself to the peer.
The draft just helps each party not to select the method that is unsupported by 
the peer.

> Nits:
> 3.2.2 "If no Certificate Request payload were receives" s/receives/received/ ?

Thank you, fixed in my local copy.

Regards,
Valery.

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] I-D Action: draft-ietf-ipsecme-g-ikev2-11.txt

[Valery Smyslov]

Hi,

the -11 version of the draft addresses comments from Daniel's last review
(see my other message).
It also makes changes to the way keys are wrapped - it adds explicit
indication of key wrap algorithm (via new transform attribute), and thus
changes the key wrap format.
The changes are based on this discussion:
https://mailarchive.ietf.org/arch/msg/cfrg/Y6OxWjFP8Rp7jHxOrckEIJf6yD4/

The draft also has a lot of fixes and clarifications. Hope it is now clearer
and is ready for forwarding.

Please review the changes.

Regards,
Valery (and Brian).



> Internet-Draft draft-ietf-ipsecme-g-ikev2-11.txt is now available. It is a
work item of
> the IP Security Maintenance and Extensions (IPSECME) WG of the IETF.
> 
>Title:   Group Key Management using IKEv2
>Authors: Valery Smyslov
> Brian Weis
>Name:draft-ietf-ipsecme-g-ikev2-11.txt
>Pages:   74
>Dates:   2024-02-26
> 
> Abstract:
> 
>This document presents an extension to the Internet Key Exchange
>version 2 (IKEv2) protocol for the purpose of a group key management.
>The protocol is in conformance with the Multicast Security (MSEC) key
>management architecture, which contains two components: member
>registration and group rekeying.  Both components are required for a
>GCKS (Group Controller/Key Server) to provide authorized Group
>Members (GMs) with IPsec group security associations.  The group
>members then exchange IP multicast or other group traffic as IPsec
>packets.
> 
>This document obsoletes RFC 6407.  This documents also updates RFC
>7296 by renaming a transform type 5 from "Extended Sequence Numbers
>(ESN)" to the "Replay Protection (RP)" and by renaming IKEv2
>authentication method 0 from "Reserved" to "NONE".
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-g-ikev2/
> 
> There is also an HTMLized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-g-ikev2-11
> 
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-ipsecme-g-ikev2-11
> 
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
> 
> 
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] GDOI and G-IKEv2 payloads

[Valery Smyslov]

Hi Toerless,

> Well... There may be connection between progressing the draft and these
> extensions.
> 
> Given how extensions to GDOI where also done by other SDOs, i would like
to
> understand if
> G-IKEv2 has done the best to make extensions as painless as possible,
especially
> for adopting extensions previously existing in GDOI. Worst case, G-IKEv2
does
> make any such extensions more difficult than necessary (not what i would
think,
> just thinking paranoid).

G-IKEv2 is based on IKEv2 which has numerous extensions.

> Ideally, i would even like to see a small section in G-IKEv2 that outlines
how GDOI
> extensions can be mapped to G-IKEv2 . If this waas all registry entries in
> RFC8052, then it would IMHO even be a great exercise for progressing
G-IKEv2 to
> see if equivalent registry entries for
> G-IKEv2 would be sufficient. And the section i am thinking of would for
example
> just be a comparison of registry tables.

I don't think core specification should define how all existing extensions
of an older protocol could be mapped to the current one, but few general
words could be added.

Regards,
Valery.

> Cheers
> Toerless
> 
> On Tue, Feb 06, 2024 at 10:31:43AM +0300, Valery Smyslov wrote:
> > Hi Toerless,
> >
> > first G-IKEv2 should be published as RFC. The draft is currently in
> > WGLC (for a long time), but received very few reviews so far (and many
> > thanks to all who reviewed it!).
> > I'm planning to publish an updated version addressing Daniel's review
soon.
> >
> > Once G-IKEv2 is standardized, there is no problem (IMHO) to do the
> > equivalent of RFC8052 with it.
> >
> > Regards,
> > Valery.
> >
> > > How would someone today do the equivalent of RFC8052 with G-IKEv2 ?
> > >
> > > On Mon, Feb 05, 2024 at 04:06:11AM +, Fries, Steffen wrote:
> > > > Hi,
> > > >
> > > > I've got a question regarding the relation of G-IKEv2 and GDOI.
> > > >
> > > > I realized that G-IKEv2 will be the successor of GDOI and would
> > > > have a
> > question
> > > regarding backward compatibility of payloads defined for GDOI. As
> > > the
> > underlying
> > > exchanges for the base key management changed from IKE to IKEv2 they
> > > will
> > not
> > > be backward compatible. Nevertheless, there have been enhancements
> > > of GDOI for protocols used in the power system domain like GOOSE and
> > > Sampled
> > Values,
> > > which lead to the definition of new payloads for the ID, SA TEK and
> > > KD
> > payloads to
> > > accommodate the power system protocol parameters in RFC 8052.
> > > Likewise,
> > using
> > > the same approach new payloads of the same types have been defined
> > > to distribute parameters for PTP (Precision Time Protocol) in IEC
62351-9.
> > > >
> > > > In general, I realized that there are similar payloads available
> > > > in
> > G-IKEv2 but I
> > > was not quite sure, if it was a design criterion to have backward
> > compatibility for
> > > extensions/enhancements defined for GDOI to be usable also in G-IKEv2.
> > Could
> > > you please shed some light on this?
> > > >
> > > > Best regards
> > > > Steffen
> > > >
> > > > --
> > > > Steffen Fries
> > > >
> > > > Siemens AG
> > > > Technology
> > > > Cybersecurity & Trust
> > > > T CST
> > > > Otto-Hahn-Ring 6
> > > > 81739 Munich, Germany
> > > > Phone: +49 (89) 7805-22928
> > > > mailto:steffen.fr...@siemens.com
> > > > www.siemens.com
> > > > [Logo]
> > > > Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim
> > Hagemann
> > > Snabe; Managing Board: Roland Busch, Chairman, President and Chief
> > Executive
> > > Officer; Cedrik Neike, Matthias Rebellius, Ralf P. Thomas, Judith
> > > Wiese; Registered offices: Berlin and Munich, Germany; Commercial
registries:
> > Berlin-
> > > Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE
> > > 23691322
> > >
> > > ___
> > > IPsec mailing list
> > > IPsec@ietf.org
> > > https://www.ietf.org/mailman/listinfo/ipsec

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] GDOI and G-IKEv2 payloads

[Valery Smyslov]

Hi Toerless,

first G-IKEv2 should be published as RFC. The draft is currently in WGLC
(for a long time),
but received very few reviews so far (and many thanks to all who reviewed
it!).
I'm planning to publish an updated version addressing Daniel's review soon.

Once G-IKEv2 is standardized, there is no problem (IMHO) to do the
equivalent of RFC8052 with it.

Regards,
Valery.

> How would someone today do the equivalent of RFC8052 with G-IKEv2 ?
> 
> On Mon, Feb 05, 2024 at 04:06:11AM +, Fries, Steffen wrote:
> > Hi,
> >
> > I've got a question regarding the relation of G-IKEv2 and GDOI.
> >
> > I realized that G-IKEv2 will be the successor of GDOI and would have a
question
> regarding backward compatibility of payloads defined for GDOI. As the
underlying
> exchanges for the base key management changed from IKE to IKEv2 they will
not
> be backward compatible. Nevertheless, there have been enhancements of GDOI
> for protocols used in the power system domain like GOOSE and Sampled
Values,
> which lead to the definition of new payloads for the ID, SA TEK and KD
payloads to
> accommodate the power system protocol parameters in RFC 8052. Likewise,
using
> the same approach new payloads of the same types have been defined to
> distribute parameters for PTP (Precision Time Protocol) in IEC 62351-9.
> >
> > In general, I realized that there are similar payloads available in
G-IKEv2 but I
> was not quite sure, if it was a design criterion to have backward
compatibility for
> extensions/enhancements defined for GDOI to be usable also in G-IKEv2.
Could
> you please shed some light on this?
> >
> > Best regards
> > Steffen
> >
> > --
> > Steffen Fries
> >
> > Siemens AG
> > Technology
> > Cybersecurity & Trust
> > T CST
> > Otto-Hahn-Ring 6
> > 81739 Munich, Germany
> > Phone: +49 (89) 7805-22928
> > mailto:steffen.fr...@siemens.com
> > www.siemens.com
> > [Logo]
> > Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim
Hagemann
> Snabe; Managing Board: Roland Busch, Chairman, President and Chief
Executive
> Officer; Cedrik Neike, Matthias Rebellius, Ralf P. Thomas, Judith Wiese;
> Registered offices: Berlin and Munich, Germany; Commercial registries:
Berlin-
> Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322
> 
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] GDOI and G-IKEv2 payloads

[Valery Smyslov]

Hi, Steffen,

 

in general, G-IKEv2 is not backward compatible with GDOI (likewise IKEv2 is
not backward compatible with IKEv1).

For this reason extensions defined for G-DOI should be redefined for G-IKEv2
(once it becomes an RFC).

>From my reading of RFC 8052, it doesn't define new payloads for GDOI,
instead new ID type, Protocol ID etc. 

are specified. The same approach could be used for G-IKEv2 too.

 

Regards,

Valery.

 

Hi,

 

I've got a question regarding the relation of G-IKEv2 and GDOI. 

 

I realized that G-IKEv2 will be the successor of GDOI and would have a
question regarding backward compatibility of payloads defined for GDOI. As
the underlying exchanges for the base key management changed from IKE to
IKEv2 they will not be backward compatible. Nevertheless, there have been
enhancements of GDOI for protocols used in the power system domain like
GOOSE and Sampled Values, which lead to the definition of new payloads for
the ID, SA TEK and KD payloads to accommodate the power system protocol
parameters in RFC 8052. Likewise, using the same approach new payloads of
the same types have been defined to distribute parameters for PTP (Precision
Time Protocol) in IEC 62351-9. 

 

In general, I realized that there are similar payloads available in G-IKEv2
but I was not quite sure, if it was a design criterion to have backward
compatibility for extensions/enhancements defined for GDOI to be usable also
in G-IKEv2. Could you please shed some light on this?

 

Best regards

Steffen

 

--
Steffen Fries

Siemens AG
Technology
Cybersecurity & Trust
T CST
Otto-Hahn-Ring 6
81739 Munich, Germany
Phone: +49 (89) 7805-22928
  mailto:steffen.fr...@siemens.com
www.siemens.com

Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann
Snabe; Managing Board: Roland Busch, Chairman, President and Chief Executive
Officer; Cedrik Neike, Matthias Rebellius, Ralf P. Thomas, Judith Wiese;
Registered offices: Berlin and Munich, Germany; Commercial registries:
Berlin-Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE
23691322 

 

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] WG Adoption call for draft-smyslov-ipsecme-ikev2-qr-alt

[Valery Smyslov]

Hi William,

thank you for these comments. Please see inline.

> Hi,
> 
> I support the adoption of this draft.
> I've read the very early version and thought it was quite useful.
> I've read it again and still believe it's important and useful. I believe 
> we're highly likely to implement this
> draft.
> 
> 
> Some quick comments below:
> 
> 1) I feel the title "Alternate approach" doesn't reflect the value of this 
> draft well. This draft achieves the
> goals of using PPK to protect the initiated IKE SA and creating or rekeying 
> SAs with a new PPK. These are
> notable improvements in how PPK can be better used to defend against quantum 
> attacks. I'm a fan of
> Quantum Key Distribution (QKD) and PPKs can be easily and frequently changed 
> when using QKD. This
> draft is well suited in integrating into the solution of QKD. I feel this 
> draft is more useful than RFC 8784,
> especially when used together with QKD. When compared with RFC 8784, the 
> draft only has a cost of the
> round of IKE_INTERMIDATE exchange, and this cost is relatively small, at 
> least to me. So I prefer
> something like "Enhanced approach" rather than "Alternate approach".

Good point. Actually, the draft has went a bit away from the point it was just 
an alternative way to use PPK :-)
I don't have objections to "Enhanced approach", but first wat to see more 
proposals.

> 2) I strongly recommend adding support for using a new PPK for creating the 
> first Child SA, i.e., support
> sending PPK_IDENTITY_KEY notifications in IKE_AUTH. This draft already 
> supports using different PPKs
> for creating the first IKE SA, creating the additional Child SAs, and 
> rekeying both IKE and Child SAs. For
> the scenario when a stronger security requirement is needed, for example, one 
> PPK for one SA, what is
> missing in the current draft is using a new PPK for creating the first Child 
> SA. Using PPKs in the IKE_AUTH
> exchange is similar to using PPKs in the CREATE_CHILD_SA exchange as defined 
> in section 3.2. So, I
> believe adding support for using PPKs in the IKE_AUTH exchange is a small 
> modification to the draft but
> complementary to the whole solution. The integration solution of IPsec and 
> QKD would significantly
> benefit from this draft and this complement.

So, you want to be able to use separate PPKs for IKE SA and for all its Child 
SAs, including the very first one?

> 3) For the last paragraph of section 3.1,
>Since the responder selects PPK before it knows the identity of the
>initiator, a situation may occur, when the responder agrees to use
>some PPK in the IKE_INTERMEDIATE exchange, but during the IKE_AUTH
>exchange discovers that this particular PPK is not associated with
>the initiator's identity in its local policy.  Note, that the
>responder does have this PPK, but it is just not listed among the
>PPKs for using with this initiator.  In this case the responder
>SHOULD abort negotiation and return back the AUTHENTICATION_FAILED
>notification to be consistent with its policy.  However, if using PPK
>with this initiator is marked optional in the local policy, then the
>responder MAY continue creating IKE SA using the negotiated "wrong"
>PPK.
> Regarding the situation that the PPK is not associated with the initiator's 
> identity in the responder's local
> policy, I think the right choice is to not use that PPK, i.e., aborting the 
> negotiation. But, because this
> seems not to be a fatal fault, I can also accept the handling that the 
> responder will use this "wrong" PPK
> if it is configured to do so. But I don't feel the causal logic described in 
> the last sentence is correct. If
> using PPK with this initiator is marked optional in the responder's local 
> policy, it only means the
> responder can use PPK or not use PPK with the initiator, but doesn't mean the 
> "wrong" PPK can be used.
> I suggest the last sentence be reworded to " However, the responder MAY 
> continue creating IKE SA using
> the negotiated "wrong" PPK if this situation is marked acceptable in its 
> local policy."

OK, makes sense.

> Two nits:
> 1) In the first paragraph of section 3.1.1, there is a missing ")" after 
> "(for example, as defined
> in [RFC9370]".
> 2) Also in section 3.1.1, suggest the following changes:
> OLD: In the formula above Ni and Nr are nonces from the IKE_SA_INIT exchange 
> and SPIi, SPIr - SPIs of
> the IKE SA being created.
> NEW: In the formula above, Ni and Nr are nonces from the IKE_SA_INIT 
> exchange, and SPIi and SPIr are
> the SPIs of the IKE SA being created.

Fixed, thank you.

Regards,
Valery.

> Regards & Thanks！
> Wei PAN (潘伟)
> 
> > -Original Message-
> > From: IPsec  On Behalf Of Tero Kivinen
> > Sent: Tuesday, November 28, 2023 2:32 AM
> > To: ipsec@ietf.org
> > Subject: [IPsec] WG Adoption call for draft-smyslov-ipsecme-ikev2-qr-alt
> >
> > This is two week adoption call for draft-smyslov-ipsecme-ik

Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-auth-announce-06.txt

[Valery Smyslov]

Hi,

the -06 version has the security considerations section updated.

Regards,
Valery.

> -Original Message-
> From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of 
> internet-dra...@ietf.org
> Sent: Tuesday, December 12, 2023 4:09 PM
> To: i-d-annou...@ietf.org
> Cc: ipsec@ietf.org
> Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-auth-announce-06.txt
> 
> Internet-Draft draft-ietf-ipsecme-ikev2-auth-announce-06.txt is now available.
> It is a work item of the IP Security Maintenance and Extensions (IPSECME) WG
> of the IETF.
> 
>Title:   Announcing Supported Authentication Methods in IKEv2
>Author:  Valery Smyslov
>Name:draft-ietf-ipsecme-ikev2-auth-announce-06.txt
>Pages:   13
>Dates:   2023-12-12
> 
> Abstract:
> 
>This specification defines a mechanism that allows the Internet Key
>Exchange version 2 (IKEv2) implementations to indicate the list of
>supported authentication methods to their peers while establishing
>IKEv2 Security Association (SA).  This mechanism improves
>interoperability when IKEv2 partners are configured with multiple
>different credentials to authenticate each other.
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-auth-announce/
> 
> There is also an HTMLized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-ikev2-auth-announce-06
> 
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-ipsecme-ikev2-auth-announce-06
> 
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
> 
> 
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] WG Adoption call for draft-mglt-ipsecme-ikev2-diet-esp-extension

[Valery Smyslov]

Hi,

I support adoption of this document and will review it if it is adopted.

Regards,
Valery.

> -Original Message-
> From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Tero Kivinen
> Sent: Monday, November 27, 2023 9:35 PM
> To: ipsec@ietf.org
> Subject: [IPsec] WG Adoption call for 
> draft-mglt-ipsecme-ikev2-diet-esp-extension
> 
> This is two week adoption call for
> draft-mglt-ipsecme-ikev2-diet-esp-extension. If you support adopting
> this document as a working group document for IPsecME to work on, and
> then at some point publish this as an RFC, send comments to this list.
> 
> This adoption call ends 2023-12-13.
> 
> Note, that I do want to see people saying that they think this
> document is worth of working on, and that they plan to review and
> comment on it. If I only get one or two people (including authors :-)
> to say they support this work, then there is no point of work on this
> in WG.
> --
> kivi...@iki.fi
> 
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] WG Adoption call for draft-smyslov-ipsecme-ikev2-qr-alt

[Valery Smyslov]

HI,

I support adoption of this document (I am its author).
We also have implemented it.

Regards,
Valery.

> This is two week adoption call for draft-smyslov-ipsecme-ikev2-qr-alt.
> If you support adopting this document as a working group document for
> IPsecME to work on, and then at some point publish this as an RFC,
> send comments to this list.
> 
> This adoption call ends 2023-12-13.
> 
> Note, that I do want to see people saying that they think this
> document is worth of working on, and that they plan to review and
> comment on it. If I only get one or two people (including authors :-)
> to say they support this work, then there is no point of work on this
> in WG.
> --
> kivi...@iki.fi
> 
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] WGLC of draft-ietf-ipsecme-multi-sa-performance

[Valery Smyslov]

Hi Paul,

I snipped parts where we are in agreement.

> > 2. Section 2
> >
> >   There are a number of practical reasons why most Implementations have
> >   to limit a Child SA to only one specific hardware resource, but a key
> >   limitation is that sharing the crypto state, counters and sequence
> >   numbers between multiple CPUs is not feasible without a significant
> >   performance penalty.
> >
> > Shouldn't it be clarified, that the performance problems arise
> > if you use an SA by several CPUs at the same time? I don't think
> > there are problems if you use the SA by several CPUs at different time.
> > Consider you have an SA with a traffic one packet per hour.
> > Each time it is processed up by a different CPU, then the resulted
> > state is stored in the shared memory. So, perhaps
> >
> > s/one specific hardware resource/one specific hardware resource at any 
> > given time
> 
> I changed it to:
> 
> but a key limitation is that sharing the crypto state, counters
> and sequence numbers between multiple CPUs that are trying to
> use these shared states at the same time is not feasible without
> a significant performance penalty.

Fine with me.

> > 3. Section 3
> >
> >   If multiple Child SAs with the same Traffic Selectors are
> >   desired, the initiator will add the SA_RESOURCE_INFO notify payload
> >   to the Exchange negotiating the Child SA (eg IKE_AUTH or
> >   CREATE_CHILD_SA).  If this initial Child SA will be tied to a
> >   specific resource, it MAY indicate this by including an identifier in
> >   the Notification Data.  A responder that is willing to have multple
> >   Child SAs for the same Traffic Selectors will respond by also adding
> >   the SA_RESOURCE_INFO notify payload in which it MAY add a non-zero
> >   notify data payload.
> >
> > This text is a bit inconsistent with IKEv2 specification.
> > In my reading the text implies that unless you exchange SA_RESOURCE_INFO,
> > you cannot initiate multiple SAs with same selector, which is wrong -
> > you can do it at any time if you follow RFC 7296.
> > Only if you want to follow this draft (i.e. - associate each Child SA with
> > some resource, and be able to limit their number with TS_MAX_QUEUE)
> > you have to negotiate. I think that this subtle thing should be expressed 
> > more accurately.
> 
> Changed to:
> 
>   If multiple Child SAs with the same Traffic Selectors that
>  are bound to a single resource are desired, [...]

OK.

> > 4. Section 3
> >
> >   These resource-
> >   specific Child SAs MUST be negotiated with identical Child SA
> >   properties that were negotiated for the initial Child SA.  This
> >   includes cryptographic algorithms, Traffic Selectors, Mode (e.g.
> >   transport mode), compression usage, etc.  However, each Child SA does
> >   have its own keying material that is individually derived according
> >   to the regular IKEv2 process.
> >
> > I think that MUST is over-restrictive if we talk about crypto algorithms.
> > For crypto algorithms herhaps something along the lines:
> >
> > SHOULD be negotiated with the same crypto algorithms;
> > if they differ, then they MUST provide identical level of protection.
> 
> I don't agree. We are basically making "clones", so I see no reason why
> to make this more complicated by allowing things to be more different in
> various ways. The negotiation for the first child and second child
> should follow from the same configuration so it should really also end
> up returning the same crypto algorithms. Unless you would make choics
> based on trigger packet on specific resource, but that's something I
> am happy to not create another knob for. If others really feel similar
> to Valery, please speak out. We would also than need to make a clear
> list of all the knobs that MUST be the same and all the ones that SHOULD
> be the same. I'd rather not make that list :P

I see your point. I don't insist, but also don't want to eliminate this option.
For example (as it was pointed out on the list) when different resources
are optimized for different algorithms.

> > (I agree that Mode and Traffic Selectors MUST be the same, not sure about 
> > compression).
> 
> 
> > 5. Section 3
> >
> >   During the CREATE_CHILD_SA rekey for the Child SA, the
> >   SA_RESOURCE_INFO notification MAY be included, but regardless of
> >   whether or not it is included, the rekeyed Child SA MUST be bound to
> >   the same resource(s) as the Child SA that is being rekeyed.
> >
> > Isn't binding a local matter? Doesn't peer bother to what resource you bound
> > your end of an SA? Then why is there this MUST? What happens if I bound new 
> > SA
> > to a different CPU - peer never know this, so how it will check that you 
> > follow this MUST?
> > I think that instead of this requirement there should be just a 
> > recommendation for implementers
> > (with no BCP14 language).
> i
> changed MUST to should.

I can live with this, although I would prefer t

Re: [IPsec] Interesting attacks on PKCS#v1.5 in IKE

[Valery Smyslov]

Hi Paul,

> >> On the other perhaps we should think of moving Secure Password
> >> Framework for IKev2 (RFC6467) and ONE of the associated password
> >> authentication methods to standard track,
> >
> > Strongly support.
> 
> We also talked about that before. A truly strong random PSK is much
> stronger than a PAKE. Pushing people to use PAKE might in many cases

No objection. PAKE is not a replacement for PSK, but it has its own niche.
It is most appropriate for user authentication, when use doesn't have
certificate and cannot remember strong PSK.

> decrease the security strength as well. So we cannot get rid of PSK,

Nobody proposes getting rid of PSK.

> so it seems advise to "use PAKE not PSK" will have the same effect

No, it is not a general advise. PAKE is only applicable for some scenarios.

> as "don't use weak PSKs" which clearly is not working. Which is why
> I feel perhaps at loading time of PSKs, my implementation should reject
> certain obviously weak PSKs. On systems using PSKs, we don't tend to
> have 1000s of these, just a few. We can spend some CPU cycles on these.
> 
> >> and try to get people to implement
> >
> > We implemented 6467.
> 
> For users to authenticate with a password, I think EAP methods are far
> more common. eg EAP-mschapv2, which you can ask the RADEXT group has
> its own set of horrible security features (eg if the EAP messages are
> not themselves encrypted to the AAA server).

That's why the idea is to use strong password authentication, not 
broken methods. PAKE as a concept provides a defense against
passive dictionary attacks, so it is a big step forward compare to 
most existing methods. It cannot defend against active brute force
attacks though...

> >> them. If I remember right CFRG has now selected one augmented and one
> >> non-augmented PAKE, so perhaps we could simply say use them, but I have
> >> not checked whether we have either one of them defined for Secure
> >> Password Framwork (RFC6567) uses.
> >
> > These methods are CPace (balanced) and OPAQUE (augmented).
> > None are defined for 6467 yet. Moreover, both are not
> > yet published as RFC.
> 
> We can work on adding these, but I feel that IKE implementations kind of
> need to force that a minimum length PSK cannot be used without a PAKE.
> Otherwise we just add another unused feature without solving anything.

I still think that PAKE is different in its use cases, than PSK.
PAKE is good when the secret is not stored on the host at all,
only user knows it (so, if your notebook is stolen, the theft gets nothing).
PSK assumes that they are stored somewhere, so that no human 
intervention is needed to access them.

Regards,
Valery.

> Paul

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] review draft-ietf-ipsecme-g-ikev2-10.txt

[Valery Smyslov]

Hi Daniel,

 

thank you for the review. I will look at it a bit later.

 

Regards,

Valery.

 

Hi, 

 

I reviewed draft-ietf-ipsecme-g-ikev2-10.txt and provides my comments in the 
attached file. I am providing impressions as I was reading the text, the 
authors are free to ignore them. I think the document is in good shape and I 
tend to think we may send it to IESG in the coming future. The beginning is 
quite hard but then it is pretty clear. 

 

I am pretty sure I am using variations of the GCKS acronyms but it represents 
the same entity ;-). I have not reviewed the appendix, sections I might have to 
review are 4.5.3.  Member Key Bag Substructure 2.4.1.1.  GSA_REKEY Messages 
Authentication. 



 

Yours, 

Daniel


-- 

Daniel Migault

Ericsson

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Interesting attacks on PKCS#v1.5 in IKE

[Valery Smyslov]

Hi,

> > - Maybe look at a new EAP method to prevent AUTH payload from the
> >server to be send before client is authenticated.

If EAP is employed the server sends AUTH twice - first time before any 
EAP method starts and second time - at the end of EAP protocol.
Are you suggesting not to send the first AUTH, so not pre-authenticate
server to client before EAP starts?

> When we were designing IKEv2 we had long discussion about who should
> authenticate first. If the initiator authenticates first, that allows 
> attackers to
> find out identity of the client / remote users, which might be more valuable
> than the identity of the server. The identity of the server is quiet often 
> already
> known based on the IP-address.
> 
> Making resopnder to authenticate first will allow attackers to do scanning of
> identities on the network, i.e., they can connect to hosts and do active
> connection and get the authenticated identity of the server.
> 
> > - Implementations MUST reject weak PSKs that are easy to detect.
> 
> To that to be MUST, it would require some specific methods to tell how you
> can detect weak PSKs.
> 
> We already have:
> 
>Note that it is a common but typically insecure practice to have a
>shared key derived solely from a user-chosen password without
>incorporating another source of randomness.  This is typically
>insecure because user-chosen passwords are unlikely to have
>sufficient unpredictability to resist dictionary attacks and these
>attacks are not prevented in this authentication method.
> 
> On the other perhaps we should think of moving Secure Password
> Framework for IKev2 (RFC6467) and ONE of the associated password
> authentication methods to standard track, 

Strongly support.

> and try to get people to implement

We implemented 6467.

> them. If I remember right CFRG has now selected one augmented and one
> non-augmented PAKE, so perhaps we could simply say use them, but I have
> not checked whether we have either one of them defined for Secure
> Password Framwork (RFC6567) uses.

These methods are CPace (balanced) and OPAQUE (augmented).
None are defined for 6467 yet. Moreover, both are not
yet published as RFC.

Regards,
Valery.

> --
> kivi...@iki.fi
> 
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] New Version Notification for draft-kampanakis-ml-kem-ikev2-00.txt

[Valery Smyslov]

Hi Panos,

first, thank you for posting this draft. I think this is an important work. Few 
comments below.

First, you should not use in the draft any codepoints until IANA allocates them.
Just replace your self-allocated values for ML-KEM with ""
whenever it is mentioned in the draft. Once codepoints are allocated by IANA
you will replace these placeholders with real values (that might be different
from what are you using now).

Then, I think that there is no need to repeat in this draft text from RFC 7296, 
RFC9242, RFC 9370 etc.
It is enough if you just reference these RFCs. This would eliminate Section 2 
almost entirely,
making the draft shorter. The necessary information is:
- codepoints
- length and wire format of public key and ciphertext
- recipient tests

In addition, you may also consider using ML-KEM as drop-in replacement for DH 
in IKEv2.
ML-KEM has relatively short public key, that seems to make it possible to use it
in the IKE_SA_INIT without following IKE_INTERMEDIATE (at least in some 
situations,
e.g. when IKE over TCP is used). In this case this is a pure PQ and not a 
hybrid protocol. 
Note, that I'm not advocating not using hybrid key exchange in case of ML-KEM 
(quite the opposite), 
but you may want to mention this possibility for completeness.

Regards,
Valery.



> Hi all,
> 
> https://datatracker.ietf.org/doc/draft-kampanakis-ml-kem-ikev2/
> This new draft brings ML-KEM to IKEv2 by using RFC 9370. It basically says 
> how ML-KEM will be
> negotiated as an additional Key Exchange and requests codepoints for ML-KEM. 
> The intention is not to
> get temporary codepoints like we did with Kyber in TLS. We are close to the 
> final specs, so codepoints
> next year would suffice.
> 
> It could be a standards track draft given that ML-KEM will see a lot of 
> adoption, an AD sponsored draft,
> or even an individual stable draft which gets codepoints from Expert Review.  
> The approach is to be
> decided by the IPSECME WG.
> 
> Feedback is welcome.
> 
> Thx,
> Panos
> 
> 
> ~~~
> A new version of Internet-Draft draft-kampanakis-ml-kem-ikev2-00.txt has been 
> successfully submitted
> by Panos Kampanakis and posted to the IETF repository.
> 
> Name: draft-kampanakis-ml-kem-ikev2
> Revision: 00
> Title:Post-quantum Hybrid Key Exchange with ML-KEM in the Internet Key 
> Exchange Protocol Version
> 2 (IKEv2)
> Date: 2023-11-12
> Group:Individual Submission
> Pages:11
> URL:  https://www.ietf.org/archive/id/draft-kampanakis-ml-kem-ikev2-00.txt
> Status:   https://datatracker.ietf.org/doc/draft-kampanakis-ml-kem-ikev2/
> HTML: 
> https://www.ietf.org/archive/id/draft-kampanakis-ml-kem-ikev2-00.html
> HTMLized: https://datatracker.ietf.org/doc/html/draft-kampanakis-ml-kem-ikev2
> 
> 
> Abstract:
> 
>[EDNOTE: The intention of this draft is to get IANA KE codepoints for
>ML-KEM.  It could be a standards track draft given that ML-KEM will
>see a lot of adoption, an AD sponsored draft, or even a individual
>stable draft which gets codepoints from Expert Review.  The approach
>is to be decided by the IPSECME WG. ]
> 
>NIST recently standardized ML-KEM, a new key encapsulation mechanism,
>which can be used for quantum-resistant key establishment.  This
>draft specifies how to use ML-KEM as an additionall key exchange
>mechanism in IKEv2 along with traditional (Elliptic Curve) Diffie-
>Hellman.  This hybrid approach allows for negotiating IKE and Child
>SA keys which are safe against cryptanalytically-relevant quantum
>computers and theoretical weaknesses in ML-KEM as it is relatively
>new.
> 
> 
> 
> The IETF Secretariat
> 
> 
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] WGLC of draft-ietf-ipsecme-multi-sa-performance

[Valery Smyslov]

Hi,

I support publication of this draft. I'm glad authors took my points into 
consideration
while preparing the latest version. I do have some comments though.

1. Section 1

   IKEv2 [RFC7296] already allows installing
   multiple Child SAs with identical Traffic Selectors, but it offers no
   method to indicate that the additional Child SA is being requested
   for performance increase reasons and is restricted to some resource
   (queue or CPU).  Without this indication, the peer might not accept
   multi Child SAs with identical Traffic Selectors and might delete one
   of the Child SAs it considered an unwanted duplicate.

There is some inconsistency here. You first say that IKEv2 allows
creating multiple identical Child SAs and then say that implementations
would delete them as unwanted duplicates. Clearly these implementations
violate RFC 7296, and we don't consider broken implementations, do we? :-)
I suggest to remove the last sentence, or to add a clarification.

2. Section 2

   There are a number of practical reasons why most Implementations have
   to limit a Child SA to only one specific hardware resource, but a key
   limitation is that sharing the crypto state, counters and sequence
   numbers between multiple CPUs is not feasible without a significant
   performance penalty.

Shouldn't it be clarified, that the performance problems arise
if you use an SA by several CPUs at the same time? I don't think 
there are problems if you use the SA by several CPUs at different time.
Consider you have an SA with a traffic one packet per hour.
Each time it is processed up by a different CPU, then the resulted
state is stored in the shared memory. So, perhaps

s/one specific hardware resource/one specific hardware resource at any given 
time

3. Section 3

   If multiple Child SAs with the same Traffic Selectors are
   desired, the initiator will add the SA_RESOURCE_INFO notify payload
   to the Exchange negotiating the Child SA (eg IKE_AUTH or
   CREATE_CHILD_SA).  If this initial Child SA will be tied to a
   specific resource, it MAY indicate this by including an identifier in
   the Notification Data.  A responder that is willing to have multple
   Child SAs for the same Traffic Selectors will respond by also adding
   the SA_RESOURCE_INFO notify payload in which it MAY add a non-zero
   notify data payload.

This text is a bit inconsistent with IKEv2 specification. 
In my reading the text implies that unless you exchange SA_RESOURCE_INFO,
you cannot initiate multiple SAs with same selector, which is wrong - 
you can do it at any time if you follow RFC 7296.
Only if you want to follow this draft (i.e. - associate each Child SA with
some resource, and be able to limit their number with TS_MAX_QUEUE)
you have to negotiate. I think that this subtle thing should be expressed more 
accurately.

4. Section 3

   These resource-
   specific Child SAs MUST be negotiated with identical Child SA
   properties that were negotiated for the initial Child SA.  This
   includes cryptographic algorithms, Traffic Selectors, Mode (e.g.
   transport mode), compression usage, etc.  However, each Child SA does
   have its own keying material that is individually derived according
   to the regular IKEv2 process.

I think that MUST is over-restrictive if we talk about crypto algorithms.
For crypto algorithms herhaps something along the lines: 

SHOULD be negotiated with the same crypto algorithms;
if they differ, then they MUST provide identical level of protection.

 (I agree that Mode and Traffic Selectors MUST be the same, not sure about 
compression).

5. Section 3

   During the CREATE_CHILD_SA rekey for the Child SA, the
   SA_RESOURCE_INFO notification MAY be included, but regardless of
   whether or not it is included, the rekeyed Child SA MUST be bound to
   the same resource(s) as the Child SA that is being rekeyed.

Isn't binding a local matter? Doesn't peer bother to what resource you bound
your end of an SA? Then why is there this MUST? What happens if I bound new SA
to a different CPU - peer never know this, so how it will check that you follow 
this MUST?
I think that instead of this requirement there should be just a recommendation 
for implementers
(with no BCP14 language).

6. Section 4

   A simple distribution could be to install one additional Child SA on
   each CPU.  An implementation MAY ensure that one Child SA can be used
   by all CPUs ...

I believe it should be "can" instead of "MAY", since it is a local matter.

7. Section 4

   When the number of queue or CPU resources are different between the
   peers, the peer with the least amount of resources MAY decide to not
   install a second outbound Child SA for the same resource as it will
   never use it to send traffic.  

Again, I think it should be "can" instead of "MAY", since it is a local matter.

8. Section 4

   If per-CPU SADB_ACQUIRE messages are implemented (see Section 6), the
   Traffic Selector (TSi) entry containing the inform

Re: [IPsec] AD Review of draft-ietf-ipsecme-ikev2-auth-announce-04

[Valery Smyslov]

HI Roman!

> Hi Valery!
> 
> Thanks for -05.  Reducing the thread down to areas of discussion.
> 
> > -Original Message-
> > From: Valery Smyslov 
> > Sent: Thursday, October 26, 2023 11:51 AM
> > To: 'Roman Danyliw' ; ipsec@ietf.org
> > Subject: Re: [IPsec] AD Review of draft-ietf-ipsecme-ikev2-auth-announce-04
> 
> [snip]
> 
> > > ** Section 5.  Please add the Security Considerations of the specifically
> > negotiated auth methods apply.
> >
> > This is not a negotiation, this is announcement, just to help the other 
> > side to
> > correctly choose among several possible methods. Since this is a hint,
> > implementations may use it as other hints that are already available (e.g. 
> > CAs
> > from CERTREQ). Thus I'm not sure what specifically should be added to the
> > Security Considerations section. Do you have some proposed text?
> 
> I was looking primarily for a reminder that the different methods being 
> suggested each have their own
> security considerations.

I think we can add the following text:

Security properties of different authentication methods varies.
Refer to corresponding documents, listed in [IKEV2-IANA] for 
discussion of security properties of each authentication method.

Note, that announcing authentication methods gives an eavesdropper
additional information about peers capabilities. If a peer advertises 
NULL authentication along with other methods, then active attacker 
on the path may force to use NULL authentication by removing
all other announcements. Note, that this is not a real attack, since
NULL authentication should be allowed by local security policy.
 
Regards,
Valery.

> > > ** Section 6.  The “Notify Message Types - Status Types” registry has
> > > three fields.  Please formally say that this document should be the 
> > > reference.
> >
> > Done.
> >
> > I also have off-the-list conversation with Daniel Van Geest, who made some
> > good proposals, which I would also like to include in the draft if the WG 
> > agrees.
> >
> > 1. Specify that auth announcements are included into the
> > SUPPORTED_AUTH_METHODS notification
> > in the order of their preferences for the sender. This doesn't break 
> > anything
> > (the receiver is free to ignore the order),
> > but might help it to make the best choice.
> >
> > 2. Clarify that peers may send the SUPPORTED_AUTH_METHODS independently
> > of whether it was received
> > (this is not a negotiation). This is what actually the draft says now, 
> > just stress
> > this for clarification.
> >
> > 3. Specify interaction with RFC 4739 (Multiple Authentication Exchanges in 
> > the
> > Internet Key Exchange (IKEv2) Protocol).
> > In particular. allow sending multiple SUPPORTED_AUTH_METHODS
> > notifications in a message
> > (also add a clarification that if multiple SUPPORTED_AUTH_METHODS
> > notifications are included in a message
> >  and the receiver doesn't know why, the all included announcements form 
> > a
> > single list).
> 
> I see this proposed text is in -05.
> 
> WG chairs: can you please check that this has consensus of the WG.
> 
> Thanks,
> Roman

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] AD Review of draft-ietf-ipsecme-ikev2-auth-announce-04

[Valery Smyslov]

Hi Roman,

thank you for your review, please see inline.

> Hi!
> 
> I performed an AD review of draft-ietf-ipsecme-ikev2-auth-announce-04.  
> Thanks for the work on this
> document.  I have the following feedback:
> 
> 
> ** Section 3.1
> If the initiator is configured to use Extensible Authentication Protocol 
> (EAP) for authentication in IKEv2
> (see Section 2.16 of [RFC7296]), then it SHOULD NOT send the 
> SUPPORTED_AUTH_METHODS
> notification.
> 
> -- Since SHOULD NOT vs. MUST NOT is used, under what circumstances would it 
> be appropriate to use
> EAP + SUPPORTED_AUTH_METHODS?

I was thinking that this might simplify implementations (initiator may always 
send this notify, responder will just ignore it).

But thinking more about this, I now understand, that this paragraph is 
incorrect and should be removed at all.
For the reason, that the sender of  SUPPORTED_AUTH_METHODS announces which auth 
methods it is ready
to accept as verifier, and in IKEv2 even in case of EAP the server (responder) 
always send AUTH payload
to authenticate itself to the initiator (which is done before the EAP starts). 
So, even in case of EAP
the initiator should verify the responder's identity using AUTH payload, thus 
sending SUPPORTED_AUTH_METHODS is OK.

> ** Section 3.2
> 
> If more authentication methods are defined in future, the corresponding 
> documents must describe the
> semantics of the announcements for these methods.
> 
> -- Should this be a s/must/MUST?

With my understanding of using BCP14 language, these keywords are usually 
concerned
with protocols behavior. In this case the "must" is concerned with human 
(document authors) behavior :-)

That said, I understand that this may be interpreted differently, so if you 
think
"MUST" is more appropriate here than "must", I'll be happy to make the change.

> ** Section 3.2
> The blob always starts with an octet containing the length of the blob 
> followed by an octet containing
> the authentication method. Authentication methods are represented as values 
> from the "IKEv2
> Authentication Method" registry defined in [IKEV2-IANA].
> 
> -- The reference in [IKEV2-IANA] is incorrect.  It should be pointing to 
> Parameter 12.
> 
> OLD
> [IKEV2-IANA]
> IANA, "Internet Key Exchange Version 2 (IKEv2) Parameters",
> .
> 
> NEW
> [IKEV2-IANA]  IANA, "Internet Key Exchange Version 2 (IKEv2) Parameters",
> 

Fixed, thank you.

> ** Section 3.2.3.  Please provide a normative reference DER.  I believe it is:
> 
>[X.690]ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002,
>   Information technology - ASN.1 encoding rules:
>   Specification of Basic Encoding Rules (BER), Canonical
>   Encoding Rules (CER) and Distinguished Encoding Rules
>   (DER).

Done (also added a reference to RFC 5280 for AlgorithmIdentifier, followed what 
is in RFC 7427).

> ** Section 5.  Please add the Security Considerations of the specifically 
> negotiated auth methods apply.

This is not a negotiation, this is announcement, just to help the other side
to correctly choose among several possible methods. Since this is a hint,
implementations may use it as other hints that are already available 
(e.g. CAs from CERTREQ). Thus I'm not sure what specifically should be
added to the Security Considerations section. Do you have some proposed text?

> ** Section 6.  The “Notify Message Types - Status Types” registry has three 
> fields.  Please formally say
> that this document should be the reference.

Done.

I also have off-the-list conversation with Daniel Van Geest, who made some good 
proposals,
which I would also like to include in the draft if the WG agrees.

1. Specify that auth announcements are included into the SUPPORTED_AUTH_METHODS 
notification
in the order of their preferences for the sender. This doesn't break 
anything (the receiver is free to ignore the order), 
but might help it to make the best choice.

2. Clarify that peers may send the SUPPORTED_AUTH_METHODS independently of 
whether it was received
(this is not a negotiation). This is what actually the draft says now, just 
stress this for clarification.

3. Specify interaction with RFC 4739 (Multiple Authentication Exchanges in the 
Internet Key Exchange (IKEv2) Protocol).
In particular. allow sending multiple SUPPORTED_AUTH_METHODS notifications 
in a message
(also add a clarification that if multiple SUPPORTED_AUTH_METHODS 
notifications are included in a message
 and the receiver doesn't know why, the all included announcements form a 
single list).

Since the I-D submission is closed, the diff file is included with this message.

Regards,
Valery.

> Thanks,
> Roman
> ___
> IPsec mailing list
> IPsec@ietf.org
> 

Re: [IPsec] New Version Notification for draft-smyslov-ipsecme-ikev2-qr-alt-09.txt

[Valery Smyslov]

Hi,

the new version addresses comments received in the ML.
It also adds an option of using PPK in the CREATE_CHILD_SA exchange.

Regards,
Valery.

> -Original Message-
> From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
> Sent: Friday, October 20, 2023 9:27 AM
> To: Valery Smyslov
> Subject: New Version Notification for 
> draft-smyslov-ipsecme-ikev2-qr-alt-09.txt
> 
> A new version of Internet-Draft draft-smyslov-ipsecme-ikev2-qr-alt-09.txt has
> been successfully submitted by Valery Smyslov and posted to the
> IETF repository.
> 
> Name: draft-smyslov-ipsecme-ikev2-qr-alt
> Revision: 09
> Title:Alternative Approach for Mixing Preshared Keys in IKEv2 for 
> Post-quantum Security
> Date: 2023-10-19
> Group:Individual Submission
> Pages:11
> URL:  
> https://www.ietf.org/archive/id/draft-smyslov-ipsecme-ikev2-qr-alt-09.txt
> Status:   https://datatracker.ietf.org/doc/draft-smyslov-ipsecme-ikev2-qr-alt/
> HTMLized: 
> https://datatracker.ietf.org/doc/html/draft-smyslov-ipsecme-ikev2-qr-alt
> Diff: 
> https://author-tools.ietf.org/iddiff?url2=draft-smyslov-ipsecme-ikev2-qr-alt-09
> 
> Abstract:
> 
>An Internet Key Exchange protocol version 2 (IKEv2) extension defined
>in RFC8784 allows IPsec traffic to be protected against someone
>storing VPN communications today and decrypting it later, when (and
>if) cryptographically relevant quantum computers are available.  The
>protection is achieved by means of Post-quantum Preshared Key (PPK)
>which is mixed into the session keys calculation.  However, this
>protection doesn't cover an initial IKEv2 SA, which might be
>unacceptable in some scenarios.  This specification defines an
>alternative way to get protection against quantum computers, which is
>similar to the solution defined in RFC8784, but protects the initial
>IKEv2 SA too.
> 
>Besides, RFC8784 assumes that PPKs are static and thus they are only
>used when an initial IKEv2 Security Association (SA) is created.  If
>a fresh PPK is available before the IKE SA is expired, then the only
>way to use it is to delete the current IKE SA and create a new one
>from scratch, which is inefficient.  This specification also defines
>a way to use PPKs in active IKEv2 SA for creating additional IPsec
>SAs and for rekeys operations.
> 
> 
> 
> The IETF Secretariat


___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] I-D Action: draft-ietf-ipsecme-g-ikev2-10.txt

[Valery Smyslov]

Hi,

compared to previous version this one contains no changes, just keeps the draft 
alive.
Based on discussion in CFRG in summer I believe the key wrapping format should 
be changed...
More reviews are still very welcomed.

Regards,
Valery.

> -Original Message-
> From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of 
> internet-dra...@ietf.org
> Sent: Friday, October 20, 2023 9:31 AM
> To: i-d-annou...@ietf.org
> Cc: ipsec@ietf.org
> Subject: [IPsec] I-D Action: draft-ietf-ipsecme-g-ikev2-10.txt
> 
> Internet-Draft draft-ietf-ipsecme-g-ikev2-10.txt is now available. It is a
> work item of the IP Security Maintenance and Extensions (IPSECME) WG of the
> IETF.
> 
>Title:   Group Key Management using IKEv2
>Authors: Valery Smyslov
> Brian Weis
>Name:draft-ietf-ipsecme-g-ikev2-10.txt
>Pages:   71
>Dates:   2023-10-19
> 
> Abstract:
> 
>This document presents an extension to the Internet Key Exchange
>version 2 (IKEv2) protocol for the purpose of a group key management.
>The protocol is in conformance with the Multicast Security (MSEC) key
>management architecture, which contains two components: member
>registration and group rekeying.  Both components require a Group
>Controller/Key Server to download IPsec group security associations
>to authorized members of a group.  The group members then exchange IP
>multicast or other group traffic as IPsec packets.
> 
>This document obsoletes RFC 6407.  This documents also updates RFC
>7296 by renaming a transform type 5 from "Extended Sequence Numbers
>(ESN)" to the "Replay Protection (RP)" and by renaming IKEv2
>authentication method 0 from "Reserved" to "NONE".
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-g-ikev2/
> 
> There is also an HTMLized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-g-ikev2-10
> 
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-ipsecme-g-ikev2-10
> 
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
> 
> 
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-auth-announce-04.txt

[Valery Smyslov]

Hi,

this version addresses points from the shepherd review.

Regards,
Valery.

> -Original Message-
> From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of 
> internet-dra...@ietf.org
> Sent: Monday, October 16, 2023 5:03 PM
> To: i-d-annou...@ietf.org
> Cc: ipsec@ietf.org
> Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-auth-announce-04.txt
> 
> Internet-Draft draft-ietf-ipsecme-ikev2-auth-announce-04.txt is now available.
> It is a work item of the IP Security Maintenance and Extensions (IPSECME) WG
> of the IETF.
> 
>Title:   Announcing Supported Authentication Methods in IKEv2
>Author:  Valery Smyslov
>Name:draft-ietf-ipsecme-ikev2-auth-announce-04.txt
>Pages:   12
>Dates:   2023-10-16
> 
> Abstract:
> 
>This specification defines a mechanism that allows the Internet Key
>Exchange version 2 (IKEv2) implementations to indicate the list of
>supported authentication methods to their peers while establishing
>IKEv2 Security Association (SA).  This mechanism improves
>interoperability when IKEv2 partners are configured with multiple
>different credentials to authenticate each other.
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-auth-announce/
> 
> There is also an HTMLized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-ikev2-auth-announce-04
> 
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-ipsecme-ikev2-auth-announce-04
> 
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
> 
> 
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Shepherd review of the draft-ietf-ipsecme-ikev2-auth-announce

[Valery Smyslov]

Hi Tero,

thank you for the review. See inline below.

> I would need author to reply this email and express whether there is
> any IPRs related to this draft known by the authors.

I confirm that I'm not aware of any IPR related to this draft.

> --
> 
> In section 3.1 the draft says:
> 
>   Instead, the initiator MAY either link the
>Announcements to the CAs received in the IKE_SA_INIT response, or MAY
>ignore the SUPPORTED_AUTH_METHODS notification entirely.
> 
> but instead of ignoring the SUPPORTED_AUTH_METHODS notification
> entirely, it could simply ignore the cert linking. If it ignores the
> whole SUPPORTED_AUTH_METHODS it might pick completely unusable method,
> so instead it should use that to pick suitable methods, even when it
> can't link them to specific trust anchors.

Makes sense. Changed to:

   Instead, the initiator MAY either link the
   Announcements to the CAs received in the IKE_SA_INIT response, or MAY
   ignore the Announcements containing links to CAs.

> --
> 
> In section 3.2 the draft says:
> 
> The meaning of the remaining octets of the blob, if
>any, depends on the authentication method and is defined below.
> 
> I think it would be simply bettter to say:
> 
> The meaning of the remaining octets of the blob, if
>any, depends on the authentication method.
> 
> as in the future some of those authentication methods might be defined
> in other documents and not below...

OK, good point.

> --
> 
> As this document adds two new variations of the basic IKEv2
> IKE_SA_INIT / (IKE_INTERMEDIATE) / IKE_AUTH, it would be really good
> to have IKEv2 RFC 7296 Appendix C style exchange summaries. Please add
> those.

Added.

> --
> 
> I-D nits complain :
> 
> == Outdated reference: A later version (-09) exists of
>  draft-ounsworth-pq-composite-sigs-08
> 
> so fix that also at the same time.

Oh, this is fixed automatically when a new version is published :-)

Regards,
Valery.

> --
> kivi...@iki.fi

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] [***SPAM***] RE: SvcParams encoding (was RE: AUTH48: RFC-to-be 9464 for your review)

[Valery Smyslov]

Hi Med, Tommy, all,

> Hi Tommy, all,
> 
> One comment on this part:
> 
> > the binary format for the parameters, and it doesn’t require the IKE
> > implementation to do any parsing, etc. on that.
> 
> Actually, it should because we have some restriction on params in DNR/IKE. 
> Blindly passing the
> information to DNS libraries may induce some issues, e.g., when IP hints are 
> present but !=IP addresses.

In addition, RFC 8598 specifies that Domain Name is in DNS presentation format.
So, if encrypted DNS is used with Split DNS, then I suspect the parsing will be 
needed (am I missing something?).

Regards,
Valery.

> For this reason and also to provide guidance for future params that might 
> (not) be suitable for DNR/IKE,
> do you see a value in tagging these in the IANA SVCB registry? See more at:
> https://boucadair.github.io/dnr-svcb-registry/draft-wb-add-svcb-registry-update.html
>  (not published
> yet).
> 
> For server configuration files (including small ones in CPEs) based on 
> human-readable parameters, the
> DHCP/IKE libraries will do the conversion for sending them using the wire 
> format. Making use of new
> svcparams won’t be automatic as we might ideally hope but some effort will be 
> needed to convince
> vendors that new svcparams are useful for DNR/IKE beyond what is included in 
> the DNR/IKE RFCs. The
> proposed update would help in that maintenance front.
> 
> Cheers,
> Med
> 
> > -Message d'origine-
> > De : Tommy Pauly 
> > Envoyé : jeudi 5 octobre 2023 04:44
> > À : Paul Wouters 
> > Cc : BOUCADAIR Mohamed INNOV/NET ;
> > ipsec@ietf.org; Valery Smyslov ; ipsecme-...@ietf.org;
> > ipsecme-cha...@ietf.org; Dan Wing ; Tirumaleswar
> > Reddy 
> > Objet : Re: [IPsec] SvcParams encoding (was RE: AUTH48: RFC-to-be 9464
> >  for your review)
> >
> > As with DNR, I definitely think we should be using the wire format
> > here (for communicating on the wire). The IKE option here would carry
> > the binary format for the parameters, and it doesn’t require the IKE
> > implementation to do any parsing, etc on that.
> >
> > Since it looks like there’s good consensus on the DNR side in the ADD
> > WG, I think the most important thing to do is ensure the same format
> > is used for IKE as is used elsewhere. For DDR, DNR, and this IKE
> > extension, they should all use the same format, whether the
> > information is in a DNS packet, a DHCP packet, or an IKE packet.
> >
> > Thanks,
> > Tommy
> >
> > > On Oct 4, 2023, at 5:28 AM, Paul Wouters  wrote:
> > >
> > > As I said over the other side, I prefer presentation format. Here
> > that is even more true than over at the dhcp server because ike
> > daemons (server AND client) tend to not implement dns wire format.
> > >
> > > Presentation format would be to reject this change.
> > >
> > > But whichever is picked, if I am in the rough, do make it the same
> > format for both drafts.
> > >
> > > Paul
> > >
> > > Sent using a virtual keyboard on a phone
> > >
> > >> On Oct 4, 2023, at 06:33, mohamed.boucad...@orange.com wrote:
> > >>
> > >> Hi all, =
> > >>
> > >>
> > >> This document is already in AUTH48-DONE but still not published yet
> > >> because= of a normative dependency (see more about the cluster at
> > >>
> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> > >> .rfc-
> > %2F&data=05%7C01%7Cmohamed.boucadair%40orange.com%7C9255f776e6cc
> > >>
> > 4c03710d08dbc54d09a2%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638
> > >>
> > 320706888240742%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
> > >>
> > 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=j1S53uWVH
> > >> CJoqPS%2BIWoKaFJRUjaz1zC1k2h1FKLEAoQ%3D&reserved=0=
> > >> editor.org/auth48/C461).
> > >>
> > >> A late issue was raised about the encoding of the service
> > parameters
> > >> (repre= sentation format vs wire format). A summary can be found
> > at:
> > >> https://mailar=
> > chive.ietf.org/arch/msg/add/qU_TaosKNhojs3h3ojUb0B_bpXg/.
> > >>
> > >> In order to be consistent with the consensus in ADD, I suggest we
> > >> update RF= C-to-be 9464 as follows: =
> > >>
> > >>
> > >> OLD:
> > >>  Service Parameters (SvcParams) (variab

Re: [IPsec] Fwd: New Version Notification for draft-colitti-ipsecme-esp-ping-00.txt

[Valery Smyslov]

Hi Paul,

> On Wed, 6 Sep 2023, Antony Antony wrote:
> 
> > Here is a proposed text for the I-D.
> >
> > "Upon completing an IKE negotiation, an IPsec peer wishing to ascertain the
> > viability of the path for ESP packets MAY initiate an ESP Echo Request
> 
> I would change this to:
> 
> "After completing an IKE negotiation, an IPsec peer wishing to verify
> the viability of the current network path for ESP packets MAY initiate
> an ESP Echo Request"
> 
> As in, you can do it immediately after the IKE SA is established, or at
> any time later as well.

Completing IKE negotiation doesn't always mean that IPsec SAs are created.
(e.g., in case of childless IKE or non-fatal error in creating Child SAs).
More accurate text is needed.

Regards,
Valery.

> Paul
> 
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] New Version Notification for draft-smyslov-ipsecme-ikev2-qr-alt-07.txt

[Valery Smyslov]

NTERMEDIATE, use N(PPK_IDENTITY) in initiator message and
> N(PPK_IDENTITY_KEY) in responder message, only for the single PPK the 
> responder has selected.
> 
> Explanation: Currently, in the last IKE_INTERMEDIATE, the initiator sends SK 
> { ... N(PPK_IDENTITY_KEY,
> PPK_ID_1) [ , ... , N(PPK_IDENTITY_KEY, PPK_ID_n ) ] } where PPK_IDENTITY_KEY 
> is sent for each PPK_ID
> the initiator is offering. The responder then sends SK { N(PPK_IDENTITY) } 
> for the PPK it selects, using the
> N(PPK_IDENTITY) Notify Payload specified in RFC 8784.
> 
> It's my understanding that the initiator and responder expect the PPKs to 
> match for any given PPK_ID
> (i.e. that there is a very high likelihood that they match). If this 
> assumption is incorrect, please correct
> me, but if this is the case, in order to perform fewer computations and 
> shrink the size of the initiator
> message, it may make sense to use N(PPK_IDENTITY) [RFC8784] in the initiator 
> message, and the new
> N(PPK_IDENTITY_KEY) in the responder message, only for the single PPK the 
> responder has selected.
> Then, before the initiator sends IKE_AUTH, it can use the confirmation value 
> sent by the responder in
> N(PPK_IDENTITY_KEY) to check that the PPK values the initiator and responder 
> are using match. (If they
> do not match, the initiator could send another IKE_INTERMEDIATE containing 
> N(PPK_IDENTITY_KEY)s for
> each PPK it supports, as currently specified.) Depending on how many PPKs the 
> initiator offers, this may
> not considerably shrink the message size.

The reason why the initiator provides key confirmation(s) to the responder and 
not vice versa 
is that in this case it's more easy to handle PPK mismatch case in the protocol.
If the responder detects that the PPK value for the selected PPK mismatches, 
then it just sends
back AUTHENTICATION_FAILED (in the IKE_INTERMEDIATE) and the negotiation is 
aborted gracefully.
On the other hand, if the responder provided key confirmation to the initiator,
then in the situation when the selected PPK value mismatched, the initiator 
should inform the responder
somehow about this. From the responder's point of view the IKE_INTERMEDIATE 
exchange
has been completed successfully and the responder has been waiting for the 
IKE_AUTH request.
But the initiator could not start IKE_AUTH because it was unable to compute 
SK_* values.
The initiator might either send a clear INFORMATIONAL with AUTHENTICATION_FAILED
(that is not trusted at all) or might just abort the negotiation leaving the 
responder with 
the incomplete IKE SA, which would be eventually deleted, but would still 
consume some
memory before this and thus increasing surface for DoS attacks.
Note, that in this case there would be also no diagnostics on the responder
about the real reason the negotiation failed (it looked like DoS attack to the 
responder).

> Comment: Update Security Considerations section.
> 
> Explanation: The Security Considerations section currently cites RFC 8784. 
> I'd suggest that RFC 9242's
> security considerations be referenced as well, and I'd suggest repeating some 
> of the security
> considerations from RFC 9370 that are relevant here- in particular, the 
> second paragraph of RFC 9370
> discusses how to ensure quantum resistance in Transform Types 2 and 3- this 
> is worth repeating here,
> especially in the case that this draft is used independently (without RFC 
> 9370) to provide QR.
> 
> In RFC 8784 and RFC 9370, there is discussion of the security of each 
> extension with regard to an active
> attacker- it may be useful in this draft to extend this discussion here in 
> order to cover 1. the addition of
> IKE_INTERMEDIATE, 2. the fact that QR is achieved prior to IKE_AUTH (either 
> if this draft is used on its
> own or in conjunction with RFC 9370), and 3. the fact that authentication is 
> QR (compared to RFC 9370
> alone).

The current Security Consideration section is mostly a stub.
I agree that more considerations should be added there.
Thank you for the concrete proposals.

Regards,
Valery.

> - Rebecca
> 
> Rebecca Guthrie
> she/her
> Center for Cybersecurity Standards (CCSS)
> Cybersecurity Collaboration Center (CCC)
> National Security Agency (NSA)
> 
> -Original Message-
> From: IPsec  On Behalf Of Valery Smyslov
> Sent: Friday, April 14, 2023 4:11 AM
> To: IPsecME WG 
> Cc: ipsec-cha...@ietf.org
> Subject: Re: [IPsec] New Version Notification for 
> draft-smyslov-ipsecme-ikev2-qr-alt-07.txt
> 
> Hi,
> 
> a new version of the draft has been published.
> It addresses issue with mismatched PPKs and also adds some clarifications on 
> interaction with RFC 8784.
> 
> As it was discussed at the IETF116 IPSECME meeting, once the new versi

[IPsec] Outstanding issue with G-IKEv2

[Valery Smyslov]

Hi,

before progressing G-IKEv2 draft further, we have to resolve an issue described 
below.
Current spec defines a format for wrapped keys (Section 4.5.1) in such a way, 
that 
only confidentiality of the wrapped keys is achieved. The format deliberately 
omits 
the integrity protection of the wrapped keys, because they are inside G-IKEv2
message, which is authenticated and integrity protected. The only reason 
to encrypt the keys inside G-IKEv2 message is to hide them from IKE protocol
level code (it may be less protected then crypto engine). On the other hand,
omitting the ICV from a key bag makes it smaller, so in case when multiple
keys need to be included into a single message (in situation member
is excluded from the group using LKH) there is less chance of fragmentation.
And to simplify implementation the algorithm used for wrapping keys is 
the same as the algorithm for protecting G-IKEv2 messages.
In case this is an AEAD algorithm the specification currently
instructs to only use encryption part of the AEAD algorithm and
not the authentication part. It's easy to do for encryption
(just drop produced ICV), but harder to do on decryption - 
you have to tell crypto library that you only want to decrypt
the blob using AEAD algorithm and you don't have ICV for this blob,
and you don't care about this.

The problem is that, as it turned out in mail exchange [1],
most (all?) current crypto libraries don't support this behavior.
In particular - they cannot perform decryption without also checking ICV
and in case the check fails the decryption process doesn't complete.

I can see two possible resolutions of the issue:
1) return back ICV to the wrapping format and continue to re-use
encryption transform for G_IKEv2 messages.
2) add a new registry "Key Wrapping Mechanisms", so that wrapping
format (and the way keys are secured) is determined by 
entries from this registry (e.g. for AES keys it can use RFC 3394).

I slightly prefer option 1, because it seems to be simpler and
doesn't create yet another registry.

Regards,
Valery.

P.S. The issue is also documented at [2]

[1] https://mailarchive.ietf.org/arch/msg/ipsec/-UvEpBRlMeGih8hzXqVGvg5f-RA/
[2] https://github.com/smyslov/G-IKEv2/issues/18



___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] draft-ietf-ipsecme-ikev2-sa-ts-payloads-opt-01 update

[Valery Smyslov]

Hi Tobias,

> > You do not need to make childless IKE SA mandatory, you simply need to
> > do first rekey after initial sa creation using normal rekey, and if
> > that normal rekey has SA/KE payloads that are acceptable for the
> > optimized rekey in the future, then you can use optimized rekeys in
> > the future.
> 
> That's exactly what I'm proposing.  Make it *mandatory* that the first 
> rekeying
> of the Child SA that's created with IKE_AUTH is a regular one.
> Because if that's not the case, it might be impossible for a responder to 
> deduce
> what the initiator's proposal is.  All further rekeyings of that Child SA can 
> be
> optimized afterwards.

Alternatively you may want not to make the first rekey mandatory,
but instead assume that no KE transform is associated with the Child SA
created by IKE_AUTH. In this case optimized rekey will work, but only 
for non-PFS cases - you just don't include KE payload.
 If you want to do optimized rekey with PFS,
then first you have to do full rekey with PFS, so that KE transform
is negotiated.

Actually, we can make the draft more flexible with regard to PFS/noPFS rekeying.
Currently optimized rekey takes all the transforms from the last full rekey,
including KE transform. It means that in situation when one want to 
do every second rekey with PFS (rekey with PFS, then rekey with no PFS, then 
rekey with PFS etc.) optimized rekey is useless (as far as I understand),
because all the properties (including the presence of PFS)
are taken from the last full rekey. With regard to presence of PFS
I think we can relax this - the presence of KE payload
can indicate whether PFS is used.

Regards,
Valery.

> Regards,
> Tobias
> 
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] draft-mglt-ipsecme-ts-dscp

[Valery Smyslov]

Hi Harold,

I have a couple of comments (in addition to the good points made by Scott, 
which I support).

According to RFC 4302 DSCP value is not preserved end-to-end, i.e. intermediate
routers are free to re-classify traffic and thus change DSCP. So, the situation 
is possible,
that peers agree upon using an SA for a traffic with some DSCP, but in fact 
receiving end will get packets with a different DSCP (because it is changed in 
transit).
What is the supposed behavior for the receiver in this case? Drop all traffic?

And another concern. I think that this document tries to improperly use 
existing mechanism.
Traffic selectors negotiated in IKE SA are part of IPsec access control 
mechanism - 
i.e. they are used to cryptographically separate different types of traffic 
(ftp, http, etc.)
and to allow performing access control (based on network characteristics).
In my understanding, DSCP doesn't specify any particular kind of traffic,
so it's strange to me to separate traffic based on its value.

That said, I seem to understand the problem that you are trying to solve 
(correct me if I'm wrong): you want to make sure that if peer A uses
SA1 for, say, high priority traffic, then peer B also use this SA
(and not, say, SA2) for high priority traffic.

If this is the problem, then perhaps it's easier to just introduce a new notify
that will inform peer that this SA is intended to be used for some 
traffic priority. If peer supports this extension, it is supposed 
to also use this SA for this kind of traffic (it if honors this proposal).
So, move from strict negotiation to just announcing.

Regards,
Valery.


> Scott, thank you for your review. Here are the responses to your comments, see
> inline for details.
> 
> Brs
> 
> From: IPsec  On Behalf Of Scott Fluhrer (sfluhrer)
> Sent: Thursday, July 13, 2023 2:58 AM
> To: ipsec@ietf.org
> Subject: [IPsec] draft-mglt-ipsecme-ts-dscp
> 
> Hi,
> 
>I rereviewed this draft, and have a few comments:
> 
> - As the draft is written, the administrator can specify that (for example) 
> traffic
> with DSCP=3 must be protected, but other traffic is not.  I don’t believe 
> giving
> administrators this option is a good idea, it can likely result in a security 
> foot
> gun.
> The current selectors (protocol, IP addresses, ports) specify the traffic 
> type,
> where it is coming from or where it is going to – that is, things that the
> application may check.  For example, if the SPD specifies that TCP traffic to 
> port
> 22 MUST be protected, then someone cannot trick the system into accepting a
> TCP packet to port 22 (without going through authentication).
> DSCP, on the other hand, doesn’t specify the traffic type or 
> source/destination,
> but instead how the traffic should be treated.  And, receiving applications do
> not verify themselves if the DSCP value is what they expect (because network
> devices are free to modify the DSCP value in transit).  Hence, in the above
> scenario where only DSCP=3 traffic is protected, the adversary can inject any
> traffic they like (and just set the DSCP setting to something else).
> It would appear to me that this draft would need to mandate that, if you do
> have a DSCP-specific SPD entry, that traffic that matches that (except for the
> DSCP) must also be protected (either encrypted or discarded).
> 
> 
> When TS_DSCP is agreed, TS_DSCP is just refinement of existing selectors which
> is always used in combination with other selectors and cannot be used "alone",
> in section 3 (Traffic Selector negotiation). This prevents DSCP from inferring
> with other traditional policies. It is also presumed that the IPsec subsystem
> itself would install a REJECT/DISCARD rule in the SPD to prevent that traffic
> from being transmitted without IPsec protection.
> 
> We agree in MANDATING to have the same policy for different DSCP values in
> the security consideration. The traffic that matches TS (except for the DSCP)
> must also be handled and we prefer to have a discard for the default policy 
> that
> is non defined DSCP values when at least one DSCP value has been defined
> (This is because the "bypass" will bring security risks, and the "encryption" 
> will
> cause packets to be encrypted regardless of the DSCP value, which makes
> TS_DSCP lose its original meaning).
> 
> I think the wording of current security consideration is bad, we will refine 
> it.
> 
> 
> - I’m going through the introduction, and quite frankly I don’t understand 
> some
> of the arguments.  For example, consider this text:
> 
>If DSCP values are
>not agreed and between (for example) 2 SAs, it is unlikely the
>initiator and the responder miraculously select the same subset of
>DSCP values over the same SAs.  Instead each peer is likely that
>inbound and outbound traffic take different SA and as such does not
>solve the issue of discarding lower priority packets associated to
>different class of traffic sharing a given SA.
> 
> I’m co

Re: [IPsec] Paul Wouters' Discuss on draft-ietf-ipsecme-add-ike-11: (with DISCUSS and COMMENT)

[Valery Smyslov]

HI Paul,

> > Actually, the format is the same for both request and response,
> > but depending on Num Hash Algs and AND Length and also on Length,
> > some fields may be omitted.
> 
> > The most generic format is:
> >
> > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> > +-+-+---+
> > |R| Attribute Type  |Length |
> > +-+-+---+---+
> > | Num Hash Algs |  ADN Length   |   |
> > +---+---+   +
> > ~Authentication Domain Name ~
> > +---+
> > ~   Digest Hash Alg Identifiers~
> > +---+
> > ~ Certificate Digest~
> > +---+---+
> >
> > Figures 2 and 3 just show how this attribute
> > looks when Num Hash Algs, AND Length and Length
> > have specific values, which make sense for the request and response.
> 
> I do think that is very confusing. I would prefer to see the field
> described once to make it more clear there is only one format.

Do you think the figure above should be added to the document
with fields description?

> But even so, wearing my implementer hat, this is not a friendly format
> to parse as various fields depend on other fields two levels deep.
> That is, I have to read in the data into a struct that has:
> 
> struct ENC_DNS4 {
>   uint32_t attr_type;
>   uint32_t length;
>   int numhash;
>   int adnlen;
>   char *blob
> };
>
> and then kludge around depending on numhash and adnlen. And if there
> are spare bytes left, I guess that must map to a cert digest then.

Sorry, but I don't  buy this argument. IKEv2 has such attributes from
the very beginning. For example, to correctly parse SUPPORTED_ATTRIBUTES
you have to read the data into the similar struct:

struct SUPPORTED_ATTRIBUTES {
uint32_t attr_type;
uint32_t length;
char *blob;
}

and then use length to determine the number of attributes (and the correctness 
of the SUPPORTED_ATTRIBUTES attribute itself). So conformant implementations 
should have no problem with such things.

> compare that to say:
> 
>   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>   +-+-+---+
>   |R| Attribute Type  |Length |
>   +-+-+---+---+
>   | Num Hash Algs |  Digest Hash Alg Identifiers  ~
>   +---+   ~
>   ~   ~
>   +---+
>   ~ Certificate Digest~
>   +---+
>   ~ ADN   ~
>   +---+
> 
> This way we also do not need "ADN Length" anymore. It can state if
> "Num Hash Agls" is not 1, Certificate Digest is omited.

First, you still have to parse this attribute differently
depending on the "Num Hash Agls" value. But worse (wearing my implementation 
hat),
this format is less friendly for parsing. The problem is that 
with the current format the low level parsing routine is able
to correctly separate ADN, Hash Identifiers and Digest without any 
knowledge of their internals and pass these separated pieces 
of data to a higher level routine that actually knows what to do with them.
With your proposed format the low level routine must know 
the length of the Digest field to correctly parse the data, 
which depends on the Hash Identifier. For a low level routine this knowledge 
is generally not available, so I would have to somehow pass this
information there.

> I'm still a little weirded out by how different request/response
> format is - it is supposed to be the same thing, but filled in, and
> the fact that the fields vary is kinda weird.

The format is actually the same, but depending on the request/response
some fields may be omitted. Don't you find it is weird that
in IKEv2 the whole data is omitted in the request if the length of the 
attribute is 0?
I believe we follow the similar logic :-)

Regards,
Valery.

> Paul

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Éric Vyncke's Yes on draft-ietf-ipsecme-add-ike-11: (with COMMENT)

[Valery Smyslov]

Hi Éric,

thank you for your comments. Please see inline
(I will only address some of your comments).

 
> --
> COMMENT:
> --
> 
> Thank you for the work put into this document. It really helps to achieve the
> goals of the ADD WG :-) (only regret is that the IPSECME WGLC was not formally
> extended to the ADD WG, a little more of cross-WG collaboration is always
> welcome even if authors are also very active in ADD).
> 
> Please find below some non-blocking COMMENT points (but replies would be
> appreciated even if only for my own education), and one nit.
> 
> Special thanks to Tero Kivinen for the shepherd's detailed write-up including
> the WG consensus and the justification of the intended status.
> 
> Other thanks to Patrick Mevzek, the DNS directorate reviewer, please consider
> this dns-dir review:
> https://datatracker.ietf.org/doc/review-ietf-ipsecme-add-ike-11-dnsdir-
> telechat-mevzek-2023-04-04/
> (and I have read Med's reply so all it good) and the previous
> https://datatracker.ietf.org/doc/review-ietf-ipsecme-add-ike-09-dnsdir-lc-
> mevzek-2023-03-16/
> (and the authors/chairs have also replied)
> 
> I hope that this review helps to improve the document,
> 
> Regards,
> 
> -éric
> 
> # COMMENTS (non-blocking)
> 
> I second Paul Wouters' DISCUSS point #2 and Zahed's one (even if this may be
> the IPSECME WG usual process, it is not the IETF process).

Are there any formal guidelines that list criteria for marking a document 
"Update" for another document?

What I like about ipsecme position on that - there is a well understood 
criteria:
if new specification requires that legacy implementations be updated,
then the new specification "Updates" an old one. If this is not the case - 
no need to mark it as "Update".

In our case, no change to implementations that are unaware of this document
and only implement RFC 8598 is needed, so this is not (in our opinion) an 
"Update".

> ## Section 1
> 
> In the discussion about private CA / address for the DNS resolver, one more
> sentence stating the obvious (when using a private CA then the client may use
> the digest info payload) would be welcome. Alternatively, moving this
> paragraph
> before the reference to the appendix will make it clearer the link with
> ENCDNS_DIGEST_INFO.
> 
> ## Section 2
> 
> Should RFC 8499 be normative (note RFC 7296 is normative and used in the
> same
> way)?
> 
> ## Section 3.2
> 
> What is the responder behaviour when receiving a CFG_REQUEST with "ADN
> Length"
> different from 0 ? Symmetrical case for the initiator when "Num Hash Algs" is
> not 1 in a CFG_SET. If the generic behaviour described in section 4 (`As a
> reminder, badly formatted attributes or unacceptable fields are handled as per
> Section 2.21 of [RFC7296].`), then why other fields (notably "R") have 
> specific
> text ? The reminder of section 4 should rather be in section 3 (but this is a
> matter of taste).

"R" is a RESERVED field and is treated as any other RESERVED field in IKEv2 - 
its value (whether it is 0 or not) is ignored. We cannot ignore invalid
values in other fields, because the receiver in this case has no clue what
the sender meant.

> `Note that SHA2-256 is mandatory to implement` does this mean that SHA2-
> 256
> identifier *MUST* always be in the list or is it implicit and does not have to
> be in the list ?

I believe not. It is mandatory to implement in general, for operations on the 
Internet.
Mutually consenting parties operating in closed environment may very well 
ignore this MTI requirement
and list only other values.

Regards,
Valery.

> # NITS (non-blocking / cosmetic)
> 
> ## Appendix A.1
> 
> No need to expand VPN as it is both well-known and used before without
> expansion ;)
> 
> 


___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] [CFRG] Use of AEAD algorithms as pure encryption algorithms

[Valery Smyslov]

Hi John,

 

thank you for your comments, please see inline.

 

Hi Valery,

 

Some quick commments.

 

- If the G-IKEv2 engine is not trusted to access information inside the 
messages,

it should probably not be trusted to modify the keys. Chaning the keys would

get however is in control of the G-IKEv2 engine access to information

encrypted with the keys. (The G-IKEv2 can force key reuse as Natanael writes).

 

G-IKEv2 engine is trusted to the extent that it will not 
voluntarily do any bad thing.

There are basically two reasons to not expose keys in clear to the 
G-IKEv2 engine.

First, despite the fact that we trust it, generally the engine may 
be more vulnerable

to some side-channel attacks compared to crypto engine. For example,

its memory may not be as protected as crypto engine's memory,

there may be some electromagnetic emission issues, not existent 

in crypto engine which may be a specially designed HSM, and the like.

Second, usually all the keys reside in crypto engine and never 
leave it in clear, only in wrapped (encrypted) form

(I think that most crypto API don't even allow to export keys in 
clear, but I may be wrong).

 

So, you can imagine the situation that we have two crypto engines -

one on a Group Controller and the other on a Group Member and

we want to transfer a key from the former to the latter.

In this situation we usually wrap the key, transfer it (even via a 
protected channel)

and unwrap on receiver. The idea was to use IKEv2 encryption 
transforms

(which in many cases are in fact AEAD transforms these days) to also

wrap/unwrap the keys, but since we know that the channel is 
protected,

only use an encryption/decryption service of these transforms.



Maybe sending two UDP datagrams is the solution? Or sending less keys and use

a KDF to derive some of the keys?

 

Sending multiple UDP datagrams is possible, but would complicate 
the protocol.

Currently it is assumed that rekey is done with a single UDP 
datagram.

Using KDF looks less desirable, it is assumed that all keys are 
independent

and there is no correlation between them.

 

- I don't think "pure encryption algorithms" is a good term. Authenticated

encryption is "pure encryption" for IND-CCA confidentiality. I.e., 
confidentiality

against active attackers.

 

It was an "ad hoc" term, I'm sure it is far from perfect.

 

- I think is it very good to have a discussion on IND-CPA encryption and APIs 
for that.

While AEAD has a standardized interface C = E(K, N, P, A) in RFC 5116, IND-CPA

encryption do not. The lack of IND-CPA encryption without message expansion and

the lack of a common API are problems. We discussed this in a paper we just

submitted to the NIST LWC workshop.

 

https://github.com/emanjon/Publications/blob/main/Proposals%20for%20Standardization%20of%20the%20Ascon%20Family.pdf

 

The DTLS 1.3 and QUIC specifications use AES-ECB which is secure in their case 
as the plaintext is a single block, but

I have met people believing that AES-ECB is now ok in general as DTLS and QUIC 
use it. It would have been easier if each AEAD algorithm had an IND-CPA mode. 
But people using IND-CPA when they should not are also a big problem…

 

I understand.

 

How should a general interface for IND-CPA look like? Should it be

 

C = E(K, N, P)

 

or should it be a special case of the AEAD interface with a zero length tag and 
A = ""?

 

C = E(K, N, P, "")

 

Or with a NULL (if we map this to C++)?

 

C = E(K, N, P, NULL)

 

Regards,

Valery.

 

Cheers,

John

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Paul Wouters' Discuss on draft-ietf-ipsecme-add-ike-11: (with DISCUSS and COMMENT)

[Valery Smyslov]

Hi Paul,

thank you for your comments, please see inline.

> Paul Wouters has entered the following ballot position for
> draft-ietf-ipsecme-add-ike-11: Discuss
> 
> --
> DISCUSS:
> --
> 
> I have a few important items I believe needs fixing, but I believe those are
> still fairly easy to address.
> 
> #1 payload format of ENCDNS_DIGEST_INFO
> 
> I believe the proposed syntax for ENCDNS_DIGEST_INFO in this document
> should not be specified this way. Depending on the use of this payload,
> it has a different field construction. That is, we have two different
> kinds of ENCDNS_DIGEST_INFO, which would make defining this field (eg in
> C headers or in a class object) impossible without splitting it into two
> different names and definitions. Either all the fields must be identical,
> with optional 0 lengths field omitted, or the draft should define
> ENCDNS_DIGEST_INFO_REQUEST and ENCDNS_DIGEST_INFO_RESPONSE with
> their different
> field types. This can be further seen by the difficulty to read the examples
> in the appendici with the ENCDNS_DIGEST_INFO() syntax.
> 
> If one ENCDNS_DIGEST_INFO type is used, I think the syntax for both request
> and response should be:
> 
>  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> +-+-+---+
> |R| Attribute Type  |Length |
> +-+-+---+---+
> | Num Hash Algs |  ADN Length   |   |
> +---+---+   +
> ~Authentication Domain Name ~
> +---+---+
> | Digest Hash Alg Identifier|   ~
> +---+   +
> ~ Certificate Digest~
> +---+---+
> 
> (eg as the current "response" version)

Actually, the format is the same for both request and response,
but depending on Num Hash Algs and AND Length and also on Length,
some fields may be omitted.

The most generic format is:

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+---+
|R| Attribute Type  |Length |
+-+-+---+---+
| Num Hash Algs |  ADN Length   |   |
+---+---+   +
~Authentication Domain Name ~
+---+
~   Digest Hash Alg Identifiers~
+---+
~ Certificate Digest~
+---+---+

Figures 2 and 3 just show how this attribute
looks when Num Hash Algs, AND Length and Length 
have specific values, which make sense for the request and response.

> And Num Hash Algs, ADN Length and Digest Hash Alg Identifier
> are mandatory fields in both the request and the response. I would
> also always list these 3 fields in the presentation format of
> ENCDNS_DIGEST_INFO() as used in the appendici examples.
> 
> I would rename "Hash Alg Identifier" to "Digest Hash Alg Identifier"
> to make it more obvious that is what the hash algorithm is for.
> 
> #2 Updates RFC 8598
> 
> Note: [RFC8598] requires INTERNAL_IP6_DNS (or INTERNAL_IP4_DNS)
> attribute to be mandatory present when INTERNAL_DNS_DOMAIN is
> included. This specification relaxes that constraint
> 
> This clearly updates RFC8598, but the document is lacking an Update: clause.
> Please add the Update clause and mention the update in the
> abstract/introduction.

It was discussed in the ipsecme WG. The conclusion is that the "Update"
clause is only needed if a new specification changes the behavior of 
legacy implementations. In other words, if you need to fix old implementations
even if they don't support new specification - then you should mark
this new specification as "Update" for an old. This is not the case,
the specified behavior is only relevant to implementations supporting
encrypted DNS. If they don't - they follow RFC 8598.

This is a long time approach in ipsecme WG, otherwise every new
extension to IKEv2 would update RFC 7296  (which is not the case). 

> #3 Security Considerations
> 
> The initiator may trust the encrypted DNS resolvers supplied by
> means of IKEv2 from a trusted responder more than the locally
> provided DNS resolvers, especially in the case of connecting
> to unknow

Re: [IPsec] [CFRG] Use of AEAD algorithms as pure encryption algorithms

[Valery Smyslov]

Hi John,

 

thank you for the comments, please see inline.

 

 

Hi Valery,

 

Some quick commments.

 

- If the G-IKEv2 engine is not trusted to access information inside the 
messages,

it should probably not be trusted to modify the keys. Chaning the keys would

get however is in control of the G-IKEv2 engine access to information

encrypted with the keys. (The G-IKEv2 can force key reuse as Natanael writes).

 

G-IKEv2 engine is trusted to the extent that it will not 
voluntarily do any bad thing.

There are basically two reasons to not expose keys in clear to the 
G-IKEv2 engine.

First, despite the fact that we trust it, generally the engine may 
be more vulnerable

to some side-channel attacks compared to crypto engine. For example,

its memory may not be as protected as crypto engine's memory,

there may be some electromagnetic emission issues, not existent 

in crypto engine which may be a specially designed HSM, and the like.

Second, usually all the keys reside in crypto engine and never 
leave it in clear, only in wrapped (encrypted) form

(I think that most crypto API don't even allow to export keys in 
clear, but I may be wrong).

 

So, you can imagine the situation that we have two crypto engines -

one on a Group Controller and the other on a Group Member and

we want to transfer a key from the former to the latter.

In this situation we usually wrap the key, transfer it (even via a 
protected channel)

and unwrap on receiver. The idea was to use IKEv2 encryption 
transforms

(which in many cases are in fact AEAD transforms these days) to also

wrap/unwrap the keys, but since we know that the channel is 
protected,

only use an encryption/decryption service of these transforms.



Maybe sending two UDP datagrams is the solution? Or sending less keys and use

a KDF to derive some of the keys?

 

Sending multiple UDP datagrams is possible, but would complicate 
the protocol.

Currently it is assumed that rekey is done with a single UDP 
datagram.

Using KDF looks less desirable, it is assumed that all keys are 
independent

and there is no correlation between them.

 

- I don't think "pure encryption algorithms" is a good term. Authenticated

encryption is "pure encryption" for IND-CCA confidentiality. I.e., 
confidentiality

against active attackers.

 

It was an "ad hoc" term, I'm sure it is far from perfect.

 

- I think is it very good to have a discussion on IND-CPA encryption and APIs 
for that.

While AEAD has a standardized interface C = E(K, N, P, A) in RFC 5116, IND-CPA

encryption do not. The lack of IND-CPA encryption without message expansion and

the lack of a common API are problems. We discussed this in a paper we just

submitted to the NIST LWC workshop.

 

https://github.com/emanjon/Publications/blob/main/Proposals%20for%20Standardization%20of%20the%20Ascon%20Family.pdf

 

The DTLS 1.3 and QUIC specifications use AES-ECB which is secure in their case 
as the plaintext is a single block, but

I have met people believing that AES-ECB is now ok in general as DTLS and QUIC 
use it. It would have been easier if each AEAD algorithm had an IND-CPA mode. 
But people using IND-CPA when they should not are also a big problem…

 

I understand.

 

How should a general interface for IND-CPA look like? Should it be

 

C = E(K, N, P)

 

or should it be a special case of the AEAD interface with a zero length tag and 
A = ""?

 

C = E(K, N, P, "")

 

Or with a NULL (if we map this to C++)?

 

C = E(K, N, P, NULL)

 

Regards,

Valery.

 

Cheers,

John

 

From: CFRG mailto:cfrg-boun...@irtf.org> > on behalf of 
Valery Smyslov mailto:smyslov.i...@gmail.com> >
Date: Friday, 21 April 2023 at 09:44
To: 'Natanael' mailto:natanae...@gmail.com> >
Cc: c...@ietf.org <mailto:c...@ietf.org>  mailto:c...@ietf.org> 
>, 'IPsecME WG' mailto:ipsec@ietf.org> >
Subject: Re: [CFRG] Use of AEAD algorithms as pure encryption algorithms

Hi Natanael,

 

thank you for your response, please see inline.

 

Den tors 20 apr. 2023 09:42Valery Smyslov < <mailto:smyslov.i...@gmail.com> 
smyslov.i...@gmail.com> skrev:

Hi,

I have a question to the crypto community regarding the use of AEAD algorithms 
as pure
encryption algorithms. The use case is as follows.

In G-IKEv2 ( <https://datatracker.ietf.org/doc/draft-ietf-ipsecme-g-ikev2/> 
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-g-ikev2/) we have a 
situation
where keys are transferred inside the G-IKEv2 message. The message itself is 
encrypted and
integrity protected. In a

Re: [IPsec] [CFRG] Use of AEAD algorithms as pure encryption algorithms

[Valery Smyslov]

Hi Natanael,

 

thank you for your response, please see inline.

 

Den tors 20 apr. 2023 09:42Valery Smyslov <  
smyslov.i...@gmail.com> skrev:

Hi,

I have a question to the crypto community regarding the use of AEAD algorithms 
as pure
encryption algorithms. The use case is as follows.

In G-IKEv2 (https://datatracker.ietf.org/doc/draft-ietf-ipsecme-g-ikev2/) we 
have a situation
where keys are transferred inside the G-IKEv2 message. The message itself is 
encrypted and
integrity protected. In addition, each of individual keys inside this message 
is encrypted too
with a different key(s) (it can be the same key for all encrypted keys or 
different key for each encrypted key,
but in any case these keys are different from the key protecting the message).
The reason for this construction is to prevent the G-IKEv2 engine which forms 
and parses 
messages from accessing any sensitive information inside the messages.

The algorithm for protecting the message itself and individual keys inside the 
message is the same - 
it is one of IKEv2 Encryption transforms 
https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-5
The reason for this is to simplify implementations - the algorithm for 
protecting the message will be 
supported anyway, so there seems to be no reason to negotiate another one.
In many cases this algorithm will be an AEAD algorithm (like AES-GCM).

The problem is that there may be quite a lot of encrypted keys inside a single 
message,
and since G-IKEv2 operates over UDP (and over multicast!), the size of the 
message matters - 
large messages will be fragmented by IP level and due to known issues with 
firewalls
might not get through, so we want to make the message small. And for each 
protected key 
the authentication tags would consume almost the same space, as the encrypted 
content.

So, the design is that even when using an AEAD algorithm, the individual
keys inside the protected message are only encrypted and their authentication 
tags produced by the AEAD algorithm,
are not transmitted. On a receiving side it must be possible to decrypt keys 
without performing an integrity check.
Note, that the message itself is encrypted and integrity protected, so we are 
sure that all message content, 
including all encrypted keys, is not altered.

My questions to the crypto community:
1. Is it generally OK to use AEAD algorithms as pure ciphers.
2. Do existing APIs to AEAD algorithms allow to decrypt an encrypted blob 
without checking its integrity.

Regards,
Valery.

 

1: No, in the general case. It's not a good idea. But there's options (see 
below).

 

Especially given that many common AEAD ciphers are built on stream ciphers they 
are trivially malleable if you don't check the authentication, so if an 
adversary knows a single plaintext block they can modify it to decrypt to 
anything they wish. You get none of the guarantees they're intended to give if 
you don't use them as intended.

 

  Yes, I’m aware of this.

 

In the context of your example this allows the adversary to eg. resend old 
keys, possibly forcing key reuse elsewhere.

 

  No, it is not possible in my use case. The message, which contains 
encrypted keys, is always

  encrypted and authenticated using the same AEAD algorithm, and 
G-IKEv2 provides replay protection,

  so no external adversary can either see or manipulate the keys.

 

*Even if* the individual keys have their own layer of authenticated encryption 
inside the encrypted stream, the authentication should bind to the session to 
prevent replays and more.

 

  As I’ve already said, replays are not possible. And there is a 
binding of these keys to a session too.

 

2: I think most APIs prevent it - in addition some algorithms makes it 
impossible, intentionally. See SCRAM;

 

https://github.com/aws/s2n-tls/tree/main/scram

 

  Thank you for the pointer.

 

You do have other options. If you prepend a signed/authenticated Merkle Tree 
hash which cover the set of encrypted keys then they can be individually 
verified against the Merkle root without decrypting the entire message. This 
signature can then also bind the key bundle to the session. The size overhead 
can be some kilobytes. If this is worth it depends on what you mean with "quite 
a lot of keys". Several hundreds or more? Could be worth doing. Just some 
dozen? Not really.

 

  Well, let me be more specific. G-IKEv2 operates over UDP, so the 
message size should be less than path MTU to avoid IP fragmentation.

  In most cases it is 1500 bytes, but can be smaller, say 576 bytes. 
There are some other stuff in the message besides keys,

  so it is generally about from 300 to 1250 bytes are available for 
keys. To exclude a user from the group using LKH algorithm (RFC 2627)

  we have to send as many keys, as the height of the key tree, which is 
determin

[IPsec] Use of AEAD algorithms as pure encryption algorithms

[Valery Smyslov]

Hi,

I have a question to the crypto community regarding the use of AEAD algorithms 
as pure
encryption algorithms. The use case is as follows.

In G-IKEv2 (https://datatracker.ietf.org/doc/draft-ietf-ipsecme-g-ikev2/) we 
have a situation
where keys are transferred inside the G-IKEv2 message. The message itself is 
encrypted and
integrity protected. In addition, each of individual keys inside this message 
is encrypted too
with a different key(s) (it can be the same key for all encrypted keys or 
different key for each encrypted key,
but in any case these keys are different from the key protecting the message).
The reason for this construction is to prevent the G-IKEv2 engine which forms 
and parses 
messages from accessing any sensitive information inside the messages.

The algorithm for protecting the message itself and individual keys inside the 
message is the same - 
it is one of IKEv2 Encryption transforms 
https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-5
The reason for this is to simplify implementations - the algorithm for 
protecting the message will be 
supported anyway, so there seems to be no reason to negotiate another one.
In many cases this algorithm will be an AEAD algorithm (like AES-GCM).

The problem is that there may be quite a lot of encrypted keys inside a single 
message,
and since G-IKEv2 operates over UDP (and over multicast!), the size of the 
message matters - 
large messages will be fragmented by IP level and due to known issues with 
firewalls
might not get through, so we want to make the message small. And for each 
protected key 
the authentication tags would consume almost the same space, as the encrypted 
content.

So, the design is that even when using an AEAD algorithm, the individual
keys inside the protected message are only encrypted and their authentication 
tags produced by the AEAD algorithm,
are not transmitted. On a receiving side it must be possible to decrypt keys 
without performing an integrity check.
Note, that the message itself is encrypted and integrity protected, so we are 
sure that all message content, 
including all encrypted keys, is not altered.

My questions to the crypto community:
1. Is it generally OK to use AEAD algorithms as pure ciphers.
2. Do existing APIs to AEAD algorithms allow to decrypt an encrypted blob 
without checking its integrity.

Regards,
Valery.


___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] I-D Action: draft-ietf-ipsecme-g-ikev2-09.txt

[Valery Smyslov]

Hi,

a new version of the draft is published.

It addresses issues from Daniel's (first part), Gorry's and Russ' reviews.
Daniel was going to complete the second part of his review soon,
but there are already quite a lot of (mostly minor) changes, so I think it's 
worth 
to publish a new version now.

Regards,
Valery.

> -Original Message-
> From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of 
> internet-dra...@ietf.org
> Sent: Wednesday, April 19, 2023 11:10 AM
> To: i-d-annou...@ietf.org
> Cc: ipsec@ietf.org
> Subject: [IPsec] I-D Action: draft-ietf-ipsecme-g-ikev2-09.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This Internet-Draft is a work item of the IP Security Maintenance
> and Extensions (IPSECME) WG of the IETF.
> 
>Title   : Group Key Management using IKEv2
>Authors : Valery Smyslov
>  Brian Weis
>Filename: draft-ietf-ipsecme-g-ikev2-09.txt
>Pages   : 71
>Date: 2023-04-19
> 
> Abstract:
>This document presents an extension to the Internet Key Exchange
>version 2 (IKEv2) protocol for the purpose of a group key management.
>The protocol is in conformance with the Multicast Security (MSEC) key
>management architecture, which contains two components: member
>registration and group rekeying.  Both components require a Group
>Controller/Key Server to download IPsec group security associations
>to authorized members of a group.  The group members then exchange IP
>multicast or other group traffic as IPsec packets.
> 
>This document obsoletes RFC 6407.  This documents also updates RFC
>7296 by renaming a transform type 5 from "Extended Sequence Numbers
>(ESN)" to the "Replay Protection (RP)" and by renaming IKEv2
>authentication method 0 from "Reserved" to "NONE".
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-g-ikev2/
> 
> There is also an htmlized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-g-ikev2-09
> 
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-ipsecme-g-ikev2-09
> 
> Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts
> 
> 
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Secdir early review of draft-ietf-ipsecme-g-ikev2-08

[Valery Smyslov]

HI Russ,

thank you for the follow-up. Please see inline (I snipped text where we are in 
agreement).

> -Original Message-
> From: Russ Housley [mailto:hous...@vigilsec.com]
> Sent: Tuesday, April 18, 2023 9:29 PM
> To: Valery Smyslov
> Cc: IETF SecDir; draft-ietf-ipsecme-g-ikev2@ietf.org; IETF IPsec
> Subject: Re: Secdir early review of draft-ietf-ipsecme-g-ikev2-08

> >> Major Concerns:
> >>
> >> Throughout: RFC 7296 says that SK operations are "Encrypted and
> >> Authenticated".  However, several places we see SK{}.  What is being
> >> authenticated and encrypted in such cases.  Similarly, there are
> >> several places where all of the items in SK{ ... } are optional.
> >> What is being authenticated and encrypted if they are all absent?
> >> Maybe I am missing something, but I think some discussion of the
> >> notation would be helpful.
> >
> > SK{...} denotes the "Encrypted payload" (Section 3.14 of RFC 7296).
> > An empty Encrypted Payload is used in RFC 7296 in several cases -
> > when peer should send something to complete the exchange, but
> > there is really nothing meaningful to send. In reality the content
> > of the "empty" payload is not null - it contains the mandatory Pad Length
> > field and an optional padding (for counter-based encryption algorithms
> > there is no padding). So, when sending SK{}, a peer actually sends
> > one encrypted zero byte (for counter-based modes) and authenticates
> > the whole message including the IKE header.
> >
> > There is nothing new in G-IKEv2 with this regard comparing to RFC 7296.
> > I don't think any clarification about notation is needed - we have dozens 
> > of IKEv2
> > extension RFCs which already use this notation with no clarification and in 
> > addition
> > readers are supposed to be familiar with RFC 7296. Or should we say this 
> > explicitly?
> 
> Thanks.  I would say near the beginning that the conventions from  RFC 7296 
> are used here.  That would
> have caused me to look more carefully.

I've added a sentence into the Terminology section:

   This document uses a notation and conventions from [RFC7296] for
   describing G-IKEv2 payloads and exchanges.

Is it enough?

[snip]

> >> Section 1: The IKE_INTERMEDIATE exchange is discussed later in the
> >> document, but the Introduction does not lay the ground work for it.
> >
> > The introduction is mostly concerned with group key management
> > architecture and terminology, since they a bit different from what
> > IPsec folks are accustomed to. IKE_INTERMEDIATE is not specific
> > to group key management, so it is not mentioned there.
> > It is mentioned later to make clear that besides IKE_SA_INIT+GSA_AUTH
> > other exchanges, defined as IKEv2 extensions, can also be used.
> >
> > If I missed your point, then can you please elaborate?
> 
> I think the Introduction needs to says that IKE_INTERMEDIATE can be used and 
> provide a reference.  I
> was a bit surprised when it came up much later in the document.

I've updated the second para in Section 2.1 as follows:

   G-IKEv2 is compatible with most IKEv2 extensions defined so far.  In
   particular, it is assumed that, if necessary, the IKE_INTERMEDIATE
   exchanges [RFC9242] may be utilized while establishing the
   registration SA.  It is also believed that future IKEv2 extensions
   will be possible to use with G-IKEv2, however, some IKEv2 extensions
   require special handling when used with G-IKEv2.  See Section 6 for
   more details.

Id it enough?

[snip]

> 
> >> Section 2.4.1.2: The following seems impossible to implement:
> >>
> >>   *  The GCKS must always use IKE fragmentation based on a known
> >>  fragmentation threshold (unspecified in this memo), as there is no
> >>  way to check if fragmentation is needed by first sending
> >>  unfragmented messages and waiting for response.
> >>
> >> There is no hint about how to learn the fragmentation threshold, but
> >> the GCKS MUST NOT use fragmentation unless the fragmentation threshold
> >> is known.
> >
> > It is assumed that fragmentation threshold in this case is pre-configured 
> > by administrator.
> >
> > Should we clarify this? For example:
> >
> >   *  The GCKS must always use IKE fragmentation based on a pre-configured
> >  fragmentation threshold (unspecified in this memo), as there is no
> >  way to check if fragmentation is needed by first sending
> >  unfragmented messages and waiting for response.
> >
> > Is it enough?
> 
&g

Re: [IPsec] Secdir early review of draft-ietf-ipsecme-g-ikev2-08

[Valery Smyslov]

Hi Russ,

thank you for your review. Please see inline.

> -Original Message-
> From: Russ Housley via Datatracker [mailto:nore...@ietf.org]
> Sent: Friday, April 14, 2023 3:56 PM
> To: sec...@ietf.org
> Cc: draft-ietf-ipsecme-g-ikev2@ietf.org; ipsec@ietf.org
> Subject: Secdir early review of draft-ietf-ipsecme-g-ikev2-08
> 
> Reviewer: Russ Housley
> Review result: Not Ready
> 
> I reviewed this document as part of the Security Directorate's ongoing
> effort to review all IETF documents being processed by the IESG.  These
> comments were written primarily for the benefit of the Security Area
> Directors.  Document authors, document editors, and WG chairs should
> treat these comments just like any other IETF Last Call comments.
> 
> Document: draft-ietf-ipsecme-g-ikev2-08
> Reviewer: Russ Housley
> Review Date: 2023-04-05
> IETF LC End Date: 2022-04-30
> IESG Telechat date: Unknown
> 
> Summary: Not Ready
> 
> Major Concerns:
> 
> Throughout: RFC 7296 says that SK operations are "Encrypted and
> Authenticated".  However, several places we see SK{}.  What is being
> authenticated and encrypted in such cases.  Similarly, there are
> several places where all of the items in SK{ ... } are optional.
> What is being authenticated and encrypted if they are all absent?
> Maybe I am missing something, but I think some discussion of the
> notation would be helpful.

SK{...} denotes the "Encrypted payload" (Section 3.14 of RFC 7296).
An empty Encrypted Payload is used in RFC 7296 in several cases - 
when peer should send something to complete the exchange, but 
there is really nothing meaningful to send. In reality the content
of the "empty" payload is not null - it contains the mandatory Pad Length
field and an optional padding (for counter-based encryption algorithms
there is no padding). So, when sending SK{}, a peer actually sends 
one encrypted zero byte (for counter-based modes) and authenticates
the whole message including the IKE header.

There is nothing new in G-IKEv2 with this regard comparing to RFC 7296.
I don't think any clarification about notation is needed - we have dozens of 
IKEv2 
extension RFCs which already use this notation with no clarification and in 
addition 
readers are supposed to be familiar with RFC 7296. Or should we say this 
explicitly?

> Section 1: RFC 3740 defines a GSA as:
> 
>A bundling of Security Associations (SAs) that together define how
>a group communicates securely.  The GSA may include a registration
>protocol SA, a rekey protocol SA, and one or more data security
>protocol SAs.
> 
> However, this introduction only talks about two aspects of the GSA.
> Please state which data security protocol will be used.  I assume it
> supports both ESP and AH.

That's true. I've added a clarification:

  This specification relies on ESP and AH as protocols for 
Data-Security SAs.

> Section 1: The IKE_INTERMEDIATE exchange is discussed later in the
> document, but the Introduction does not lay the ground work for it.

The introduction is mostly concerned with group key management
architecture and terminology, since they a bit different from what 
IPsec folks are accustomed to. IKE_INTERMEDIATE is not specific
to group key management, so it is not mentioned there. 
It is mentioned later to make clear that besides IKE_SA_INIT+GSA_AUTH 
other exchanges, defined as IKEv2 extensions, can also be used.

If I missed your point, then can you please elaborate?

> Section 2.4.1.1: Please provide some explanatory text prior to:
> 
>DataToAuthenticate = A | P
>GsaRekeyMessage = GenIKEHDR | EncPayload
>GenIKEHDR = [ four octets 0 if using port 4500 ] | AdjustedIKEHDR
>AdjustedIKEHDR =  SPIi | SPIr |  . . . | AdjustedLen
>EncPayload = AdjustedEncPldHdr | IV | InnerPlds | Pad | PadLen | ICV
>AdjustedEncPldHdr = NextPld | C | RESERVED | AdjustedPldLen
>A = AdjustedIKEHDR | AdjustedEncPldHdr
>P = InnerPlds

This notation follows a similar one from RFC 7296 (Section 2.15)
and RFC 9242 (3.3.2). 

We can add some text before this, for example:

The input to the authentication algorithm that computes 
the content of the AUTH payload can be described as:

Is it enough?

> Section 2.4.1.2: The following seems impossible to implement:
> 
>*  The GCKS must always use IKE fragmentation based on a known
>   fragmentation threshold (unspecified in this memo), as there is no
>   way to check if fragmentation is needed by first sending
>   unfragmented messages and waiting for response.
> 
> There is no hint about how to learn the fragmentation threshold, but
> the GCKS MUST NOT use fragmentation unless the fragmentation threshold
> is known.

It is assumed that fragmentation threshold in this case is pre-configured by 
administrator.

Should we clarify this? For example:

   *  The GCKS must always use IKE fragmentation based on a pre-configured
  fragmentation threshold (unspecified in this memo), as there i

Re: [IPsec] I-D Action: draft-ietf-ipsecme-g-ikev2-08.txt

[Valery Smyslov]

HI Daniel,

 

thanks for the follow-up, please see inline (some text is snipped, where we are 
in agreement).

 

From: Daniel Migault [mailto:mglt.i...@gmail.com] 
Sent: Friday, April 14, 2023 11:39 PM
To: Valery Smyslov
Cc: ipsec@ietf.org
Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-g-ikev2-08.txt

 

Hi Valery, 

 

Thanks for the follow-up please find inline my response to your comment. Thank 
you for the clarifications  and all my comments have been responded to.

 

Yours, 
Daniel

 

 

[snipped]


1.  Introduction and Overview

   A group key management protocol provides IPsec keys and policy to a
   set of IPsec devices which are authorized to communicate using a
   Group Security Association (GSA) defined in [RFC3740].

This is a nit but I believe that saying striaght forward 
"""
This document presents an extension to
   IKEv2 [RFC7296] called G-IKEv2, that allows to perform a group key
   management.

"""

may be clearer. 



 

  This is exactly what is written a few lines below in the same para :-)

Absolutely, as far as I remember, what I meant is that mentioning this sentence 
in the beginning tells upfront what the draft is about. Starting with the 
notion of groups management is I think not the reason we have the draft. Again 
that was just a nit.  

 

  OK, I moved this sentence to the beginning of the section.

 

   Large and small groups may use different sets of these protocols.
   When a large group of devices are communicating, the GCKS is likely
   to use the GSA_REKEY message for efficiency.  This is shown in
   Figure 1.  (Note: For clarity, IKE_SA_INIT is omitted from the
   figure.)

++
 +->|  GCKS  |<-+
 |  ++  |
 ||^|
 ||||
 || GSA_AUTH|
 ||   or|
 || GSA_REGISTRATION|
 ||||
  GSA_AUTH|| GSA_AUTH
or   GSA_REKEY |   or
  GSA_REGISTRATION|| GSA_REGISTRATION
 ||||
 |   ++-+   |
 |   ||||   |
 v   vvvv   v
   +---++++---+
   |  GM   |  ...   |   GM   |  ...   |  GM   |
   +---++++---+
   ^ ^^
   | ||
   +---ESP---+---ESP--+

   Figure 1: G-IKEv2 used in large groups


It might be helpful to indicate (inidvidual) IKE channel while the ESP SA is 
shared between all GMs. 

 

  I think that individual IKE SAs are already shown (GSA_AUTH or 
GSA_REGISTRATION). Am I missing your point?

  Or do you want to change them to “IKE SA”?

 

I do not remember what I had exactly in mind, but I think it might be to 
indicate just IKE  versus ESP to make it clear GSA messages are IKE messages.

 

  I’m a bit unsure how to better do it. I’ve added labels indicating 
IKE SAs, probably this suffice?

  Formally we should also label multicast communications, but I’m not 
sure how to do it.

  Make them in double lines (==)?

   [snip]

-  Data Security SA (DATA): A multicast SA between each multicast

  source speaker and the group's receivers.  There may be as many

  data SAs as there are multicast sources allowed by the group's

  policy.

 

   which I like more. Should we use this instead?

   Then the definition of Rekey SA must also be changed.

 

I find it may be confusing to have policies in the definition of an SA, so the 
second seems clearer to me, but I am not pushing too much. Pick whatever you 
believe is better. 

 

  I changed definitions of Data-Security SA and Rekey SA to better 
match RFC 3740 (which is clearer in my opinion).

  But still, the draft uses “policy” as synonym for “SA” very 
extensively (alas). I find this  confusing too, but this text was there from 
ancient times...

 

 

  [snip]

 

2.  G-IKEv2 Protocol

2.1.  G-IKEv2 Integration into IKEv2 Protocol

   G-IKEv2 is an extension to IKEv2 and uses its security mechanisms
   (peer authentication, confidentiality, message integrity) to ensure
   that only authenticated devices have access to the group policy and
   keys.  G-IKEv2 further provides group authorization, and secure
   policy and key download from the 

Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-auth-announce-03.txt

[Valery Smyslov]

Hi,

this new version addresses issues raised by Paul (I hope I didn't miss any).

Regards,
Valery.

> -Original Message-
> From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of 
> internet-dra...@ietf.org
> Sent: Friday, April 14, 2023 5:52 PM
> To: i-d-annou...@ietf.org
> Cc: ipsec@ietf.org
> Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-auth-announce-03.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This Internet-Draft is a work item of the IP Security Maintenance
> and Extensions (IPSECME) WG of the IETF.
> 
>Title   : Announcing Supported Authentication Methods in IKEv2
>Author  : Valery Smyslov
>Filename: draft-ietf-ipsecme-ikev2-auth-announce-03.txt
>Pages   : 11
>Date: 2023-04-14
> 
> Abstract:
>This specification defines a mechanism that allows the Internet Key
>Exchange version 2 (IKEv2) implementations to indicate the list of
>supported authentication methods to their peers while establishing
>IKEv2 Security Association (SA).  This mechanism improves
>interoperability when IKEv2 partners are configured with multiple
>different credentials to authenticate each other.
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-auth-announce/
> 
> There is also an htmlized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-ikev2-auth-announce-03
> 
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-ipsecme-ikev2-auth-announce-03
> 
> Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts
> 
> 
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Review of draft-ietf-ipsecme-ikev2-auth-announce-02

[Valery Smyslov]

HI Paul,

> >> There is text about IDi/IDr payloads being used in IKE_INTERMEDIATE and
> >> then talk about SHOULD be identical to the ones in IKE_AUTH. I would 
> >> prefer a
> >> different notify for this (eg SAM_IDi/SAM_IDr) to avoid implementers
> >> confusing/erroring on confusing these with the real IDi/IDr payloads.
> >
> > Hm, I'm not sure this would help implementers. Currently they have some
> > code that prepares IDi/IDr and they can re-use it for IKE_INTERMEDIATE.
> 
> We use a state machine based on the payload types. But also we read in
> structures are store them based on the type. Now I have to be careful
> that I don't change the state's IDi/IDr midway and run into security
> issues.

OK, I see your point. We use similar approach, but payload processing
is also dependent on the exchange it is encountered (in addition to its type),
so there is no problem to have same payloads in different exchanges for our 
implementation.

I'm a bit reluctant to add new notifies for this purpose (following the Occam's 
Razor principle),
but is this is a real problem for your implementation, then we can introduce
SAM_IDI and SAM_IDR notifications, which content would have been formatted
as IDi/IDr payloads body. So, the exchange would look like:

   Initiator  Responder
   ------
   HDR, SAi1, KEi, Ni -->
  <-- HDR, SAr1, KEr, Nr, [CERTREQ,]
  [N(SUPPORTED_AUTH_METHODS)()]

   HDR, SK {..., [N(SAM_IDI), [N(SAM_IDR),]]}  -->
  <-- HDR, SK {..., [CERTREQ,]
  [N(SUPPORTED_AUTH_METHODS)(...)] }

   HDR, SK {IDi, [CERT,] [CERTREQ,]
   [IDr,] AUTH, SAi2, TSi, TSr,
   [N(SUPPORTED_AUTH_METHODS)(...)] }  -->
  <-- HDR, SK {IDr, [CERT,]
   AUTH, SAr2, TSi, TSr }

Alternatively, we may stick with IDi/IDr, but require that they MUST be 
identical to those in IKE_AUTH.
Which approach is better for you?

> >> There are two methods described, one for old style RSA/ECDSA and one for
> >> Digital Signatures (RFC 7247, auth method 14). I would prefer to not 
> >> support
> >> the old style, as we are trying to obsolete those. These use undesirable
> >> features anyway (RSA v1.5, sha-1, etc)
> >
> > That's a fair point. But what if some new authentication method appears in 
> > the future,
> > that will unambiguously identify the authentication algorithm (so no 
> > additional information
> > like AlgorithmIdentifier is needed? I prefer to keep the format (anyway, it 
> > is mostly the same,
> > only length matters), but state, that currently this format (Len = 3) is 
> > not used.
> 
> That's fine with me.

Hmm, I checked RFC 8247 and it appears that "RSA Digital Signature" (1) is the 
only
digital signature authentication method that is currently a MUST.

Obviously, we cannot say "don't use MTI method with this extension" :-)
So, I'd rather leave the text as is for now.

> >> There are oddities with the CERTREQ payload. Some implementations using a
> >> list of hashes in 1 CERTREQ, others using 1 hash per CERTREQ. This makes 
> >> using
> >> a numbered cert link number a bit tricky. (eg number 2 of the 3rd CERTREQ).
> >
> > The draft assumes that a single list of CAs from all CERTREQ payloads is 
> > formed,
> > so, the link contains the position of the CA from this list.
> >
> >> I'd much rather select based on hash, not number.
> >
> > It is possible, but will consume 19 bytes more for each announcement.
> > I also don't like that the information is duplicated in this case -
> > both CERTREQ and SUPPORTED_AUTH_METHODS will contain the same hashes.
> > It's better get rid of CERTREQ in this case, but this will break 
> > interoperability
> > with unsupported implementations.
> 
> I think in general when you have a CERTREQ payload and hashes of CAs,
> then you can derive the authentication method from it, as it will be
> the same as the CA used to sign the EE cert. That authentication method
> should be used to sigh the AUTH payload as well. And in most (sane)
> cases there is only 1 hash. I have seen CERTREQs with CA hashes of the
> entire webpki but I consider those to be a fatal error deployment.
> 
> So I don't think the cost isn't that big.
> 
> >> Additionally, implementations might build the CERTREQ payload and then
> >> throw it away. I wouldn't want to need to keep those around for this
> >> extension.
> >
> > My understanding, that when you receive a message, you start parsing it.
> > Until you fully parse it, you unlikely throw it away. The protocol currently
> > is constructed in such a way, that SUPPORTED_AUTH_METHOFS and CERTREQ are 
> > in the same
> message,
> > except for one case - when the responder sends this information in 
> > IKE_INTERMEDIATE.
> > It is possible to modify the protocol to duplicate CERTREQ 

Re: [IPsec] New Version Notification for draft-smyslov-ipsecme-ikev2-qr-alt-07.txt

[Valery Smyslov]

Hi,

a new version of the draft has been published.
It addresses issue with mismatched PPKs and also adds some clarifications on 
interaction with RFC 8784.

As it was discussed at the IETF116 IPSECME meeting, 
once the new version is published, a call for adoption would  be issued.

Chairs, can you please issue an adoption call?

Regards,
Valery.

> -Original Message-
> From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
> Sent: Friday, April 14, 2023 10:32 AM
> To: Valery Smyslov
> Subject: New Version Notification for 
> draft-smyslov-ipsecme-ikev2-qr-alt-07.txt
> 
> 
> A new version of I-D, draft-smyslov-ipsecme-ikev2-qr-alt-07.txt
> has been successfully submitted by Valery Smyslov and posted to the
> IETF repository.
> 
> Name: draft-smyslov-ipsecme-ikev2-qr-alt
> Revision: 07
> Title:Alternative Approach for Mixing Preshared Keys in IKEv2 
> for Post-quantum Security
> Document date:2023-04-14
> Group:Individual Submission
> Pages:9
> URL:
> https://www.ietf.org/archive/id/draft-smyslov-ipsecme-ikev2-qr-alt-07.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-smyslov-ipsecme-ikev2-qr-alt/
> Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-smyslov-ipsecme-ikev2-qr-alt
> Diff:   
> https://author-tools.ietf.org/iddiff?url2=draft-smyslov-ipsecme-ikev2-qr-alt-07
> 
> Abstract:
>An IKEv2 extension defined in [RFC8784] allows IPsec traffic to be
>protected against someone storing VPN communications today and
>decrypting it later, when (and if) cryptographically relevant quantum
>computers are available.  However, this protection doesn't cover an
>initial IKEv2 SA, which might be unacceptable in some scenarios.
>This specification defines an alternative way get protection against
>quantum computers, but unlike the [RFC8784] solution it covers the
>initial IKEv2 SA too.
> 
> 
> 
> 
> The IETF Secretariat


___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] [Tsv-art] Tsvart early review of draft-ietf-ipsecme-g-ikev2-08

[Valery Smyslov]

[snip]

> >>> The packet loss cannot trigger retransmissions, because there is no
> >>> back channel from GMs to GCKS. However, there are mechanisms
> >>> that allow receiving GMs that miss the next GSA_REKEY message to recover
> >>> (see Sections 2.4.1.3 and 4.4.2.2.3).
> >> [GF] I understand now, could the ID say something?
> > We can add the following clarification into 2.4.1.4:
> >
> >  Since GSA_REKEY messages are infrequent (typically one per 
> > several hours or,
> >  in extreme cases, several minutes), packet reordering is not a 
> > problem.
> >
> > Is it OK or more text is needed?
> 
> [GF2] Certainly heading in the correct direction, I think this would be
> clearer as:
> 
> GSA_REKEY messages are sent infrequently (typically one per several hours or,
> in extreme cases, several minutes), which is much greater than typical
> network packet reordering intervals.

Excellent! Thank you.

Regards,
Valery.
  
> Best wishes,
> 
> Gorry


___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] [Tsv-art] Tsvart early review of draft-ietf-ipsecme-g-ikev2-08

[Valery Smyslov]

Hi Gorry,

> -Original Message-
> From: Gorry Fairhurst [mailto:go...@erg.abdn.ac.uk]
> Sent: Tuesday, April 11, 2023 7:22 PM
> To: Valery Smyslov; tsv-...@ietf.org
> Cc: draft-ietf-ipsecme-g-ikev2@ietf.org; ipsec@ietf.org
> Subject: Re: [Tsv-art] Tsvart early review of draft-ietf-ipsecme-g-ikev2-08
> 
> On 11/04/2023 14:09, Valery Smyslov wrote:
> > Hi Gorry,
> >
> > thank you for your review. Please see inline.
> See below, marked [GF]
> >> Reviewer: Gorry Fairhurst
> >> Review result: Ready with Issues
> >>
> >> This is an early review of Group Key Management using IKEv2 concerns 
> >> transport
> >> issues. It does not comment on the maturity of security aspects, which are 
> >> the
> >> primary concerns of the specification.
> >>
> >> Transport issues that may be relevant:
> >>
> >> 1. PMTUD and PLPMTUD are transport mechanisms. In 2.4.1.2. mention is made 
> >> of
> >> PMTUD, bit it was not clear to what was intended and what needs to be done:
> >> /PMTU probing cannot be performed due to lack of GSA_REKEY response 
> >> message./
> >> Some additional text, and a cross reference to a section in another RFC 
> >> would
> >> seem helpful here: What is /probing/ in this context? Maybe it would help 
> >> to
> >> explain a little and cite an RFC for PMTUD, if that is what is intended?
> > This piece of text is not related to classic PMTUD/PLMTUD mechanisms.
> > Instead, it is related to the PMTUD process described in Section 2.5.2 of 
> > RFC 7383,
> > which is a bit specific (sender starts from larger packets and retransmits
> > smaller packets if it receives no reply).
> >
> > We can clarify this. How about the following?
> >
> > *  PMTU mechanism, defined in Section 2.5.2 of [RFC7383], cannot be 
> > used due to lack of
> GSA_REKEY response
> >messages.
> [GF] Aha - that text would indeed be clearer.

OK.

> >> 2. The document discuses protection from replay, but it seems the mechanism
> >> will also impacted by the effect of path reordering, and that interaction
> >> should be described to explain that packet re-ordering can occur on some
> >> Internet paths and how this will impact Replay/Reflection Attack 
> >> Protection,
> >> presumably it will simply result in some packet loss? Could it trigger
> >> retransmission?
> > If we are talking about GSA_REKEY messages, then the replay protection
> > mechanism (incrementing counter) will cause packets loss in case of 
> > reordering.
> > In other words, if GM receives message with MessageID equal to N,
> > it will then ignore any messages with MessageID <= N.
> >
> > However, in real life this should not cause problems, because
> > GSA_REKEY messages are infrequent (usually one per few hours,
> > in extreme cases one per several minutes).
> >
> > The packet loss cannot trigger retransmissions, because there is no
> > back channel from GMs to GCKS. However, there are mechanisms
> > that allow receiving GMs that miss the next GSA_REKEY message to recover
> > (see Sections 2.4.1.3 and 4.4.2.2.3).
> [GF] I uinderstand now, could the ID say something?

We can add the following clarification into 2.4.1.4:

Since GSA_REKEY messages are infrequent (typically one per several 
hours or, 
in extreme cases, several minutes), packet reordering is not a 
problem.

Is it OK or more text is needed?

> >> 3. RFC8055 describes BCP guidance for congestion control: Retransmission is
> >> described in 2.4.1.3. Are the retransmitted messages subject to congestion
> >> control? or some form of rate limit? There is a maximum interval for
> >> retransmission discussed, but there is not a mention of a minimum 
> >> interval, or
> >> what happens when a retransmission fails? Specifically, is the 
> >> retransmission
> >> time period backed-off, or is there a limit on the of retries?
> > No, there is no congestion control, because there is no back channel from 
> > GMs to GCKS.
> > It is assumed that the GSA_REKEY messages are infrequent to not cause
> > any congestion. If several GSA_REKEY messages are sent to mitigate possible 
> > packet loss,
> > then the draft suggests that they are not sent at once, but instead be sent
> > with some delay (few seconds) to avoid any possible congestion.
> >
> > The concrete delay and number of sent packets are not defined in the draft,
> > since they don't affect interoperability (following long practice of