[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 idea is
t

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 should be
filled in, right?

I’m ju

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=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 example, 

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 

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 

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 

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] 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 

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=05%7C01%7Cmohamed.boucadair%40orange.com%7C9255f776e6cc
> > >>
> > 4c03710d08dbc54d09a2%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638
> > >>
> > 320706888240742%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
> > >>
> > 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=j1S53uWVH
> > >> CJoqPS%2BIWoKaFJRUjaz1zC1k2h1FKLEAoQ%3D=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) (variable) -  Specifies 

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]

 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 version is 
> published, a call for
> adoption would  be issued.

[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 

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 

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 addition, each of individual keys insi

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 

[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?
> 
> This helps, 

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 GCKS to GM

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 IPsec

Re: [IPsec] draft-ietf-ipsecme-ikev2-multiple-ke new

[Valery Smyslov]

I think that an individual draft is OK. 

 

That said, I believe that it should be known to the ipsec community

(e.g. be announced and preferably discussed, even a bit, in the ML).

 

Regards,

Valery.

 

Thanks Valery. Makes sense. 

 

> This may be a very short document referencing generic Kyber specification and 
> clarifying implementation details for IKEv2 (e.g.
the format of the public key etc.).

 

Would that be a draft towards ratification in IPSECME or something like
https://datatracker.ietf.org/doc/html/draft-tls-westerbaan-xyber768d00 which 
does not need to be ratified and can just serve as the
"Specification Required" for the TLS 1.3 IANA registry?

 

 

From: Valery Smyslov  
Sent: Tuesday, April 11, 2023 2:53 AM
To: Kampanakis, Panos ; 
draft-ietf-ipsecme-ikev2-multiple...@ietf.org
Cc: ipsec@ietf.org
Subject: RE: [EXTERNAL]draft-ietf-ipsecme-ikev2-multiple-ke new 

 


CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you can confirm the
sender and know the content is safe.

 

Hi Panos,

 

Hi draft-ietf-ipsecme-ikev2-multiple-ke authors, ipsecme WG,

 

We have seen attempts to get early codepoints allocated for PQ-hybrid key 
exchanges in TLS 1.3 and HPKE in other IETF WGs. These, I
think, are are good steps. Note for these IANA registries the requirement is 
"Specification Required". 

 

How about new PQ Transform Type 4 identifiers in IKEv2? Currently the 
draft-ietf-ipsecme-ikev2-multiple-ke draft says

 It is assumed that new Transform Type 4 identifiers will be assigned later 
for various post-quantum key exchanges [
<https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-ikev2-multiple-ke-12> 
IKEV2TYPE4ID].

 

So, if draft-ietf-ipsecme-ikev2-multiple-ke will not assign new identifiers for 
Kyber-768 in
<https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-8>
https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-8,
 should we be asking the Experts (Tero,
Valery) consider a new allocation?

 

  Yes, that's correct. 

  

  However, while it is possible to ask IANA for new allocation without 
any referencing document,

  as designated expert I would be much more comfortable if some 
document (even I-D) exists describing

  how to use Kyber-768 in specific environment of IKEv2. This may be a 
very short document referencing 

  generic Kyber specification and clarifying implementation details for 
IKEv2 (e.g. the format of the public key etc.).

 

  Regards,

  Valery.

 

Thx,

Panos

 

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

Re: [IPsec] Tsvart early review of draft-ietf-ipsecme-g-ikev2-08

[Valery Smyslov]

Hi Gorry,

thank you for your review. Please see inline.

> 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.

> 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).

> 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 IPsec WG 
documents).

> 4. What is required by:  /If the GM and the GCKS used UDP port 848 for the
>  IKE_SA_INIT exchange, they MUST behave as if they used UDP port 500./ This
>  reads as if there normative requirements, but I am unsure what they are, and
>  specifically what is intended by /behave as if/. Perhaps though, it only 
> means
>  the same method needs to be followed when port 848 is used instead of using
>  port 500?

The intended meaning of this text was that the behavior of GMs and GCKS must 
not depend on the port they created initial IKE SA over. How can we state this 
more clearly?

> Editorial issues:
> /that allows to perform a group key management./
> which allows this to perform a group key management./

Changed to "which allows performing a group key management". Is it better?

> /describes how IKEv2 deals with NATs/
> - sound a little judgmental, could this be:
> - /describes how IKEv2 supports paths with NATs/
> - or
> - /describes how IKEv2 interacts with paths with NATs/

Changed to "describes how IKEv2 supports paths with NATs".

Regards,
Valery.

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

Re: [IPsec] draft-ietf-ipsecme-ikev2-multiple-ke new

[Valery Smyslov]

Hi Panos,

 

Hi draft-ietf-ipsecme-ikev2-multiple-ke authors, ipsecme WG,

 

We have seen attempts to get early codepoints allocated for PQ-hybrid key 
exchanges in TLS 1.3 and HPKE in other IETF WGs. These, I
think, are are good steps. Note for these IANA registries the requirement is 
"Specification Required". 

 

How about new PQ Transform Type 4 identifiers in IKEv2? Currently the 
draft-ietf-ipsecme-ikev2-multiple-ke draft says

 It is assumed that new Transform Type 4 identifiers will be assigned later 
for various post-quantum key exchanges [
 
IKEV2TYPE4ID].

 

So, if draft-ietf-ipsecme-ikev2-multiple-ke will not assign new identifiers for 
Kyber-768 in

https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-8,
 should we be asking the Experts (Tero,
Valery) consider a new allocation?

 

  Yes, that's correct. 

  

  However, while it is possible to ask IANA for new allocation without 
any referencing document,

  as designated expert I would be much more comfortable if some 
document (even I-D) exists describing

  how to use Kyber-768 in specific environment of IKEv2. This may be a 
very short document referencing 

  generic Kyber specification and clarifying implementation details for 
IKEv2 (e.g. the format of the public key etc.).

 

  Regards,

  Valery.

 

Thx,

Panos

 

___
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,

thank you for this review.

> Sorry for the (very) late review. I support the document but have a few
> comments and questions.
> 
> The SUPPORTED_AUTH_METHODS NOTIFY is used for multiple purposes. One
> of these methods (with no payload data) is used for two different things.
> Would it be better to split this in two? eg
> SUPPORTED_AUTH_METHODS_SUPPORTED and
> SUPPORTED_AUTH_METHODS ?

Actually, there is no ambiguity here. The first appearance of 
SUPPORTED_AUTH_METHODS anywhere
means that this extension is supported by the party sent it. The content 
provides supported methods and 
if the content in responder's message is empty, then it means that it will be 
provided in subsequent exchange.

It is possible to use two notifications types, but is there a real need for 
that?

> The recommendations on in which IKE_INTERMEDIATE to send the payload is
> a lot of handwaving. Maybe just say "in any IKE_INTERMEDIATE, but later
> might give you more protection"

Yes, I think this can be changed along these lines.

> 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.
If these identities are to be put in notifies, then probably the amount
of code re-use will be smaller, so more new code needs to be wtitte/tested etc.

These payloads are optional in IKE_INTERMEDIATE, their presence may give 
the responder more information which authentication methods are applicable
for this particular initiator. On the other hand, they may receive less
protection, compared to IKE_AUTH, so the initiator may provide some
other identities, than its real ones are, some kind of pseudonyms,
which give enough information for selecting the proper authentication
method, but still don't reveal real initiator's identity in case attacker
can break IKE_NTERMEDIATE. 

> 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.

> 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.

> 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 in this message.
Would it eliminate your concern?

> With PAKE, can we say MUST NOT instead of SHOULD NOT, and throw a fatal
> error?

I tend to agree in general. But for some reason RFC 6467 exchange diagrams 
contain CERT and CERTREQ payloads,
so, it makes me think that they can be used somehow and thus this extension can 
be useful in this case too 
Perhaps some combined authentication? But probably this is a bug in RFC 6467...

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] Dnsdir last call review of draft-ietf-ipsecme-add-ike-09

[Valery Smyslov]

Hi Tero,

> mohamed.boucad...@orange.com writes:
> > > But my understanding is that this is not the case here, as if you
> > > send INTERNAL_DNS_DOMAIN without INTERNAL_IP*_DNS but with
> > > ENCDNS_IP* to implementations supporting old RFC,
> >
> > [Med] Responders know when it will break. They will basically supply
> > the encrypted DNS to initiators who indicated support as per:
> >
> >Initiators first indicate support for encrypted DNS by including
> >ENCDNS_IP* attributes in their CFG_REQUEST payloads.  Responders
> >supply encrypted DNS configuration by including ENCDNS_IP* attributes
> >in their CFG_REPLY payloads.
> >
> > If responders decide to ignore the capabilities of the initiators,
> > returning **only** the ENCDNS_IP* won't break only split horizon but
> > the full DNS service!
> 
> I mean if initiator proposes:
> 
>CP(CFG_REQUEST) =
>  INTERNAL_IP6_ADDRESS()
>  ENCDNS_IP6()
>  ENCDNS_DIGEST_INFO(0, (SHA2-256, SHA2-384, SHA2-512))
>  INTERNAL_DNS_DOMAIN()
> 
> to indicate that it only wants to talk ENCDNS server, and it does NOT
> want to have normal DNS server, then responder who do not understand
> ENCDNS_IP6() will see that this is against MUST in RFC8598 and as
> there is no other error to use, it will most likely consider this a
> malformed message (==fatal error) and return with INVALID_SYNTAX. This
> will tear down the IKE SA and does not specify for the initiator why
> the connection attempt failed.

The initiator cannot force the responder to do anything (e.g. to explicitly 
provide it with the encrypted DNS info).
It can only indicate support for this feature. So, in my understanding, the 
above set of configuration 
attributes indicates some problems with initiator (in which case fatal error is 
not a bad solution).

The correct request should be:

CP(CFG_REQUEST) =
  INTERNAL_IP6_ADDRESS()
  INTERNAL_IP6_DNS()
  ENCDNS_IP6()
  ENCDNS_DIGEST_INFO(0, (SHA2-256, SHA2-384, SHA2-512))
  INTERNAL_DNS_DOMAIN()

If the responder doesn't support this extension, it will ignore ENCDNS_IP6 and 
ENCDNS_DIGEST_INFO
and return INTERNAL_IP6_DNS(...) + INTERNAL_DNS_DOMAIN(...).

If the responder supports this extension, it will return either ENCDNS_IP6(...) 
+ ENCDNS_DIGEST_INFO(..) + INTERNAL_DNS_DOMAIN(...)
or INTERNAL_IP6_DNS(...) + INTERNAL_DNS_DOMAIN(...) depending on its 
configuration (most probably the former).

If the initiator is configured to allow only encrypted DNS, it may immediately
delete IKE SA in case the responder returns INTERNAL_IP6_DNS.
There is nothing more the initiator can do in this case.

Note, that with this approach there is no room for fatal errors, all protocol 
paths are legal
with no need to update 8598.

> Note, that RFC8598 says that responder must return INTERNAL_IP*_DNS if
> INTERNAL_DNS_DOMAIN is present, but if the initiator does not offer
> them it can't add them.
> 
> Thats why it would be better for even those RFC8598 implementations
> which will not support this RFC to be modified so that they will
> understand ENCDNS_IP* at least so much that they understand that they
> can ignore INTERNAL_DNS_DOMAIN attribute if there is no
> INTERNAL_IP*_DNS, and but there is ENCDNS_IP* instead. If they simply
> ignore ENCDNS_IP* (is they should, as they do not understand), and
> they ignore the INTERNAL_DNS_DOMAIN also because there is no
> INTERNAL_IP*_DNS then the initiator will be able to connect. And then
> the initiator can later do another configuration payload to fetch
> normal DNS servers ip-addresses if those would be acceptable for it.
> 
> Or, have I misunderstood the protocol somehow. I.e., what should old
> responder implementation do when it receives the request like above?

I believe so.

Regards,
Valery.

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

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

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

[Valery Smyslov]

Hi,

the new version of G-IKEv2 draft is published. It mostly addresses comments 
made by Michael.
Still waiting for more reviews...

Regards,
Valery (for the authors).

> -Original Message-
> From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of 
> internet-dra...@ietf.org
> Sent: Thursday, March 09, 2023 4:37 PM
> To: i-d-annou...@ietf.org
> Cc: ipsec@ietf.org
> Subject: [IPsec] I-D Action: draft-ietf-ipsecme-g-ikev2-08.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 WG of the IETF.
> 
> Title   : Group Key Management using IKEv2
> Authors : Valery Smyslov
>   Brian Weis
>   Filename: draft-ietf-ipsecme-g-ikev2-08.txt
>   Pages   : 70
>   Date: 2023-03-09
> 
> 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
>one of transform types defined there.
> 
> 
> 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-08
> 
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-ipsecme-g-ikev2-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] [IANA #1267827] expert review for draft-ietf-ipsecme-add-ike (ikev2-parameters)

[Valery Smyslov]

Hi David,

as I am also the document co-author, I obviously abstain here and let Tero do 
the job :-)

Regards,
Valery.

> -Original Message-
> From: David Dong via RT [mailto:drafts-expert-review-comm...@iana.org]
> Sent: Tuesday, March 07, 2023 1:53 AM
> Cc: kivi...@iki.fi; val...@smyslov.net; ipsec@ietf.org
> Subject: [IANA #1267827] expert review for draft-ietf-ipsecme-add-ike 
> (ikev2-parameters)
> 
> Dear Tero Kivinen and Valery Smyslov (cc: ipsecme WG),
> 
> As the designated experts for the IKEv2 Configuration Payload Attribute Types 
> registry, can you review
> the proposed registration in draft-ietf-ipsecme-add-ike for us? Please see
> 
> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-add-ike/
> 
> The due date is March 20, 2023.
> 
> If this is OK, when the IESG approves the document for publication, we'll 
> make the registration at
> 
> https://www.iana.org/assignments/ikev2-parameters/
> 
> We'll wait for both reviewers to respond unless you tell us otherwise.
> 
> With thanks,
> 
> David Dong
> IANA Services Specialist

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

Re: [IPsec] AD review of draft-ietf-ipsecme-add-ike-08

[Valery Smyslov]

Hi Paul,

> > ** Section 3.2. Is the RESERVED field 2 or 3 octets? Figure 2 and 3 says 
> > two and the text says three.
> 
> I guess two. But a more interesting question is, why are there RESERVED

Exactly.

> octets there to begin with ? I don't feel this CP payload would get
> extended and instead some new different CP payload would be created if
> needed.

Good point. I think we can get rid of RESERVED here (unless my co-authors
have some justification for it).

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] AD review of draft-ietf-ipsecme-add-ike-08

[Valery Smyslov]

Hi Roman,

thank you for the review, please see inline.

> Hi
> 
> I performed an AD review of draft-ietf-ipsecme-add-ike-08. Thanks for this 
> document. Below is my
> feedback:
> 
> ** Section 3.1
> 
> Section 3.1.5 of
> [I-D.ietf-add-dnr] lists a set of service parameters that are
> recommended to be supported by implementations.
> 
> The referenced section in draft-ietf-add-dnr provides MTI and RECOMMENDED 
> options. Are both of
> these applicable here?

I rely on my co-authors here.

> ** Section 3.2. Is the RESERVED field 2 or 3 octets? Figure 2 and 3 says two 
> and the text says three.

The text is a leftover from recent changes. It must be 2, as in the figure.

> ** Section 3.2. Per the Certificate Digest field, please provide a normative 
> reference to computing a SPKI
> hash.

OK.

> ** Section 3.2. Typo. s/theENCDNS_DIGEST_INFO/the ENCDNS_DIGEST_INFO/

OK, thanks.

> ** Section 4
> If the request includes multiple bitwise identical attributes,
> only the first occurrence is processed, and the rest SHOULD be
> ignored by the responder.
> 
> If only the first attribute should be processed why is the second clause not 
> a MUST. What would be the
> expected extraordinary behavior given this SHOULD?

We have had an off-the-list discussion among the authors regarding this piece 
of text.
The intention for using SHOULD here is that the following sentence allows the 
responder
to ignore the whole request if it contains too many repeated attributes 
(SHOULD, alternatively MAY).
We were having some doubts, whether SHOULD here might cause any confusion and 
MUST should be used instead,
but finally left SHOULD. 

> ** Section 4.
> These
> instances SHOULD be processed by initiators following their
> service priority (i.e., smaller service priority values indicates
> a higher preference).
> 
> Can the intent of "processed" be clarified here? There are times when the 
> service priority should be
> ignored?

I'll leave this to my co-authors.

Regards,
Valery.

> Regards,
> Roman
> 
> ___
> 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] Disabling replay protection

[Valery Smyslov]

> > Another approach would be to generalize the Transform Type 5
> > as the way to control the replay protection status
> > (see draft-ietf-ipsecme-g-ikev2-07, Section 2.6.)
> 
> I guess that depends on what implementations do when seeing a
> Transform Type 5 value with bit 1 set. Would we really want
> the Child SA to fail on such unknown value?
> 
> In that sense, a NOTIFY seems more safe. Unknown status notify's
> are ignored. And using notify shows more clearly it is a notification,
> not a negotiation?

Good point. In G-IKEv2 there is a provisioning instead of negotiation, 
so there is no such a problem.

Regards,
Valery.

> Paul

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

Re: [IPsec] Disabling replay protection

[Valery Smyslov]

Hi,

> > Hi IPSECME,
> >
> > RFC 4302 (ESP) says "if an SA establishment protocol such as IKE is 
> > employed, the receiver SHOULD
> notify the sender, during SA establishment, if the
> > receiver will not provide anti-replay protection".
> >
> > I haven't been able to find any mechanism for this in IKEv2 (or IKEv1).  Is 
> > there a way to do this?  Or is
> this a mismatch between ESP and IKEv2?

In IPsec the replay protection is a local matter of receiver, 
the sender must always increment the Sequence Number as if 
the replay protection is always on.

> Indeed, I don't see it for IKEv2 either. Funny enough there is
> IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED for RFC 6311.

That is for different purpose :-)

> For IKEv1 I do see 24577 REPLAY-STATUS, referencing RFC 2407,
> https://www.rfc-editor.org/rfc/rfc2407.html#section-4.6.3.2
> 
> So this was just never ported up to IKEv2 it seems.
> 
> At $dayjob, we would call this an "easy onboarding task" :)
> 
> Probably worth writing up a 3 page IKEv2 notification status payload for.

Another approach would be to generalize the Transform Type 5
as the way to control the replay protection status
(see draft-ietf-ipsecme-g-ikev2-07, Section 2.6.)

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] Shepherd review of the draft-ietf-ipsecme-add-ike

[Valery Smyslov]

> > > Actually is there any point of having ADN Length and Authenticated
> > > Domain Name in CFG_REQUESTS ever? Why would someone calculate hashes
> > > with certain domain names with different hash algorithms? Perhaps we
> > > should define the format for CFG_REQUEST as follows:
> > >
> > >
> > > 1   2   3
> > > 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 |
> > >+---+---+
> > >~  List of Hash Algorithm Identifiers   ~
> > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >
> > >  Figure 3: ENCDNS_DIGEST_INFO Attribute Format for CFG_REQUEST
> >
> > I'm confused, since CFG_REQUEST doesn't include Digest.
> > Am I missing your point?
> 
> Thats the point. As the CFG_REQUEST does not include Certificate
> Digest, it only includes list of hash algorithms, there is no point of
> having Authentication Domain Name there either. So the ADN Length of
> CFG_REQUEST will always be zero, and Authentication Domain Name is
> omitted, but then we could simply omit the RESERVED and ADN Length
> fields also for more optimal encoding. I.e., if as we already have
> different format for CFG_REQUEST and CFG_REPLY/CFG_SET then making
> them even more different does not matter.
>
> If we want to keep the format same for all CFG_* then we need to
> format this payload as follows:
> 
> 
> 1   2   3
> 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 |
>+-+-+---+---+
>|RESERVED   | Num Hash Algs |  ADN Length   |
>+---+---+
>~  Authentication Domain Name   ~
>+---+
>~  Hash Algorithm Identifiers   ~
>+---+
>~ Certificate Digest~
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> 
> Where for CFG_REQUEST the Num Hash Algs tells how many hash algorithms
> there are in the Hash Algorithm Identifiers list, and ADN Length will
> be zero, and Authentication Domain Name and Certificate Digest are
> omitted.
> 
> For CFG_REPLY/CFG_SET the Num Hash Algs MUST be one, and Hash
> Algoritms Identifiers includes exactly one hash algorithm identifier
> which is used to calculate the Certificate Digest.
> 
> With this payload format the decoder for this configuration payload
> attribute does not need to know the type of the Configuration Payload
> CFG Type, it can decode and encode the payload without knowing that
> information, and the actual code that fills or uses them can then do
> checking whether they have suitable fields set to suitable values.
> 
> But either one of those ways is fine, I would assume you as an
> implementor has more preference which one is nicer than we others who
> most likely will not do implementation of this.

I think that the latter approach is better (and it is more consistent
with ENCDNS_IP* encoding). I also think it's a bit easier to implement.

> > > I would prefer the SPKI (Subject Public Key Info) selector field way
> > > of RFC7671, as then it does not matter if the certificate is renewed
> > > etc.
> >
> > Does certificate renewal matter in this case?
> 
> Not really, but for TLSA certificates I have been mostly using SPKI
> and when I need to renew certificate because it expired, I will simply
> reuse the private/public key and generate new certificate, and as I am
> using SPKI I do not need to update my dns zone when I do that. I would
> assume I am not alone in this situation, but I have no idea what will
> be the operational practices for these certificates.
> 
> Both full certificate and SPKI digest allow checking that key is
> correct, but full certificate digest might get broken in case there is
> different certificates in the VPN gateway and the DNS server (i.e.,
> DNS server hash renewed its certificate with same public key, but this
> has not yet been migrated to the configuration of the VPN gateway).

OK, as Tiru clarified, it is SPKI what is used.

> > > I do not think the [Hash] is normative reference. I did not need to
> > > read and understand that to somewhat understand this document :-)
> >
> > Well, it's only 58 words including title, you may read them in few
> > seconds :-) Kidding aside, how this can be informative? The document
> > 

Re: [IPsec] [saag] IETF 114 IPsecME report

[Valery Smyslov]

Hi Paul,

> > The "proper" way would be to introduce new TS types
> > TS_IPV4_ADDR_RANGE_WITH_SECLABEL and TS_IPV6_ADDR_RANGE_WITH_SECLABEL.
> > I recall that it was already tried before, but I don't remember
> > why this way was abandoned.
> 
> The fear of combinatory explosion if something else got added. Eg lets
> say we have a similar new TS TYPE that modifies like sec_label. Let's
> call it FOO. We would end up with:
> 
> TS_IPV4_ADDR_RANGE
> TS_IPV4_ADDR_RANGE_WITH_SECLABEL
> TS_IPV4_ADDR_RANGE_WITH_FOO
> TS_IPV4_ADDR_RANGE_WITH_SECLABEL_AND_FOO
> TS_IPV6_ADDR_RANGE
> TS_IPV4_ADDR_RANGE_WITH_FOO
> TS_IPV6_ADDR_RANGE_WITH_SECLABEL
> TS_IPV6_ADDR_RANGE_WITH_SECLABEL_AND_FOO
> 
> The WG thought this would be a worse solution.

This could be solved by adding only two new TS types
TS_IPV4_ADDR_RANGE_WITH_CONSTRAINTS and TS_IPV6_ADDR_RANGE_WITH_CONSTRAINTS
with a format that allows to add new constraints to the Traffic Selector.

Something like:

1   2   3
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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   TS Type |IP Protocol ID*|   Selector Length |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Start Port* |   End Port*   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |
   ~ Starting Address* ~
   |   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |
   ~ Ending Address*   ~
   |   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |
   ~  Constraints*   ~
   |   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

where each constraint can be represented as an Attribute 
(it is also possible to introduce a dedicated structure) and all of them are 
treated with AND.
This way we may add any number of additional restrictions
to the base Traffic Selector.

Regards,
Valery.

> 
> Paul

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

Re: [IPsec] [saag] IETF 114 IPsecME report

[Valery Smyslov]

Hi Tero,

few comments inline.

[a lot of text snipped]

> This document should simply say that TS_SECLABEL MUST NOT be used
> alone. This document must not try to do incompatible change to the
> base RFC7296 which would make conforming implemntations
> non-conforming.

Unfortunately, this won't work. It is not enough to add new TS type,
with security labels the semantics of TS types should be changed
so, that there are "primary" TS types and "additional" ones.

This is because in RFC 7296 individual Traffic Selectors in TS payload 
are combined with OR. In other words, traffic matching
combination of any Traffic Selector in TSi and 
any Traffic Selector in TSr is protected.

TS_SECLABEL cannot be treated with this semantics, 
it must be treated with AND (as additional condition for 
the traffic to match), which requires RFC 7296 update.

I agree with you that current document text doesn't take into considerations 
the existence of other "primary" TS types, like TS_FC_ADDR_RANGE.

> So I do not think this document should update RFC7296 at all, so most
> of the section 3 is wrong.

The "proper" way would be to introduce new TS types
TS_IPV4_ADDR_RANGE_WITH_SECLABEL and TS_IPV6_ADDR_RANGE_WITH_SECLABEL.
I recall that it was already tried before, but I don't remember
why this way was abandoned.

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] Shepherd review of the draft-ietf-ipsecme-add-ike

[Valery Smyslov]

Hi Tero,

thank you for the review. Please see inline.

> Here are some my review comments while reading
> draft-ietf-ipsecme-add-ike:
> 
> --
> The text in section 3.1 should say that if length is 0, then no
> Service Priority, Num Addresses etc fields are present.
> 
> I.e., add text in first bullet under Length saying that if length is
> zero, then later fields are not present.

Makes sense.

> --
> 
> Also the text in Num Addresses indicate that it would be valid to send
> CFG_REQUEST with proposed Service Priority, but having Num Addresses
> set to zero?
> 
> Is this intended? I.e., is the client allowed to request data, but not
> propose IP address? If so, perhaps add sentence to Num Addresses
> explaining that it can be 0 for CFG_REQUEST when no specific address
> is request, but other parameters are requested.

Hm... I think my co-authors can comment on this.

> --
> 
> In IP Address(es) explictly mention that it is field contain 4 octet
> IPv4 addresses, or 16 octet IPv6 address without any delimeters etc.
> This can be derived from the calculation of the length field, but I
> think it should be mentioned here, even when it is obvious.

OK.

> --
> 
> In section 3.2 it is not clear what the length of the Hash Algorithm
> Identifiers fields is. It contains list of hash algorithms or one hash
> algorithm if this is response, but it is not clear what is response.

What was meant is that a list of hashes is sent by a client (in CFG_REQUEST) and
a single hash is sent by a server (in CFG_REPLY).

> We have CFG_REQUEST, CFG_REPLY, CFG_SET, and CFG_ACK. Most likely
> CFG_REPLY and CFG_ACK are sent in IKE exchange response. On the other
> hand CFG_SET is usually used to set the parameters, thus the
> Certificate Digest would be required there.

True, but IKEv2 doesn't currently use CFG_SET/CFG_ACK and
it explicitly allows implementations to ignore them.

> I would assume that there is only one Hash Algorithm Identifier for
> CFG_REPLY and CFG_SET, and then the Certificate Digest field is
> present. For CFG_REQUEST the Hash Algorithm Identifier is a list of
> two octet hash algorithm identifiers and the Certificate field is
> omitted. For the CFG_ACK only first 4 octets are included and Length
> is set to zero.
> 
> I think it would be better to split the Figure 2 to three different
> figures:
> 
> 
> 1   2   3
> 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 |
>+-+-+---+---+
>|RESERVED   |  ADN Length   |
>+---+---+
>~  Authentication Domain Name   ~
>+---+
>~  Hash Algorithm Identifier (2 octets) ~
>+---+
>~ Certificate Digest~
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>   Figure 2: ENCDNS_DIGEST_INFO Attribute Format for CFG_REPLY and CFG_SET
> 
> 
> 
> 1   2   3
> 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 |
>+-+-+---+---+
>|RESERVED   |  ADN Length   |
>+---+---+
>~  Authentication Domain Name   ~
>+---+
>~  List of Hash Algorithm Identifiers   ~
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>  Figure 3: ENCDNS_DIGEST_INFO Attribute Format for CFG_REQUEST
> 
> 1   2   3
> 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 |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>  Figure 4: ENCDNS_DIGEST_INFO Attribute Format for CFG_ACK.
> 
> and then explain the Hash Algorithm Identifier and List of Hash
> Algorithm Identifiers separately.

We may do this for completeness, but as I've already mentioned
CFG_SET/CFG_ACK are not currently used in IKEv2.
So I'm in not sure if this is really needed and won't further confuse 
implementers...

> 

Re: [IPsec] IPR Poll RE: Shepherd write-up information for draft-ietf-ipsecme-add-ike

[Valery Smyslov]

Hi,

I confirm that I'm not aware of any IPR related to this draft.

Regards,
Valery.

> Hi all,
> 
> As a input to the writeup, we are replying to the IPR poll on-list.
> 
> I don't have any IPR nor I'm aware of any related to this draft.
> 
> My co-authors replies will follow soon.
> 
> Cheers,
> Med
> 
> > -Message d'origine-
> > De : Tero Kivinen 
> > Envoyé : dimanche 29 janvier 2023 18:01
> > À : draft-ietf-ipsecme-add-...@ietf.org
> > Objet : Shepherd write-up information
> >
> 
> __
> ___
> 
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne
> doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez
> le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
> electroniques etant susceptibles
> d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
> falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged 
> information that may be
> protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete 
> this message and its
> attachments.
> As emails may be altered, Orange is not liable for messages that have been 
> modified, changed or
> falsified.
> Thank you.
> 
> ___
> 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] comments on draft-ietf-ipsecme-g-ikev2-07

[Valery Smyslov]

> > Unless I'm missing something, it's not immediately clear for me how you want
> > to use HPKE here. Can you clarify?
> 
> Similar to how MLS is using it to (re)generate  the keys for the binary tree. 
> They addressed the same
> problem of having a group and members joining and leaving and ensuring left 
> members can’t decrypt
> new messages anymore.

It seems to me taht the requirements for MLS and G-IKEv2 are a bit different.

In G-IKEv2 (or generally in GDOI architecture) we have a group controller,
which have a complete view of the group (it manages membership and generates
and distributes all the multicast keys). Generally speaking, the controller may 
be
out of the group (i.e. it may have no data to send to the members or to receive
from them other than multicast keys).

In my understanding in MLS there is no such a controller, the group is managed 
by its members and the keys are constantly updated by all members.

In other words, in G-IKEv2 group management and key distribution
is centralized, which is not the case for MLS. I didn't look into MLS
deeply, but it seems to me that it is more suitable for low-bandwidth
communications (like group chat), while G-IKEv2 approach is more 
appropriate for high-speed communications (e.g. live broadcasting).

And you may want to know that there is a mechanism in G-IKEv2
that allows excluding group members (so that they cannot decrypt multicast data 
anymore) 
using only multicast messages (yes!). It is called LKH (Logical Key Hierarchy)
and is currently a part of G-IKEv2 document. Such mechanisms are pluggable,
more can be defined in future.

Regards,
Valery.



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

Re: [IPsec] comments on draft-ietf-ipsecme-g-ikev2-07

[Valery Smyslov]

Hi Paul,

> On Mon, 26 Dec 2022, Valery Smyslov wrote:
> 
> > Subject: Re: [IPsec] comments on draft-ietf-ipsecme-g-ikev2-07
> 
> I know this comment comes very late, but within the IETF we now see
> adoption happening of HPKE, Hybrid Public Key Encryption in RFC 9180.
> 
> Would it make sense to redo the draft using HPKE primitives and methods?

Unless I'm missing something, it's not immediately clear for me how you want 
to use HPKE here. Can you clarify?

> Paul - who still needs to do a full careful reading of the draft, sorry :/

Better late than never :-)

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-02.txt

[Valery Smyslov]

Hi,

a new version of the draft is published to prevent its expiration.
This version is basically identical to the previous one, except that
a possibility for the initiator to indicate its identity in the IKE_INTERMEDIATE
exchange is added (this option was inspired by Paul's review of the document, 
thanks Paul!).

Regards,
Valery.

> -Original Message-
> From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of 
> internet-dra...@ietf.org
> Sent: Tuesday, January 10, 2023 11:14 AM
> To: i-d-annou...@ietf.org
> Cc: ipsec@ietf.org
> Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-auth-announce-02.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the IP Security Maintenance and Extensions WG of 
> the IETF.
> 
> Title   : Announcing Supported Authentication Methods in IKEv2
> Author  : Valery Smyslov
>   Filename: draft-ietf-ipsecme-ikev2-auth-announce-02.txt
>   Pages   : 10
>   Date: 2023-01-10
> 
> 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 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-02
> 
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-ipsecme-ikev2-auth-announce-02
> 
> 
> 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] comments on draft-ietf-ipsecme-g-ikev2-07

[Valery Smyslov]

> >> > Thus, what do you want to see in the third column?  "Defined in RFC
> >> > 7296"/"Defined in this document"?
> >>
> >> You could say, "STD79", and "Section X" if you like.
> 
> > I prefer "RFC7296", as it's better known than "STD79" :-)
> 
> Yet, it's incorrect.

I'm not sure.

> It fails to include the updates, and it goes stale.

The table of payloads in the G-IKEv2 spec will not contain updates anyway.
It lists the payloads defined in RFC 7296 and thus it seems 
appropriate to reference a document where they are defined, 
not its future updates. As, for example, IANA registries do.

> It also wastes all the effort we put into bringing it to Internet Standard.

Bad or good, I believe it is a common practice in IETF, no?
For example, a well-known RFC 822 is also STD 11, but it is rarely referenced 
by the latter name...

> > The similarity between IKE_AUTH and GSA_AUTH is that both complete
> > authenticating peers and creating IKE SA. The difference is that
> > IKE_AUTH in addition creates unicast Child SA, so the set of payloads
> 
> It does?

I'm puzzled. Do you have any doubts?

Quoting RFC 7296 Section 1 (Introduction):

   In the common
   case, there is a single IKE_SA_INIT exchange and a single IKE_AUTH
   exchange (a total of four messages) to establish the IKE SA and the
   first Child SA.

Am I missing the point?

> >> > Note, that RFC 7296 includes a concept of one-way IKEv2 messages
> >> (for > error notification in case no IKE SA exists).
> >>
> >> Fair enough, but those are inside the IKEv2 PARENT_SA, while GSA_REKEY
> >> is not.
> 
> > GSA_REKEY is "inside" a multicast rekey SA (which is different from
> > initial GM<->GCKS IKE SA).
> 
> I think that this new SA needs to be introduced.

It is introduced. Section 1:

   Group rekeys are accomplished
   using ... the GSA_REKEY pseudo-exchange (a single message
   distributed to all GMs, usually as a multicast message) ...

> I think that there need to be some diagrams.

Figure 1 shows the case where rekeying is being done over multicast.

Do you think more clarifications are needed?

Regards,
Valery.

> --
> Michael Richardson. o O ( IPv6 IøT consulting )
>Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
> 


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

Re: [IPsec] comments on draft-ietf-ipsecme-g-ikev2-07

[Valery Smyslov]

Hi Michael,

> > Thus, what do you want to see in the third column?  "Defined in RFC
> > 7296"/"Defined in this document"?
> 
> You could say, "STD79", and "Section X" if you like.

I prefer "RFC7296", as it's better known than "STD79" :-)

> >> I don't understand GSA_AUTH vs IKE_AUTH. I think that's an IKEv1-ism
> >> to split it.
> 
> > Why? When you need to substantially modify the behavior of the exchange
> > you have two options - either indicate its purpose with some notify or
> > introduce a new dedicated exchange. GSA_AUTH substantially differs from
> > IKE_AUTH, so what's wrong with introducing a new exchange type for it?
> > After all, we did it before (IKE_SESSION_RESUME, IKE_FOLLOWUP_KE).
> 
> I guess that I'm completely unable to understand what GSA_AUTH needs to do
> that's different.

The similarity between IKE_AUTH and GSA_AUTH is that both complete
authenticating peers and creating IKE SA. The difference is that IKE_AUTH
in addition creates unicast Child SA, so the set of payloads it may/must contain
corresponds to this function. GSA_AUTH creates one or more multicast
Child SAs and zero or one multicast IKE SA (used for group rekeying),
including direct downloading keying material from GCKS to GM.
So it may/must contain very different set of payloads (apart from
those used for authentication).

> >> I'd consider leaving it out, or discouraging it.  Obviously, one can
> >> just never compress, but it seems like it's been a PITA to implement.
> 
> > IPcomp is optional, you don't need to implement it. It can be useful if
> > the traffic is compressible, especially taking into consideration that
> > multicast is always udp and IP fragmentation may be an issue. On the
> > other hand, if IPcomp is used for some group SA and later an GM is
> > joined which doesn't support it, then a sufficiently clever GCKS could
> > immediately rekey the SA with IPcomp off (taking a risk of IP
> > fragmentation).
> 
> I'm saying, it adds complexity, which means additional test cases, and
> potential security holes.  It seems unlikely to ever actually get used.

Don't implement it if you don't need it.

> >  The GSA_REKEY is a pseudo-exchange, consisting of a one- way
> > IKEv2 message sent by the GCKS, where the rekey policy is delivered to
> > group members using IP multicast as a transport.  This method is
> > valuable for large and dynamic groups, and where policy may change
> > frequently and a scalable rekeying method is required.
> 
> Reasonable text, but with the clarification, I have many more questions :-)

Don't hesitate to ask :-)

> I think that it's conflating forwarding plane stuff with control plane stuff
> in a way that is really surprising..

In G-IKEv2 both data security SAs (IPsec) and rekey SA (IKE) rely on multicast. 
That's the architecture choice.

> >> propose some clarification text?
> >>
> >> It seems that GSA_RSAKEY is not an IKEv2 message at all then.
> 
> > Why? It is a one-way IKEv2 message (but not an IKEv2 exchange!).  It
> > follows the format for IKEv2 messages and it is processed very much as
> > usual, except that no response is sent.
> 
> Does it travel from port 500 to port 500?
> I don't think so, but maybe I just don't understand.

It depends. The GCKS installs the rekey SA and informs GMs about its source and 
destination IP:port.
I see no reasons why 500 --> 500 cannot be chosen. But actually the ports for 
rekey SA
are arbitrary selected on GCKS discretion.

> > Note, that RFC 7296 includes a concept of one-way IKEv2 messages (for
> > error notification in case no IKE SA exists).
> 
> Fair enough, but those are inside the IKEv2 PARENT_SA, while GSA_REKEY is not.

GSA_REKEY is "inside" a multicast rekey SA (which is different from initial 
GM<->GCKS IKE SA). 

> > I cannot speak for others, but I'm planning to implement it.  And as
> > far as I know, draft 05 version of the IEEE Std 802.15.9 standard
> > (March 2021) specifies that G-IKEv2 is used for group key distribution
> > (but I'm not involved in this work).
> 
> Almost nobody other that Tero has implemented 802.15.9/IKEv2.
> (That's a shame, and I wish it weren't so, but sometimes you have to respect
> the market choices)

Market choices are volatile :-)

Regards,
Valery.

> --
> Michael Richardson. o O ( IPv6 IøT consulting )
>Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
> 


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

Re: [IPsec] comments on draft-ietf-ipsecme-g-ikev2-07

[Valery Smyslov]

Hi Michael,

> > I think it must be pre-configured (just as, for example, using TCP
> > encapsulation in IKEv2).  Should we add some text?
> 
> If it's an arbitrary port that someone has to configure, then please include
> no ports.
>
> I don't think it should be that way.
> 
> I think that it should be port 500.
> I don't know if the option to also listen on port 848 matters.
> That reflects my preference that this work be an IKEv2 extension,
> rather than a new protocol like the IKEv1 version.

I think the text can be changed to indicate that using IKE ports is RECOMMENDED
and udp/848 is MAY (to allow compatibility with GDOI).

> >> Section 2.2 recaps the payload acronyms.  I suggest a third column
> >> telling us where they are defined.
> 
> > Perhaps it's better to split the table into to - existing IKEv2
> > payloads and newly defined G-IKEv2-specific payloads. Does it work for
> > you?
> 
> No, I'd rather see it all in one table.

Thus, what do you want to see in the third column? 
"Defined in RFC 7296"/"Defined in this document"?

> >> Can I do unicast IKE_CHILD_SA echanges in the same PARENT_SA as I do
> >> G-IKEv2?  I can imagine use cases where there is both multicast and
> >> unicast traffic that needs to be protected.  I guess not, beacuse
> >> GSA_AUTH is not IKE_AUTH.
> 
> > You cannot create unicast IPsec SA at the time the G-IKEv2 SA is being
> > established (since GSA_AUTH cannot do it). It's an open question
> > whether you can create them once it is up (via CREATE_CHILD_SA). It is
> > not explicitly prohibited now, but would prefer not to do it - use
> > G-IKEv2 SA for group key management traffic only and create a separate
> > IKEv2 SA if the GCKS acts as a GW too.
> 
> I don't understand GSA_AUTH vs IKE_AUTH. I think that's an IKEv1-ism to split 
> it.

Why? When you need to substantially modify the behavior of the exchange
you have two options - either indicate its purpose with some notify
or introduce a new dedicated exchange. GSA_AUTH substantially differs
from IKE_AUTH, so what's wrong with introducing a new exchange type for it?
After all, we did it before (IKE_SESSION_RESUME, IKE_FOLLOWUP_KE).

> >> Use of IPCOMP seems really difficult.  I guess it can't be used until
> >> every receiver supports it.  Is that common?  Are the target use cases
> >> (probably video?) even compressible?
> 
> > With multicast architecture for any single feature used, every receiver
> > have to support it, IPcomp is not an exception. Using IPcomp is defined
> > for completeness.  No target use cases were considered (I think there
> > may be few of them).
> 
> I'd consider leaving it out, or discouraging it.
> Obviously, one can just never compress, but it seems like it's been a PITA to 
> implement.

IPcomp is optional, you don't need to implement it. It can be useful if the 
traffic
is compressible, especially taking into consideration that multicast is always 
udp
and IP fragmentation may be an issue. On the other hand, if IPcomp is used
for some group SA and later an GM is joined which doesn't support it,
then a sufficiently clever GCKS could immediately rekey the SA with IPcomp off
(taking a risk of IP fragmentation).

> >> I guess 2.4.1 answers that question.  Maybe just leave the comment to
> >> 2.4.1.
> 
> > Can you suggest some wording?
> 
> remove: "This is not a real IKEv2 exchange, since no response messages are 
> sent."

OK. I also added some clarification to this para:

 The GSA_REKEY is a pseudo-exchange, consisting of a one-
 way IKEv2 message sent by the GCKS, where the rekey policy is
 delivered to group members using IP multicast as a transport.
 This method is valuable for large and dynamic groups, and where
 policy may change frequently and a scalable rekeying method is
 required.  When the GSA_REKEY is used, the IKE SA protecting
 the member registration exchanges is usually terminated, and
 group members await policy changes from the GCKS via the
 GSA_REKEY messages.

Is it better?

> >> Are these IKEv2 messages sent in the normal port 500/848/4500 channel?
> >> Or?  I don't understand this part at all.  There are implications that
> >> it's multicast, but clearly, it can't be?
> 
> > GSA_REKEY is sent over multicast (that's why it is unacknowledged).
> > The port it is sent to is specified by the GCKS in the GSA_AUTH
> > exchange (it can be any UDP port).
> 
> > Can you be more specific of the text that is not clear and perhaps
> > propose some clarification text?
> 
> It seems that GSA_RSAKEY is not an IKEv2 message at all then.

Why? It is a one-way IKEv2 message (but not an IKEv2 exchange!).
It follows the format for IKEv2 messages and it is processed
very much as usual, except that no response is sent.

Note, that RFC 7296 includes a concept of one-way IKEv2 messages

Re: [IPsec] comments on draft-ietf-ipsecme-g-ikev2-07

[Valery Smyslov]

Hi Michael,

many thanks for your review. Much appreciated.

Please, see inline.

> I started reading through this document during IETF115, but didn't finish
> until today.  I don't think that I have ever read the IKEv1-G stuff.
> 
> >   G-IKEv2 SHOULD use UDP port 848, the same as GDOI [RFC6407], because
> >   they serve a similar function.  They can use the same ports, just as
> >   IKEv1 and IKEv2 can share port 500.  The version number in the IKE
> >   header distinguishes the G-IKEv2 protocol from GDOI protocol
> >   [RFC6407].  G-IKEv2 MAY also use the IKEv2 ports (500, 4500), which
> >   would provide a better integration with IKEv2.  G-IKEv2 MAY also use
> >   TCP transport for registration (unicast) IKE SA, as defined in
> >   [RFC8229].
> 
> Based upon this text, I would have no idea when/if I can send my G-IKEv2
> packet to port 500 or 848.

I think it must be pre-configured (just as, for example, using TCP 
encapsulation in IKEv2).
Should we add some text?

> Section 2.2 recaps the payload acronyms.
> I suggest a third column telling us where they are defined.

Perhaps it's better to split the table into to - existing IKEv2 payloads
and newly defined G-IKEv2-specific payloads. Does it work for you?

> I think that GSA, KD, IDg, and SAg are new?

Yes.

> Can I do unicast IKE_CHILD_SA echanges in the same PARENT_SA as I do G-IKEv2?
> I can imagine use cases where there is both multicast and unicast traffic
> that needs to be protected.
> I guess not, beacuse GSA_AUTH is not IKE_AUTH.

You cannot create unicast IPsec SA at the time the G-IKEv2 SA is being 
established
(since GSA_AUTH cannot do it). It's an open question whether you can create 
them once it is up 
(via CREATE_CHILD_SA). It is not explicitly prohibited now, but would prefer
not to do it - use G-IKEv2 SA for group key management traffic only
and create a separate IKEv2 SA if the GCKS acts as a GW too.

> Use of IPCOMP seems really difficult.  I guess it can't be used until every
> receiver supports it.  Is that common?   Are the target use cases (probably
> video?) even compressible?

With multicast architecture for any single feature used, every receiver have to 
support it,
IPcomp is not an exception. Using IPcomp is defined for completeness.
No target use cases were considered (I think there may be few of them).

> section 2.4:
>GSA_REKEY  The GSA_REKEY is a pseudo-exchange initiated by the GCKS,
>  where the rekey policy is usually delivered to group members
>  ... no response messages are sent
> 
> so, does this violate the IKEv2 concept that all messages get acknowledged?

Yes :-) That's why it is called "pseudo-exchange".

> I guess 2.4.1 answers that question.  Maybe just leave the comment to 2.4.1.

Can you suggest some wording?

> Are these IKEv2 messages sent in the normal port 500/848/4500 channel? Or?
> I don't understand this part at all.  There are implications that it's
> multicast, but clearly, it can't be?

GSA_REKEY is sent over multicast (that's why it is unacknowledged). 
The port it is sent to is specified by the GCKS in the GSA_AUTH 
exchange (it can be any UDP port).

Can you be more specific of the text that is not clear and 
perhaps propose some clarification text?

> "SID" is now rather overloaded in the IETF (CORE/YANG, SR6...), and perhaps
> another TLA could be considered :-)

This term was used in the draft from its early versions :-)
Perhaps change to SenderID? Or SENDER_ID? Or is it overloaded too?

> s/acieve/achieve/g in section 2.6.
> s/incement/increment/
> s/thus making impossible/thus making it impossible/

Thank you, will fix.

> I think that the end of section 2.6, aout reusing Extended Sequence Number
> should probably have more widespread review within the WG.
> This is not just a key mgmt issue, but an 4301 update I think.

Actually, the current text in the draft is misleading.
It is not about reusing, the transform meaning is generalized
and a new value for transform ID is added. 
We'll try to make the text more clear.

I'm not sure it is an update to 4301, since it requires 
no code change for existing implementations.

> I think that KWK should be explained in the abstract in section 1.

OK.

> It seems a key architectural aspect of this document.
> I got lost in section 3.  I am lacking architectural understanding.
> Perhaps there is some other background that I more strongly need to
> understand.

Section 1 gives some high-level view of the architecture.
Do you think it should be expanded or more details
be added to the Section 3? Probably add a sub-section?


> I coudn't critically read Section 4, without higher level understanding.
> 
> In general, I'd rather that this was an extension to IKEv2, rather than a new
> protocol.  I think that IKEv1 was lacking enough orthogonality for that to
> have been practical before.

It was started as a new protocol, but now it is more like an IKEv2 extension.

> I'm not sure if section 6.1 belongs here.

Why? It describes how 

Re: [IPsec] Assessing Support for draft-smyslov-ipsecme-ikev2-qr-alt

[Valery Smyslov]

Hi all,

 

the draft's original goal was to provide a way for G-IKEv2 to make hassle-free 
use of PPK 

(in G-IKEv2 sensitive information is transferred at the time the initial IKE SA 
is created).

However, the draft is not tied to G-IKEv2 and can be used with IKEv2 when you 
need 

initial IKE SA to be secured with PPK.

 

The draft was presented at IETF 106:

https://datatracker.ietf.org/meeting/106/materials/slides-106-ipsecme-an-alternative-approach-for-postquantum-preshared-keys-in-ikev
2-00

 

As the draft's author, I obviously will support its adoption if the adoption 
call is issued by the chairs.

As someone who implemented it, I confirm that it's easy, given you have already 
implemented RFC 8784 and 9242.

 

Regards,

Valery.

 

Greetings all,

 

DoD has customers who are interested in incorporating a PSK into the initial 
IKEv2 SA. While RFC 8784 already defines a PSK
mechanism, the PSK is not rolled into the encryption until creation of the 
first Child SA. On the other hand, Alternative Approach
for Mixing Preshared Keys in IKEv2 for Post-Quantum Security 
(draft-smyslov-ipsecme-ikev2-qr-alt) proposes a mechanism for
incorporating a PSK that leverages RFC 9242's Intermediate Exchange in order to 
enable use of the PSK prior to IKE_AUTH. While RFC
8784 is useful as an immediate post-quantum solution, the proposed mechanism in 
draft-smyslov-ipsecme-ikev2-qr-alt provides
PSK-fortified confidentiality earlier in the IKEv2 exchanges, and is simple to 
implement (given existing support for RFC 9242).

 

I support the adoption of this draft, and am willing to contribute as a 
reviewer. Would the WG be interested in adopting this draft?

 

Rebecca Guthrie

she/her

Center for Cybersecurity Standards (CCSS)

Cybersecurity Collaboration Center (CCC)

National Security Agency (NSA)

 

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

Re: [IPsec] WGLC of draft-ietf-ipsecme-ikev2-auth-announce

[Valery Smyslov]

Hi Michael,

> I am those that didn't read it during WGLC, or pay attention it before, but I 
> scanned it.
> It seems to solve a problem that I don't think that I have.
> 
> I do not object to publishing it.
> 
> Given that Notify messages are available without a draft,  it might be that
> what we have (an ID) is presently enough.
> (i.e. allocate it a Notify value, and just let it wait for some more people
> to implement it.)

the draft is also used in (now expired) draft-guthrie-ipsecme-ikev2-hybrid-auth.

Regards,
Valery.

> --
> Michael Richardson. o O ( IPv6 IøT consulting )
>Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
> 


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

Re: [IPsec] WGLC of draft-ietf-ipsecme-ikev2-auth-announce

[Valery Smyslov]

Hi Tero,

I think the document is ready (but I'm definitely biased here as its author).

I also recall, that at the time of document adoption a few people
expressed a support for it, so probably they can now look
into the current version and say whether it is ready or not.

Regards,
Valery.

> -Original Message-
> From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Tero Kivinen
> Sent: Thursday, December 08, 2022 1:46 AM
> To: ipsec@ietf.org
> Subject: [IPsec] WGLC of draft-ietf-ipsecme-ikev2-auth-announce
> 
> I started this last call almost a month ago, and I have not seen any
> discussion, comments or emails on the ipsec list.
> 
> For me that would indicate that nobody has actually reviewed the
> document during the WGLC, and would indicate there is very little
> interest in publishing this document.
> 
> I will keep the document in WGLC state for some time, but perhaps we
> should think whether there is enough interest to work on this issue at
> all.
> --
> 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] Éric Vyncke's No Objection on draft-ietf-ipsecme-ikev2-multiple-ke-10: (with COMMENT)

[Valery Smyslov]

Hi Éric,

> -Original Message-
> From: Eric Vyncke (evyncke) [mailto:evyn...@cisco.com]
> Sent: Thursday, December 01, 2022 1:41 PM
> To: Valery Smyslov; 'The IESG'
> Cc: draft-ietf-ipsecme-ikev2-multiple...@ietf.org; ipsecme-cha...@ietf.org; 
> ipsec@ietf.org;
> kivi...@iki.fi; charl...@computer.org; g...@apnic.net
> Subject: Re: Éric Vyncke's No Objection on 
> draft-ietf-ipsecme-ikev2-multiple-ke-10: (with COMMENT)
> 
> Hello Valery,
> 
> Thanks for your suggested text for the abstract, may I suggest a little more 
> concise (albeit less precise)
> text for the 2nd paragraph (up to the authors of course):
> 
> The primary application of this feature in IKEv2 is the ability 
> to perform one or more
> post-quantum key exchanges in conjunction with the classical key 
> exchange,
> so that the resulting shared key is resistant against quantum 
> computer attacks.
> Since there is currently no post-quantum key exchange that is 
> against conventional (non-
> quantum)
> adversaries, performing multiple key exchanges with different 
> post-quantum algorithms along
> with the classical key exchange algorithms addresses this 
> concern, since the
> overall security is at least as strong as each individual 
> primitive.

I think in this text an important consideration is missing - that we now have 
enough trust in (EC)DH
against conventional computers, but we don't have this level of trust in most 
post-quantum
algorithms (both against conventional and quantum adversaries). That's why we 
want 
to combine them.

Ah, I can see now that the original text can be interpreted, that we don't trust
post-quantum key exchange only against conventional adversaries...
We can modify the text as follows (make it more concise, less precise, but 
still correct, IMHO):

Since there is currently no post-quantum key exchange that is studied at
the level that (EC)DH is studied, performing multiple key exchanges 
with different post-quantum 
algorithms along with the well-established classical key exchange 
algorithms addresses this concern, since the
overall security is at least as strong as each individual primitive.

Is it OK?

Regards,
Valery. 

> 
> Hope this helps
> 
> -éric
> 
> 
> On 30/11/2022, 08:48, "iesg on behalf of Valery Smyslov" 
>  s...@elvis.ru> wrote:
> 
> Hi Éric,
> 
> > Hello Valery,
> >
> > TL;DR:  Thanks for your reply and your comments. I agree with them ;-)
> >
> > If you want a more detailed reply, then look for EV> below
> 
> OK, I snipped the text where we have an agreement.
> 
> > Regards
> >
> > -éric
> 
> [snipped]
> 
> > > The bullet 2) is a nice explanation about *why* there must be 
> multiple key
> > > exchanges with different methods. Until reading that part, I was 
> really
> > > wondering why this I-D was about the link with PQC and multiple 
> key exchanges.
> > > Should this be mentioned in the abstract already ?
> >
> > I don't mind, but as far as I know, IESG wants abstract to be short 
> :-)
> > If you (and other ADs) think it's a good idea, then we'll add this 
> text.
> >
> > EV> I know about short abstract, but they should also give an idea of 
> the content & purpose
> 
> If it is OK with the IESG we'll extend the abstract with this text. It 
> will look like:
> 
> This document describes how to extend the Internet Key Exchange 
> Protocol
> Version 2 (IKEv2) to allow multiple key exchanges to take place
> while computing a shared secret during a Security Association 
> (SA) setup.
> 
> The primary application of this feature in IKEv2 is the ability 
> to perform one or more
> post-quantum key exchanges in conjunction with the classical 
> (Elliptic Curve) Diffie-Hellman
> (EC)DH key exchange,
> so that the resulting shared key is resistant against quantum 
> computer attacks.
> Since there is currently no post-quantum key exchange that is 
> trusted at
> the level that (EC)DH is trusted for against conventional 
> (non-quantum)
> adversaries, performing multiple key exchanges with different 
> post-quantum algorithms along
> with the well-established classical key exchange algorithms 
> addresses this concern, since the
> overall security is at least as strong as each individual 
> primitive.
> 
> Another possible application for this 

Re: [IPsec] Murray Kucherawy's No Objection on draft-ietf-ipsecme-ikev2-multiple-ke-10: (with COMMENT)

[Valery Smyslov]

Hi Murray,

thank you for your comments, please see inline.

> -Original Message-
> From: Murray Kucherawy via Datatracker [mailto:nore...@ietf.org]
> Sent: Thursday, December 01, 2022 10:32 AM
> To: The IESG
> Cc: draft-ietf-ipsecme-ikev2-multiple...@ietf.org; ipsecme-cha...@ietf.org; 
> ipsec@ietf.org;
> kivi...@iki.fi
> Subject: Murray Kucherawy's No Objection on 
> draft-ietf-ipsecme-ikev2-multiple-ke-10: (with COMMENT)
> 
> Murray Kucherawy has entered the following ballot position for
> draft-ietf-ipsecme-ikev2-multiple-ke-10: 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-multiple-ke/
> 
> 
> 
> --
> COMMENT:
> --
> 
> This document has seven authors while the RFC Editor guideline is five.  Have
> we considered moving a couple of them to Section 6?

No comments :-) Probably my co-authors will comment on this.

> While not a DISCUSS-level concern, I would really like to see more division
> among the actions requested of IANA in Section 4.  There are 12 actions across
> two sections; it wouldn't take much to put each action in its own section, for
> example.  I can see in the datatracker that IANA has already indicated they
> understand what's being asked of them, but still I think it's helpful to other
> readers to organize it.

We have divided the IANA consideration section into two parts with the 
following logic in mind.
The main body of Section 4 lists those actions, that do allocate new codepoints.
This section should be consulted by IANA when, for example, they process early 
allocation request.
On the other hand, Section 4.1 list auxiliary actions - renaming of existing 
registries and 
adding various notes to them, - those that do not concern with actual 
allocation of code points.
This part may be skipped when the early allocation is being done (which in fact 
was the case).

We believe this division has its logic and won't confuse readers and IANA.

Regards,
Valery.


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

Re: [IPsec] Paul Wouters' Discuss on draft-ietf-ipsecme-ikev2-multiple-ke-10: (with DISCUSS and COMMENT)

[Valery Smyslov]

We are converging :-)

> > I'm a bit reluctant to add all this information to the abstract. It is 
> > already a bit too long
> > (since Éric and Warren suggested to augment it with the explanation text of 
> > how
> > this design helps in situation when PQ algorithms are less trusted). So 
> > currently
> > the abstract is:
> >
> >This document describes how to extend the Internet Key Exchange 
> > Protocol
> >Version 2 (IKEv2) to allow multiple key exchanges to take place
> >while computing a shared secret during a Security Association (SA) 
> > setup.
> >
> >The primary application of this feature in IKEv2 is the ability to 
> > perform one or more
> >post-quantum key exchanges in conjunction with the classical 
> > (Elliptic Curve) Diffie-Hellman (EC)DH
> key exchange,
> >so that the resulting shared key is resistant against quantum 
> > computer attacks.
> >Since there is currently no post-quantum key exchange that is 
> > trusted at
> >the level that (EC)DH is trusted for against conventional 
> > (non-quantum)
> >adversaries, performing multiple key exchanges with different 
> > post-quantum algorithms along
> >with the well-established classical key exchange algorithms 
> > addresses this concern, since the
> >overall security is at least as strong as each individual primitive.
> >
> >Another possible application for this extension is the ability to 
> > combine several key exchanges
> >in situations when no single key exchange algorithm is trusted by 
> > both initiator and responder.
> >
> >   This document updates RFC7296 by renaming a transform type 4 from 
> > "Diffie-Hellman Group (D-H)"
> >to "Key Exchange Method (KE)" and renaming a field in the Key 
> > Exchange Payload from "Diffie-
> Hellman Group Num"
> >to "Key Exchange Method". It also renames an IANA registry for this 
> > transform type
> >from "Transform Type 4 - Diffie-Hellman Group Transform IDs" to
> >"Transform Type 4 - Key Exchange Method Transform IDs". These 
> > changes generalize
> >key exchange algorithms that can be used in IKEv2.
> >
> > Do you *really* want to make it longer? I'm not sure that if we just mention
> > the names of the added exchange and notifies, that will help readers of the 
> > abstract
> > to understand what this document is about...
> 
> This document updates RFC7296. It introduces the IKE_FOLLOWUP_KE Exchange. It 
> renames [...]
> 
> > [update]
> >
> > I've just noticed your message sent in response to Warren. So, since you 
> > insist :-),
> > I suggest adding the following text before "This document updates...":
> >
> >This document utilizes the IKE_INTERMEDIATE exchange to perform multiple 
> > key exchanges when
> >an IKE SA is being established and introduces a new IKEv2 exchange 
> > IKE_FOLLOWUP_KE to perform
> >them when IKE SA is up (during rekeys or creating additional Child SAs).
> >
> > is it now OK?
> 
> Also fine :)

Great!

> >> I don't think it would hurt pointing to Section 2.4 of RFC 7296. I see
> >> this as a likely possible implemention mistake.
> >
> > My problem with your proposal here is that this situation is not
> > specific to this document. In other words, whether the initiator
> > proposes any additional key exchanges or not, if an attacker
> > manages to send a response before the genuine responder
> > and the initiator continues establishing IKE SA using this response,
> > then it will fail. There is nothing specific to the multiple key exchanges.
> > And we implicitly assume that implementations follow RFC 7296.
> 
> I want to prevent code like:
> 
>   if (AKE-required && !AKE-received)
>   return STF_FATAL// kills state
> 
> I know it is a "reminder", but I think an important one.

RFC 7296 states that the proposed defense against this attack is a MAY
(due to relatively high cost of the defense). So, I've added the following text 
at the end
of 3.2.1:

It is possible that an attacker manages to send a response to the 
initiator's IKE_SA_INIT request 
before the genuine responder. If the initiator continues creating IKE SA 
using this response, the attempt will fail.
Implementers may wish to consider a possible defense technique described in 
Section 2.4 of [RFC7296].

We really cannot advise something marked as MAY, we can only remind that this 
technique exists.

> >> Just give it some thought, but if we leave it as is that is fine too.
> >
> > As I'm lazy, I prefer to do nothing here (unless you or my co-authors 
> > strongly disagree :-))
> 
> Fine with me. Can't get worse than CREATE_CHILD_SA I guess :P

CREATE_CHILD_SA_FOLLOWUP_KEY_EXCHANGE? :-)
Oh, sorry, you seemed to propose something similar :-)

> >> I also think that is only a reason to ignore the CREATE_CHILD_SA, and
> >> not a reason to destroy the existing IKE SA (and thus any existing Child
> >> SA)
> >
> > 

Re: [IPsec] Paul Wouters' Discuss on draft-ietf-ipsecme-ikev2-multiple-ke-10: (with DISCUSS and COMMENT)

[Valery Smyslov]

HI CJ,

 

From: CJ Tjhai [mailto:c...@post-quantum.com] 
Sent: Wednesday, November 30, 2022 12:30 PM
To: Paul Wouters
Cc: Valery Smyslov; Paul Wouters; The IESG; 
draft-ietf-ipsecme-ikev2-multiple...@ietf.org; ipsecme-cha...@ietf.org; 
ipsec@ietf.org WG; Tero Kivinen
Subject: Re: [IPsec] Paul Wouters' Discuss on 
draft-ietf-ipsecme-ikev2-multiple-ke-10: (with DISCUSS and COMMENT)

 

Hi Paul, Hi Valery

 

@Paul Wouters <mailto:p...@nohats.ca>  Many thanks for your thorough review of 
the draft, really appreciate that.

 

Where to put the "Design Criteria" section has been bothering me for quite a 
while. Personally, I prefer to have this section to be moved as an appendix.

 

I'll update Valery's PR with this change, unless there is an objection from any 
of the other co-authors.

 

  No objections from me. Thank you for doing this.

 

  Regards,

  Valery.

 

Best wishes,

CJ

 

 

 

On Tue, 29 Nov 2022 at 18:49, Paul Wouters  wrote:

On Tue, 29 Nov 2022, Valery Smyslov wrote:

>> ### IANA entries mentions in the Introduction ?
>>
>> Shouldn't the introduction mention this draft introduces the IKE_FOLLOWUP_KE 
>> Exchange
>> and the STATE_NOT_FOUND Notify Message Type, along with additional entries 
>> to the
>> (now renamed) Key Exchanges Methods registry?
>
> I'm a bit puzzled here. The introduction currently is silent about the 
> details of the proposed
> extension. Do you want to add them there? Or did you mean the Abstract,
> (which indeed contains some details) to be augmented with more details?

Yes I meant the abstract :)

>> ### Additional key exchanges DoS ?
>>
>> The following paragraph raised an issue for me:
>> ```
>>If the responder selects NONE for some Additional Key Exchange types
>>(provided they are proposed by the initiator), then the corresponding
>>IKE_INTERMEDIATE exchanges MUST NOT take place.
>> ```
>> If the initiator's local policy requires at least one Additional Key 
>> Exchange,
>> an attacker sending back a quick reply with only NONE replies would be a DoS.
>> I think similar to like the original IKE_SA_INIT, perhaps we need to give 
>> some
>> advise that if the local policy would lead to permanent failure, that it
>> should wait for other (more legitimate) responses to this IKE_SA_INIT ?
>
> As you pointed out, the situation is exactly the same as described
> in Section 2.4 of RFC 7296:
>
>   One type of DoS attack on the initiator of an IKE SA can be avoided
>   if the initiator takes proper care: since the first two messages of
>   an SA setup are not cryptographically protected, an attacker could
>   respond to the initiator's message before the genuine responder and
>   poison the connection setup attempt.  To prevent this, the initiator
>   MAY be willing to accept multiple responses to its first message,
>   treat each response as potentially legitimate, respond to each one,
>   and then discard all the invalid half-open connections when it
>   receives a valid cryptographically protected response to any one of
>   its requests.  Once a cryptographically valid response is received,
>   all subsequent responses should be ignored whether or not they are
>   cryptographically valid.
>
> Since the draft adds nothing new into the negotiation mechanism
> in the IKE_SA_INIT, I see no need to reiterate this advice here
> (otherwise we may want to repeat a lot of text from base IKEv2 spec :-)).

I don't think it would hurt pointing to Section 2.4 of RFC 7296. I see
this as a likely possible implemention mistake.

>> ### ADDITIONAL_KEY_EXCHANGE
>> ```
>>After IKE SA is created the window size may be greater than one and
>>multiple concurrent exchanges may be in progress, it is essential to
>>link the IKE_FOLLOWUP_KE exchanges together
>> ```
>> I had some trouble figuring out why these are needed. For Child SA rekeys, 
>> these
>> would not be needed, because we would have an old SPI and MSGID that would 
>> make the
>> order obvious. But for adding addtional Child SA's, we have no old SPI. But 
>> we have
>> a new SPI on the initiator (and then a new SPI on the responder in the 
>> answer. Since
>> these are coupled by MSGID, I wonder if ADDITIONAL_KEY_EXCHANGE is really 
>> needed?
>> Looking at the useful appendix examples, I realise that the IKE_FOLLOWUP_KE 
>> exchange
>> does not have an SA payload so no SPI, so it makes sense to me now. Perhaps 
>> a sentence
>> in the document would be useful to explain this?
>
> How about:
>
>   After IKE SA is created the window size may be greater than one and
>   multiple concurrent exchanges may be in progress, it 

Re: [IPsec] Paul Wouters' Discuss on draft-ietf-ipsecme-ikev2-multiple-ke-10: (with DISCUSS and COMMENT)

[Valery Smyslov]

Hi Paul,

let's continue :-)

I snipped the text where we are in agreement.

> -Original Message-
> From: Paul Wouters [mailto:p...@nohats.ca]
> Sent: Tuesday, November 29, 2022 9:49 PM
> To: Valery Smyslov
> Cc: 'Paul Wouters'; 'The IESG'; 
> draft-ietf-ipsecme-ikev2-multiple...@ietf.org; ipsecme-cha...@ietf.org;
> ipsec@ietf.org WG; Tero Kivinen
> Subject: Re: [IPsec] Paul Wouters' Discuss on 
> draft-ietf-ipsecme-ikev2-multiple-ke-10: (with DISCUSS and
> COMMENT)
> 
> On Tue, 29 Nov 2022, Valery Smyslov wrote:
> 
> >> ### IANA entries mentions in the Introduction ?
> >>
> >> Shouldn't the introduction mention this draft introduces the 
> >> IKE_FOLLOWUP_KE Exchange
> >> and the STATE_NOT_FOUND Notify Message Type, along with additional entries 
> >> to the
> >> (now renamed) Key Exchanges Methods registry?
> >
> > I'm a bit puzzled here. The introduction currently is silent about the 
> > details of the proposed
> > extension. Do you want to add them there? Or did you mean the Abstract,
> > (which indeed contains some details) to be augmented with more details?
> 
> Yes I meant the abstract :)

I'm a bit reluctant to add all this information to the abstract. It is already 
a bit too long
(since Éric and Warren suggested to augment it with the explanation text of how
this design helps in situation when PQ algorithms are less trusted). So 
currently
the abstract is:

This document describes how to extend the Internet Key Exchange Protocol
Version 2 (IKEv2) to allow multiple key exchanges to take place 
while computing a shared secret during a Security Association (SA) 
setup.

The primary application of this feature in IKEv2 is the ability to 
perform one or more 
post-quantum key exchanges in conjunction with the classical (Elliptic 
Curve) Diffie-Hellman (EC)DH key exchange,
so that the resulting shared key is resistant against quantum computer 
attacks.
Since there is currently no post-quantum key exchange that is trusted at
the level that (EC)DH is trusted for against conventional (non-quantum)
adversaries, performing multiple key exchanges with different 
post-quantum algorithms along
with the well-established classical key exchange algorithms addresses 
this concern, since the
overall security is at least as strong as each individual primitive.

Another possible application for this extension is the ability to 
combine several key exchanges 
in situations when no single key exchange algorithm is trusted by both 
initiator and responder.

   This document updates RFC7296 by renaming a transform type 4 from 
"Diffie-Hellman Group (D-H)"
to "Key Exchange Method (KE)" and renaming a field in the Key Exchange 
Payload from "Diffie-Hellman Group Num"
to "Key Exchange Method". It also renames an IANA registry for this 
transform type 
from "Transform Type 4 - Diffie-Hellman Group Transform IDs" to 
"Transform Type 4 - Key Exchange Method Transform IDs". These changes 
generalize 
key exchange algorithms that can be used in IKEv2.

Do you *really* want to make it longer? I'm not sure that if we just mention 
the names of the added exchange and notifies, that will help readers of the 
abstract 
to understand what this document is about...

[update]

I've just noticed your message sent in response to Warren. So, since you insist 
:-),
I suggest adding the following text before "This document updates...":

This document utilizes the IKE_INTERMEDIATE exchange to perform multiple 
key exchanges when
an IKE SA is being established and introduces a new IKEv2 exchange 
IKE_FOLLOWUP_KE to perform 
them when IKE SA is up (during rekeys or creating additional Child SAs).

is it now OK?

[/update]

> >> ### Additional key exchanges DoS ?
> >>
> >> The following paragraph raised an issue for me:
> >> ```
> >>If the responder selects NONE for some Additional Key Exchange types
> >>(provided they are proposed by the initiator), then the corresponding
> >>IKE_INTERMEDIATE exchanges MUST NOT take place.
> >> ```
> >> If the initiator's local policy requires at least one Additional Key 
> >> Exchange,
> >> an attacker sending back a quick reply with only NONE replies would be a 
> >> DoS.
> >> I think similar to like the original IKE_SA_INIT, perhaps we need to give 
> >> some
> >> advise that if the local policy would lead to permanent failure, that it
> >> should wait for other (more legitimate) responses to this IKE_SA_INIT ?
> >
> > As you pointed out, the situa

Re: [IPsec] Warren Kumari's No Objection on draft-ietf-ipsecme-ikev2-multiple-ke-10: (with COMMENT)

[Valery Smyslov]

Hi Warren,

thank you for your comments. Please see inline.

> -Original Message-
> From: Warren Kumari via Datatracker [mailto:nore...@ietf.org]
> Sent: Wednesday, November 30, 2022 1:19 AM
> To: The IESG
> Cc: draft-ietf-ipsecme-ikev2-multiple...@ietf.org; ipsecme-cha...@ietf.org; 
> ipsec@ietf.org;
> kivi...@iki.fi; kivi...@iki.fi; g...@apnic.net
> Subject: Warren Kumari's No Objection on 
> draft-ietf-ipsecme-ikev2-multiple-ke-10: (with COMMENT)
> 
> Warren Kumari has entered the following ballot position for
> draft-ietf-ipsecme-ikev2-multiple-ke-10: 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-multiple-ke/
> 
> 
> 
> --
> COMMENT:
> --
> 
> Thank you for writing this document (and also making it easy for someone like
> me to understand :-)) Also thanks to Geoff Huston for his DNSDOR review
> (https://datatracker.ietf.org/doc/review-ietf-ipsecme-ikev2-multiple-ke-07-dnsdir-lc-huston-2022-10-
> 10/)
> 
> I have a few non-blocking comments -- feel free to address them or not.
> 
> I think that moving Section 2, Bullet 2 towards to top of the document would
> help the reader better understand why this document exists...

Éric has suggested to put this or similar text to the Abstract, so it is now 
there.
The Abstract now is:

This document describes how to extend the Internet Key Exchange Protocol
Version 2 (IKEv2) to allow multiple key exchanges to take place 
while computing a shared secret during a Security Association (SA) 
setup.

The primary application of this feature in IKEv2 is the ability to 
perform one or more 
post-quantum key exchanges in conjunction with the classical (Elliptic 
Curve) Diffie-Hellman (EC)DH key exchange,
so that the resulting shared key is resistant against quantum computer 
attacks.
Since there is currently no post-quantum key exchange that is trusted at
the level that (EC)DH is trusted for against conventional (non-quantum)
adversaries, performing multiple key exchanges with different 
post-quantum algorithms along
with the well-established classical key exchange algorithms addresses 
this concern, since the
overall security is at least as strong as each individual primitive.

Another possible application for this extension is the ability to 
combine several key exchanges 
in situations when no single key exchange algorithm is trusted by both 
initiator and responder.

   This document updates RFC7296 by renaming a transform type 4 from 
"Diffie-Hellman Group (D-H)"
to "Key Exchange Method (KE)" and renaming a field in the Key Exchange 
Payload from "Diffie-Hellman Group Num"
to "Key Exchange Method". It also renames an IANA registry for this 
transform type 
from "Transform Type 4 - Diffie-Hellman Group Transform IDs" to 
"Transform Type 4 - Key Exchange Method Transform IDs". These changes 
generalize 
key exchange algorithms that can be used in IKEv2.

Is it OK?

> 1: "While solving such a problem remains difficult with current
>computing power, it is believed that general purpose quantum
>computers will be able to solve this problem, implying that the
>security of IKEv2 is compromised."
> 
> 'solving such a problem remains difficult with current computing power' 
> implies
> that they *can* be solved with current computing power, while 'it is 
> *believed*
> that general purpose quantum computers will be able to solve this problem'
> implies that quantum only *might* be able to solve them...this makes it sound
> like quantum machines are less of a concern than current ones :-). Perhaps
> 'general purpose quantum computers will *easily* be able to solve this
> problem'? Or 'solving such a problem is infeasible with current computing
> power'? (handwaving away trivial parameters) My suggestion isn't great, but
> hopefully I've managed to explain my concern?

I see your point. I would use one of your suggestions, unless my co-authors 
disagree:

While solving such
a problem remains infeasible with current computing power, it is
believed that general purpose quantum computers will be able to solve
this problem, implying that the security of IKEv2 is compromised.

(I don't like "easily", since it's very subjective). 

> 2: Design Criteria - 3)   Focus on post-quantum confidentiality.

Re: [IPsec] Erik Kline's No Objection on draft-ietf-ipsecme-ikev2-multiple-ke-10: (with COMMENT)

[Valery Smyslov]

Hi Erik,

thank you for your comments. Please see inline.

> -Original Message-
> From: Erik Kline via Datatracker [mailto:nore...@ietf.org]
> Sent: Wednesday, November 30, 2022 6:16 AM
> To: The IESG
> Cc: draft-ietf-ipsecme-ikev2-multiple...@ietf.org; ipsecme-cha...@ietf.org; 
> ipsec@ietf.org;
> kivi...@iki.fi; kivi...@iki.fi
> Subject: Erik Kline's No Objection on 
> draft-ietf-ipsecme-ikev2-multiple-ke-10: (with COMMENT)
> 
> Erik Kline has entered the following ballot position for
> draft-ietf-ipsecme-ikev2-multiple-ke-10: 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-multiple-ke/
> 
> 
> 
> --
> COMMENT:
> --
> 
> # Internet AD comments for draft-ietf-ipsecme-ikev2-multiple-ke-10
> CC @ekline
> 
> ## Nits
> 
> ### S2
> 
> * s/FIPS complaint/FIPS compliant/

Funny typo :-) Fixed, thank you.

> ### S3.2.1
> 
> * I take it that it's not relevant to the example flow that there is no
>   transform called AKE4.  :-)

This was done on purpose, to illustrate the text in the para above:

   The initiator MAY propose non-consecutive Additional Key Exchange
   transforms, for example proposing Additional Key Exchange 2 and
   Additional Key Exchange 5 transforms only.

> ### S5
> 
> * "can dwarfed"?

This has been  already changed to:

Simply increasing the key length can mitigate this attack.

by request from Sean.

The updated PR is available at:
https://github.com/post-quantum/ietf-pq-ikev2/pull/22

Regards,
Valery.

___
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-multiple-ke-10: (with COMMENT)

[Valery Smyslov]

Hi Éric,

> Hello Valery,
> 
> TL;DR:  Thanks for your reply and your comments. I agree with them ;-)
> 
> If you want a more detailed reply, then look for EV> below

OK, I snipped the text where we have an agreement.

> Regards
> 
> -éric

[snipped]

> > The bullet 2) is a nice explanation about *why* there must be multiple 
> key
> > exchanges with different methods. Until reading that part, I was really
> > wondering why this I-D was about the link with PQC and multiple key 
> exchanges.
> > Should this be mentioned in the abstract already ?
> 
> I don't mind, but as far as I know, IESG wants abstract to be short :-)
> If you (and other ADs) think it's a good idea, then we'll add this text.
> 
> EV> I know about short abstract, but they should also give an idea of the 
> content & purpose

If it is OK with the IESG we'll extend the abstract with this text. It will 
look like:

This document describes how to extend the Internet Key Exchange Protocol
Version 2 (IKEv2) to allow multiple key exchanges to take place 
while computing a shared secret during a Security Association (SA) 
setup.

The primary application of this feature in IKEv2 is the ability to 
perform one or more 
post-quantum key exchanges in conjunction with the classical (Elliptic 
Curve) Diffie-Hellman (EC)DH key exchange,
so that the resulting shared key is resistant against quantum computer 
attacks.
Since there is currently no post-quantum key exchange that is trusted at
the level that (EC)DH is trusted for against conventional (non-quantum)
adversaries, performing multiple key exchanges with different 
post-quantum algorithms along
with the well-established classical key exchange algorithms addresses 
this concern, since the
overall security is at least as strong as each individual primitive.

Another possible application for this extension is the ability to 
combine several key exchanges 
in situations when no single key exchange algorithm is trusted by both 
initiator and responder.

   This document updates RFC7296 by renaming a transform type 4 from 
"Diffie-Hellman Group (D-H)"
to "Key Exchange Method (KE)" and renaming a field in the Key Exchange 
Payload from "Diffie-Hellman Group Num"
to "Key Exchange Method". It also renames an IANA registry for this 
transform type 
from "Transform Type 4 - Diffie-Hellman Group Transform IDs" to 
"Transform Type 4 - Key Exchange Method Transform IDs". These changes 
generalize 
key exchange algorithms that can be used in IKEv2.

Hope it's now clear and not *too* long :-)

> > Should "FIPS" be prefixed by "USA" as in "USA FIPS" ?
> 
> I don't know, rely on my co-authors (actually it seems that
> this is a well-known organization outside USA, but formally you are 
> right).
> 
> EV> I live a in Federal state as well (Belgium), so while I understand that 
> FIPS stands for the USA one, let's
> be inclusive. Up to you and the authors.

No problem, will change the text to:

USA Federal Information Processing Standards (FIPS) compliance.  IPsec 
is widely used in Federal Information
Systems and FIPS certification is an important requirement.
However, at the time of writing, none of the algorithms that is believed
to be post-quantum is FIPS compliant yet.  Nonetheless, it is possible 
to combine
this post-quantum algorithm with a FIPS complaint key establishment 
method so that
the overall design remains FIPS compliant [NISTPQCFAQ].

Is it OK that prefix "USA" is added once and not to every appearance of "FIPS" ?

The updated PR is available at:
 https://github.com/post-quantum/ietf-pq-ikev2/pull/22
 
Regards,
Valery.

> > ## Notes
> >
> > This review is in the ["IETF Comments" Markdown format][ICMF], You can 
> use the
> > [`ietf-comments` tool][ICT] to automatically convert this review into
> > individual GitHub issues.
> >
> > [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
> > [ICT]: https://github.com/mnot/ietf-comments
> >
> 
> 


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

Re: [IPsec] Secdir telechat review of draft-ietf-ipsecme-ikev2-multiple-ke-10

[Valery Smyslov]

Hi Sean,

[snipped]

> > I'm not sure the DEs have enough qualification to judge whether the proposed
> > algorithm is good or bad with its cryptographic properties. I believe it is 
> > the CFRG's task
> > to bless algorithms and the DEs should only pay attention to is whether
> > the proposed algorithm meets the protocol restrictions (and those are
> > listed in Section 4.1 for the DEs).
> 
> Valery you’re not giving yourself and Tero enough credit ;) 

:-)

> But, you did say exactly what I hoped you
> would say, in that the CFRG is going to evaluate the alg. Note sure if this 
> needs to be documented.

In my opinion it is not needed. While CFRG generally evaluates most of 
algorithms
that populate this registry, some of them could be added without this 
evaluation.
I mean those algorithm that were specified outside of IETF or published via ISE 
(I'm here speaking as author of RFC 9227 and draft-smyslov-ike2-gost).

In IPSECME we have RFC 7321 and RFC 8247 that list the currently recommended 
algorithms,
and these RFCs are updated from time to time, because even CFRG "blessing" is 
not eternal :-)

Regards,
Valery.



___
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-multiple-ke-10: (with COMMENT)

[Valery Smyslov]

Hi Éric,

thank you for your comments. Please see inline.

> -Original Message-
> From: Éric Vyncke via Datatracker [mailto:nore...@ietf.org]
> Sent: Tuesday, November 29, 2022 12:38 PM
> To: The IESG
> Cc: draft-ietf-ipsecme-ikev2-multiple...@ietf.org; ipsecme-cha...@ietf.org; 
> ipsec@ietf.org;
> kivi...@iki.fi; kivi...@iki.fi; charl...@computer.org; g...@apnic.net
> Subject: Éric Vyncke's No Objection on 
> draft-ietf-ipsecme-ikev2-multiple-ke-10: (with COMMENT)
> 
> Éric Vyncke has entered the following ballot position for
> draft-ietf-ipsecme-ikev2-multiple-ke-10: 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-multiple-ke/
> 
> 
> 
> --
> COMMENT:
> --
> 
> 
> # Éric Vyncke, INT AD, comments for draft-ietf-ipsecme-ikev2-multiple-ke-10
> CC @evyncke
> 
> Thank you for the work put into this document. Even if my IPsec knowledge is
> now very dated, I find it relatively easy to read.

Thank you.

> 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 write-up including the WG
> consensus *but* the justification of the intended status is missing.
> 
> Other thanks to Geoff Huston for his Last Call DNS directorate review at:
> https://datatracker.ietf.org/doc/review-ietf-ipsecme-ikev2-multiple-ke-07-dnsdir-lc-huston-2022-10-10/
> 
> Please note that Charles Perkins is the Internet directorate reviewer (at my
> request) and you may want to consider this int-dir reviews as well when 
> Charles
> will complete the review (no need to wait for it though):
> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-multiple-ke/reviewrequest/16618/
> 
> I hope that this review helps to improve the document,
> 
> Regards,
> 
> -éric
> 
> ## COMMENTS
> 
> Out of all Paul Wouters's points, I support the last one about AH (I am not
> experience enough to appreciate the other ones). It is also related to bullet
> 3) of section 2.

I have already commented this in my response to Paul.
So, the document focuses on PQ security, but also has
another application in mind - the ability to combine 
several different key exchange methods so, that the resulting
shared secret depends on all of them. This can be useful 
without any PQ algorithms - e.g. in a situation
when each of the peers trust only its favorite
key exchange algorithms, so that there is no any single
one that is trusted by the both. In this case the draft 
allows to use two, so that each peer will be sure
that its favorite algorithm is used.

In this context AH still may be used
(well, it is not deprecated yet?).

> ### Missing reference RFC 8247
> 
> As indicated by idnits tool, RFC 8247 is used as a reference but is not 
> defined
> ;-)

Ah, we managed to confuse idnits (which in fact is not too difficult) :-)

This document does not reference RFC 8247, but it contains 
the text to be placed at the IANA registry page as a Note,
and this text contains a "[RFC8247]", but this reference 
is in the context of IANA page :-)

> ### Section 2
> 
> The bullet 2) is a nice explanation about *why* there must be multiple key
> exchanges with different methods. Until reading that part, I was really
> wondering why this I-D was about the link with PQC and multiple key exchanges.
> Should this be mentioned in the abstract already ?

I don't mind, but as far as I know, IESG wants abstract to be short :-)
If you (and other ADs) think it's a good idea, then we'll add this text.

> Should "FIPS" be prefixed by "USA" as in "USA FIPS" ?

I don't know, rely on my co-authors (actually it seems that 
this is a well-known organization outside USA, but formally you are right).

> ## NITS
> 
> ### Section 1.2
> 
> `payloads longer than 64k` suggest to specify the units of measure.

Changed to 64 Kbytes.

Thank you!

The updated PR is available at:
https://github.com/post-quantum/ietf-pq-ikev2/pull/22


Regards,
Valery.


> ## Notes
> 
> This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
> [`ietf-comments` tool][ICT] to automatically convert this review into
> individual GitHub issues.
> 
> [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
> [ICT]: https://github.com/mnot/ietf-comments
> 


___
IPsec mailing list
IPsec@ietf.org

Re: [IPsec] Paul Wouters' Discuss on draft-ietf-ipsecme-ikev2-multiple-ke-10: (with DISCUSS and COMMENT)

[Valery Smyslov]

Hi Paul,

thank you for your thorough review, please see inline.

> -Original Message-
> From: Paul Wouters via Datatracker [mailto:nore...@ietf.org]
> Sent: Tuesday, November 29, 2022 12:09 AM
> To: The IESG
> Cc: draft-ietf-ipsecme-ikev2-multiple...@ietf.org; ipsecme-cha...@ietf.org; 
> ipsec@ietf.org;
> kivi...@iki.fi; kivi...@iki.fi
> Subject: Paul Wouters' Discuss on draft-ietf-ipsecme-ikev2-multiple-ke-10: 
> (with DISCUSS and
> COMMENT)
> 
> Paul Wouters has entered the following ballot position for
> draft-ietf-ipsecme-ikev2-multiple-ke-10: Discuss
> 
> 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-multiple-ke/
> 
> 
> 
> --
> DISCUSS:
> --
> 
> # Sec AD review of draft-ietf-ipsecme-ikev2-multiple-ke-10
> 
> CC @paulwouters
> 
> 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.
> 
> This review uses the format specified in 
> https://github.com/mnot/ietf-comments/ which allows
> automated tools to process items (eg to produce github issers)
> 
> Let me first apologize to Valery for not getting to review this document 
> earlier. He surely
> reminded me enough times to do it before it landed at the IESG.

No problem, I did know that you wouldn't escape this review :-)

> This is a very well written document. Thanks to everyone involved. While I 
> have a few DISCUSS
> comments, these should be easy to address or convince me why no changes are 
> required.

Thank you.

> Note to self (and Valery): draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt 
> needs to be updated
> to support this document. It currently only supports sending one KE payload.

OK. I don't think it would be difficult.

> ## DISCUSS
> 
> 
> ### IANA entries mentions in the Introduction ?
> 
> Shouldn't the introduction mention this draft introduces the IKE_FOLLOWUP_KE 
> Exchange
> and the STATE_NOT_FOUND Notify Message Type, along with additional entries to 
> the
> (now renamed) Key Exchanges Methods registry?

I'm a bit puzzled here. The introduction currently is silent about the details 
of the proposed
extension. Do you want to add them there? Or did you mean the Abstract,
(which indeed contains some details) to be augmented with more details?

> ### Additional key exchanges DoS ?
> 
> The following paragraph raised an issue for me:
> ```
>If the responder selects NONE for some Additional Key Exchange types
>(provided they are proposed by the initiator), then the corresponding
>IKE_INTERMEDIATE exchanges MUST NOT take place.
> ```
> If the initiator's local policy requires at least one Additional Key Exchange,
> an attacker sending back a quick reply with only NONE replies would be a DoS.
> I think similar to like the original IKE_SA_INIT, perhaps we need to give some
> advise that if the local policy would lead to permanent failure, that it
> should wait for other (more legitimate) responses to this IKE_SA_INIT ?

As you pointed out, the situation is exactly the same as described 
in Section 2.4 of RFC 7296:

   One type of DoS attack on the initiator of an IKE SA can be avoided
   if the initiator takes proper care: since the first two messages of
   an SA setup are not cryptographically protected, an attacker could
   respond to the initiator's message before the genuine responder and
   poison the connection setup attempt.  To prevent this, the initiator
   MAY be willing to accept multiple responses to its first message,
   treat each response as potentially legitimate, respond to each one,
   and then discard all the invalid half-open connections when it
   receives a valid cryptographically protected response to any one of
   its requests.  Once a cryptographically valid response is received,
   all subsequent responses should be ignored whether or not they are
   cryptographically valid.

Since the draft adds nothing new into the negotiation mechanism 
in the IKE_SA_INIT, I see no need to reiterate this advice here
(otherwise we may want to repeat a lot of text from base IKEv2 spec :-)).

> ### ADDITIONAL_KEY_EXCHANGE
> ```
>After IKE SA is created the window size may be greater than one and
>multiple concurrent exchanges may be in progress, it is essential to
>link the IKE_FOLLOWUP_KE exchanges together
> ```
> I had some trouble figuring out why these are needed. For Child SA rekeys, 
> these
> 

Re: [IPsec] Secdir telechat review of draft-ietf-ipsecme-ikev2-multiple-ke-10

[Valery Smyslov]

Hi Sean,

thank you for your review. Please, see inline.

> Reviewer: Sean Turner
> Review result: Has Nits
> 
> Hi! Thanks for the well written draft. I really liked Appendix B that includes
> the tried but discarded designs.

Thank you.

> Issue worth discussing (and it might be a short discussion):
> 
> Are there any instructions that the DEs needs to make sure that this registry
> is not populated with PQ-wanna-be Transforms? E.g., I show up my shiny new 
> (and
> supposedly) PQ resistant alg and the DE says 

I'm not sure the DEs have enough qualification to judge whether the proposed 
algorithm is good or bad with its cryptographic properties. I believe it is the 
CFRG's task 
to bless algorithms and the DEs should only pay attention to is whether 
the proposed algorithm meets the protocol restrictions (and those are 
listed in Section 4.1 for the DEs).

> Nits:
> 
> The use of “we” is a style thing that I would change, but if the WG/IESG are
> good with it I can get on board too.

I'll rely on my co-authors on this :-)

> s1.2, last para: “require such a requirement” is a bit awkward. How about 
> “have
> such a requirement” or “levy such a requirement”?

Changed to "have such a requirement".

> s2, hybrid: I think you might want to include some words by what you mean by
> “hybrid”? Maybe as simple as copy some of the text from the 1st para of s3.1
> forward, “when multiple key exchanges are performed and the calculated shared
> key depends on all of them”.
> 
> s3.1, s/Note that with this semantics,/Note that with these semantics,

Fixed, thank you.

> s4.1:
> 
> s/must/MUST in the DE instructions?

Hm, I may be wrong, but in my understanding RFC2119 words have their meaning
only in the context of an RFC/I-D (to which the DE instructions don't belong 
to)...

> s/addition,any/addition, any

Fixed.

> s5:
> 
> s/dwarfed/ with thwart or mitigate

Changed to mitigate.

> s/the data need to remain/the data needs to remain

Fixed.

> A.1:
> 
> s/as follows/as follows.

OK.

> s/SKEYSEED(1)  …. )./SKEYSEED(1) … )

Done.

> s/{SK_d(1) … SPIr)./{SK_d(1) … SPIr)

Ditto.

> Is this missing:
> 
>  The updated SKEYSEED value is then used to derive the following
>  keying materials
> 
> between these two lines:
> 
>  SKEYSEED(2) = prf(SK_d(1), SK(2) | Ni | Nr)
>  {SK_d(2) | SK_ai(2) | SK_ar(2) | SK_ei(2) | SK_er(2) | SK_pi(2) |
> SK_pr(2)} = prf+ (SKEYSEED(2), Ni | Nr | SPIi | SPIr)

Well, I think it must be clear enough from the formulas - 
we first calculate new SKEYSEED (SKEYSEED(2)) and then
use it to calculate new SK_* keys (SK_*(2)).
We purposely added indexes in round braces to make it easier 
for readers to figure out "generations" of the keys.
Do you think it is not clear enough?

> A.4:s/a security association/an IKE SA

OK.

The changes can be reviewed in the PR:
https://github.com/post-quantum/ietf-pq-ikev2/pull/22

Regards,
Valery.


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