Hi Paul,
> Paul Wouters has entered the following ballot position for
> draft-ietf-ipsecme-g-ikev2-20: 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-g-ikev2/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> Thanks for the document. It is very clear. I have some questions and comments
> we should talk through, but nothing that I think will be a problem.
Thank you.
> I wonder why the design for GSA_AUTH is not more genericly done, so that
> it would be possible to mix regular IKE/Child SAs with GSAs ? It seems
> things are now tied to the IKE_SA_INIT followed by GSA_AUTH, but there
> is no CREATE_CHILD_SA method to start a GSA_AUTH ?
This is an interesting question. Technically it is possible to mix creating
unicast Child SAs
with joining multicast GSAs using the same IKE SA between the GM and the GCKS
(BTW, the GSA_REGISTRATION exchange is used to join a group at any time once
IKE SA is created).
But I'm not sure this is a good idea. The IKE SA authenticates the peers
and in general authentication requirement for unicast communication
will be different from those for joining multicast group. I think that
it is clearer if different IKE SAs are used for these purposes.
> It seems the problem of a fast changing group membership is somewhat
> ignored (as compared to MLS that made it a fundamental part of the
> protocol). There is enough room in the current design that this can
> probably be added at a later stage, if this document sees deployment
> and such scale issues become a problem.
Hmm. Not sure I got you right. I don't think that the problem is ignored
(unless I miss what the essence of the problem is). The addition of new
members doesn't affect existing group members and doesn't require
any change in the current GSA. The problem arises if in case
of group member removal you want to make sure that the removed member cannot
read
the future traffic. In this case you can rely on LKH, which allows to
rekey GSA using multicast message in such a way, that the removed
group member would not be able to learn the new GSA keys.
Thus, every removal of group member will require sending one
multicast message that will update GSA keys for the rest of the group.
I think this is fairly efficient.
Let me know if I missed something.
> Now for specific text issues:
>
>
> I don't fully understand this sentence:
>
> After the GM and GCKS complete the IKE_SA_INIT exchange, the
> GSA_AUTH exchange MUST complete before any other exchanges defined
> in this document can be done. GSA_AUTH is used to authenticate
> the previous exchanges, exchange identities and certificates.
>
> If an IKE_INTERMEDIATE was required, this would happen after the IKE_SA_INIT,
> but before the GSA_AUTH exchange. Also, wouldn't it be valid to setup either
This text was written before the birth of IKE_INTERMEDIATE :-)
This text formally doesn't prevent IKE_INTERMEDIATE, it only says that
IKE_AUTH MIST complete after IKE_SA_INIT and before any other exchanges
defined in this document :-) And Section 2.1 allows IKE_INTERMEDIATE explicitly.
But we can change the text to eliminate confusion:
OLD:
After the GM and GCKS complete the IKE_SA_INIT exchange, the GSA_AUTH
exchange MUST complete before any other exchanges defined in this
document can be done. GSA_AUTH is used to authenticate the previous
exchanges, exchange identities and certificates. G-IKEv2 also uses
this exchange for group member registration and authorization.
NEW:
The GSA_AUTH exchange MUST complete before any other exchanges
defined in this document can be done. GSA_AUTH is used to
authenticate the previous exchanges, exchange identities and
certificates. G-IKEv2 also uses this exchange for group member
registration and authorization.
> a regular IKE SA with Child SA, or a Childless SA, and only then decide to
> run a GSA_AUTH exchange? In which case "GSA_AUTH is used to authenticate
> the previous exchanges" makes no sense.
The GSA_REGISTRATION exchange would be used in this case.
But please see above.
>
> Initiator (GM) Responder (GCKS)
> -------------------- ------------------
> <-- HDR, SK{IDr, [CERT,] AUTH, N}
>
> Figure 5: GSA_AUTH Error Response
>
> Why would the responder in this case send its AUTH payload? Compare this to
> RFC7296 error handling here:
>
> If the error occurred on the responder, the notification is
> returned in the protected response, and is usually the only
> payload in that response.
>
> I would omit the AUTH payload in this case to keep it the same as regular
> IKEv2.
I don't think the cited text from RFC 7296 is relevant here. It is concerned
with
failed authentication. The full text from RFC 7296 Section 2.21.2 is:
All errors that occur in an IKE_AUTH exchange, causing the
authentication to fail for whatever reason (invalid shared secret,
invalid ID, untrusted certificate issuer, revoked or expired
certificate, etc.) SHOULD result in an AUTHENTICATION_FAILED
notification. If the error occurred on the responder, the
notification is returned in the protected response, and is usually
the only payload in that response.
The draft here (Section 2.3.1) is talking about errors that
prevent the GM to join the group:
If a GM included an SAg payload, and the GCKS chooses to
evaluate it, and the GCKS detects that the group member cannot
support the security policy defined for the group, then the GCKS
returns the NO_PROPOSAL_CHOSEN notification. Other types of error
notifications can be INVALID_GROUP_ID, AUTHORIZATION_FAILED or
REGISTRATION_FAILED.
Note, that in all these situations the GM authentication is succeeded,
but for various reasons the GM cannot be admitted to the group.
In many cases these reasons are fixable (e.g. the GM may try
to join some other group with GSA_RESISTRATION), thus
there is no point to prevent IKE SA from being created.
Note, that RFC7296 in Section 2.21.2 says:
If authentication has succeeded in the IKE_AUTH exchange, the IKE SA
is established; however, establishing the Child SA or requesting
configuration information may still fail. This failure does not
automatically cause the IKE SA to be deleted. Specifically, a
responder may include all the payloads associated with authentication
(IDr, CERT, and AUTH) while sending error notifications for the
piggybacked exchanges (FAILED_CP_REQUIRED, NO_PROPOSAL_CHOSEN, and so
on), and the initiator MUST NOT fail the authentication because of
this. The initiator MAY, of course, for reasons of policy later
delete such an IKE SA.
This is exactly the situation the text in the draft is about (in the context of
GSA and not unicast Child SA).
> Depending on its policy the GCKS MAY combine these two
> methods. For example, it may use the GSA_INBAND_REKEY to deliver
> key to the GMs in the group acting as senders
>
> Does this not assume those GMs MUST keep the IKE SAs up? Otherwise how can
> the GCKS
> send a GSA_INBAND_REKEY message? Is it expected to be able to reach all
> GM's by
> _initiating_ a new IKE SA? I haven't seen specified that the GCKS can initiate
> an IKE SA, so I assume this is not possible. Perhaps then the GCKS should send
> a notify in GSA_REGISTRATION to signal to the GMs to keep the IKE SA open ?
The GMs are expected to not delete IKE SA on their own.
If the GCKS doesn't need the IKE SA with a particular GM, it will close it.
If this GM needs it later (e.g. to join other group) it will re-create it.
In G-IKEv2 GMs play mostly passive role with keeping IKE SA.
They just create IKE SA to join the group. The GCKS decides whether
this SA should be kept or it is OK to delete it. See the last paras of Section
2.3.3 and 2.3.4.
The GCKS never initiates IKE SA to GMs.
> Do we _really_ have to support IPCOMP ?? :(
We have _to_be_able_ to support it :-) It is not deprecated yet, right ?
But it is optional, no need to support in implementations.
> The digital signing is applied to the concatenation of two chunks: A
> and P.
>
> Why is just signing Chunk A or just Chunk P not enough?
The digital signature is the only way for the GCKS to authenticate the
multicast rekey message,
since the group keys are known to all members. And since the message contains
new keys, it must be signed entirely, from the start of the header to the end
of last payload.
Since the content of the IV (which is in the middle of the message to be
signed) is unknown
at the time of signing, it is excluded from signing by splitting a message into
two chunks.
This approach works if even the size of IV is unknown at the time of signing,
since the Length fields are adjusted for the purpose of signing to be as if no
IV is present.
> What is the Responder SPI set to for a GSA_REKEY IKE message that is
> broadcast to all GMs?
In this case the concatenation of the Initiator SPI and Responder SPI is used
as an GIKE_UPDATE SA SPI (16 bytes).
The GCKS chooses all 16 bytes, there is no "Initiator" or "Responder" here.
> If a Data-Security SA is not rekeyed yet and is about to expire
> (a "soft lifetime" expiration is described in Section 4.4.2.1 of
> [RFC4301]), the GM SHOULD initiate a registration to the GCKS.
>
> Wouldn't this cause all DM's to simultaniously try to do IKE to do GCKS?
> Maybe at the very least, suggest some "fuzz" is used with the timer to
> ensure not all GMs rekey at the same second.
In normal case the GCKS must ensure this never happens by rekeying
GSA before its expiration time. This may happen if the GM misses
some multicast GIKE_UPDATE message, for example due to network loss.
We expect that this will be relatively seldom event affecting only
some GMs. Thus, we don't think any fuzz is needed.
> A similar problem happens after a REKEY_SA Delete operation. Maybe suggest
> some "fuzz" in the timing there as well? (although I guess every member
> wants to reconnect as fast as possible as to not miss any messages :/ )
Nobody wants to be left behind :-)
> Should some of these payloads have the Critical Flag set? I am not sure
> if matters much, as a peer not supporting this will fail anyway and if
> G-IKE is not used, these payloads do not appear (or if they do, it is
> broken anyway)
Yes. In addition, the unsupported peer will fail when it sees GSA_AUTH
(an unknown exchange) and won't parse it content at al :-)
> (*) If AEAD encryption algorithm is used, then INTEG transform
> MUST NOT be specified, otherwise it MUST be specified.
>
> It's ugly but I would also allow None as INTEG transform for AEAD. It has
> happened in
> the past and libreswan had interop issues with some peers due to no integ vs
> integ
> of 'None'.
OK. I changed the text as follows:
(*) If AEAD encryption algorithm is used, then INTEG transform either
MUST NOT be specified or MUST contain value NONE; otherwise it MUST
be specified and MUST contain value other than NONE.
> AUTHORIZATION_FAILED doesn't appear to be associated with G-IKEv2 by its
> name, and might
> get picked up my implementers who just look at the list to see what error to
> pick.
> Perhaps
> renaming it to GROUP_AUTHORIZATION_FAILED to make it more clear this is
> specific to G-IKEv2?
>
> Similar perhaps for REGISTRATION_FAILED ->
> GROUP_REGISTRATION_FAILED ?
> And SENDER -> GROUP_SENDER ?
We also have REGISTRATION_FAILED :-)
In general, I don't mind doing this, but we still have other new names and not
all of them
are associated with G-IKEv2 for outsiders. But this will be clear
for implementers from reading the Reference column in the IANA registry.
And actually the current names of AUTHORIZATION_FAILED and REGISTRATION_FAILED
are generic enough to be re-used in IKEv2 too, if needed :-)
SENDER is a different beast and I tend to agree with you here.
I renamed SENDER --> GROUP_SENDER
> The Security Considerations doesn't state that each GM basically needs to
> trust all
> other GMs
> not to share the content with members outside the group.
The GCKS acts as a third party that provides this trust, that only authorized
entities are admitted to the group.
But I added the following text to the Section 8:
When an entity joins the group and becomes a group member, it should
trust the GCKS that only authorized entities are admitted to the
group and that group members will not leak the information shared
within the group.
Let us know if more text is needed.
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
>
> The set of keys may include keys for encryption and authentication
>
> I would say "encryption and/or authentication" to include AEAD keys?
"and/or" looks bad for me, since it implies that authentication only is OK.
I think that the current text is better, - it states that there are keys for
encryption and authentication, These might be a single key for AEAD,
that provides both encryption and authentication, or separate keys for
encryption and authentication if separate algorithms are used :-)
> The second exchange GSA_AUTH is similar t
>
> Saying "second" is confusing here. it is not the second time the GSA_AUTH is
> used.
Changed to:
s/The second exchange GSA_AUTH/The second exchange called GSA_AUTH
> The GM may include an SAg payload declaring which Transforms it is
> willing to accept.
>
> The transform for the "IKE SA "(Rekey SA?) right? Not the GSA (Data-Security
> SA?)
The SAg payload should contain proposals for both Rekey SA (GIKE_UPDATE)
and for Data-Security SAs (ESP). The former allows the GCKS to check whether
existing Rekey SA will work with this GM, since the algorithms used in the
Rekey SA
may be different from algorithms negotiated for the unicast IKE SA between the
GM and the GCKS.
> If the group member finds the policy sent by the GCKS is unacceptable,
>
> I would preface this with text saying "if the GM has been successfully
> authenticated", to make it more clear we are talking about something
> unrelated to the previous section. Maybe also say "and the GM has
> authenticated the GCKS but finds the policy sent unacceptable"
Sounds reasonable. Changed to:
OLD:
If the group member finds the policy sent by the GCKS is
unacceptable...
NEW:
If the GSA_AUTH exchange is completed successfully, but the group
member finds the policy sent by the GCKS is unacceptable...
> by initiating the GSA_REGISTRATION exchange and sending IDg
> along with the NO_PROPOSAL_CHOSEN notification in it
>
> I would avoid "with" and "in it" as it makes it less clear what is in what.
> Perhaps:
>
> by initiating the GSA_REGISTRATION exchange with the IDg payload
> and the NO_PROPOSAL_CHOSEN notification payload.
>
> I assume in this case one would omit SAg payloads as well? So maybe say:
>
> by initiating the GSA_REGISTRATION exchange containing only the IDg
> payload and a NO_PROPOSAL_CHOSEN notification payload.
>
> (I now see this is explained in Figure 8, so maybe you can also just reference
> that instead of explaining it here in detail?)
Changed to:
... the member
SHOULD inform the GCKS about this by initiating the GSA_REGISTRATION
exchange with the IDg payload and the NO_PROPOSAL_CHOSEN notification
(see Figure 8).
> A GM requesting registration contacts the GCKS using the IKE_SA_INIT
> exchange.
>
> I am still puzzled by insisting on the GSA_AUTH in this way. Why is this not
> orthogonal to the exchange? Eg why can't you do a regular IKE SA and then a
> CREATE_CHILD_SA like GSA_AUTH exchange? I assume I will see something like
> this
> later on, in case the GM wants to join more than one group?
The GSA_REGISTRATION can be used for joining more groups.
It is not currently possible to create regular unicast IKE SA and then use it
to join the group
(with GSA_REGISTRATION). The problem is that to be able to transfer GSA
keys from the GCKS to the GM, a key wrap algorithm should be negotiated.
This is done in IKE_SA_INIT exchange with a new transform "Key Wrap Algorithm".
Thus, the IKE SA between the GM and the GCKS is a bit different from
regular IKE SA.
The draft is currently silent whether unicast Child SAs can be created between
the GM and the GCKS after the GSA_AUTH. Technically this is possible,
but I am not sure this is a good idea (see above).
> Other transform types SHOULD NOT be included as they will be ignored
>
> Why not MUST NOT ?
To create a room for future extensions. The semantics of SAg is a bit different
from regular SA payload:
to keep it small all supported transforms can be placed in a single proposal,
since the GCKS just needs to know whether algorithms are supported or nor
(in case when algorithms are cross-dependant multiple proposals can be created
too).
Thus, if some new transform types will be defined later, it is easier for the GM
to just put them in a single proposal inside SAg. In regular IKEv2 the
responder skips the entire
proposal if it doesn't understand some transform type. With this behavior,
the GM would have to send two proposals - one with new transform types
and one without them (taking other content intact), but this is inefficient.
Since the GCKS does not have to choose a single proposal (as in IKEv2),
it can just ignore the transform types it does not understand. This allows
the GM to place all transform types it knows about in a single proposal.
> The GCKS MUST ignore SPI length and SPI fields in the SAg payload.
>
> That is a bit weird. If the SPI length is set to 255 but there is no space in
> the packet for this, I would expect it to return an INVALID_SYNTAX and not
> "MUST ignore". Eg this MUST ignore would require special code handling. Maybe
> say "MUST NOT use" ?
Changed as you suggested.
> I am not a multicast expert, so this might be a wrong question but:
>
> and it is not going to receive back the data it sends, then it
> MUST install this SA only in the outgoing direction.
>
> What normally determines "is not going to receive back the data it sends" ? If
> it is part of the group, wouldn't it always get the traffic? Just that now the
> traffic doesn't match an SA so it will be dropped by the IPsec subsystem with
> an error there is no matching SA? Or does signaling you don't want to receive
> the data back prevent you from receiving the packets?
I am not a multicast expert either. From my understanding, the data you sent
can be returned back to you by the TCP/IP stack (before entering
the IPsec subsystem), but they won't get received back from the network.
So, if there is only one sender in the group, then it can install
outbound SA only. It won't receive own messages from the network,
thus no errors will be at IPsec level. It can receive own messages back
from TCP/IP stack, but this is out of scope of this document.
> The GSA KEK policy MUST include the attribute
> GSA_INITIAL_MESSAGE_ID with a first Message ID the GM should
> expect to receive if it is non-zero.
>
> Is the "if it is non-zero" a condition on the "MUST" ? It reads a bit odd.
> Like
> as implementer if the KEK policy has no GSA_INITIAL_MESSAGE_ID is the policy
> INVALID_SYNTAX or not ? Maybe:
>
> If the first Message ID the GM should expect to receive is non-zero,
> the GSA KEK policy includes the GSA_INITIAL_MESSAGE_ID with the
> expected non-zero value.
Makes sense. Also fixed text in other places concerned with this attribute.
> I don't understand what this means:
>
> In the latter case outer source and destination addresses are
> taken from the inner IP packet.
>
> Is that the only thing taken from the inner packet? Or if everything is
> taken from the inner packet what is "address preserving" about this version
> of tunnel mode?
This mode is defined in RFC5374. From my understanding of this mode, it is
important
for multicast routing that IP addresses in the tunnel IP be the same as in
the inner IP. The other content can differ (thus you may conceal some things
like FlowID, DSCP etc.)
> The (encrypted) retransmitted messages MUST be bitwise identical
> and should be sent within a short time interval (a few seconds)
>
> So is there is much point to do this then? If there is a flaky connection,
> it is often going to be a few seconds, so this quick retransmit is not going
> to be very helpful.
Little can be done here. This is some simple measure to deal with a single
packet loss.
More complex measure is the use of GSA_NEXT_SPI attribute, but it has
its own limitations.
> The group member then downloads the new ....
>
> I don't like the term "download" here? Isn't it just processed from the same
Good catch. Changed
s/downloads/installs
> packet? It is not a separate 'download' action. Similarly, What is called
> Key Download Payload here, I have seen called Key Package (Payload) elsewhere,
> eg MLS.
This is inherited from GDOI (RFC6407).
Unless you strongly dislike it, I'd rather to keep this name as a sign of
continuity :-)
Anyway, SPI is also a weird acronym, SAID would be better, but we live with it
:-)
> If it is a sender and does not hold a current Sender-ID value
>
> I believe that just means it is not a sender and it wants to become a sender?
No, it is a sender, but all the Data-Security SAs it sent data over did not
have counter mode ciphers,
thus it doesn't have a Sender-ID. At some point the GCKS installs additional
Data-Security SA
with counter mode cipher and the sender finds itself in a situation that it
cannot use it as a sender,
because it doesn't have Sender-iD. It should re-registered and ask for one.
> NITS
>
> This exchange follows the IKE_SA_INIT exchange
>
> I read follow as "follows the design" not "follows in time". Perhaps:
>
> This exchange happens after the IKE_SA_INIT exchange
OK.
> The other one is -> The second new exchange type is
OK.
> an specific IKE SA -> a specific IKE SA
Fixed.
> an multicast mode -> a multicast mode
Ditto.
> I would remove:
>
> , so it is assumed that readers have an understanding of this protocol
Changed to:
This document
defines an extension to the IKEv2 protocol [RFC7296] and skips many
its details. The notation and conventions from [RFC7296] are used
for describing G-IKEv2 payloads and exchanges.
> and:
>
> It is assumed that readers are familiar with the IKEv2 protocol, so
> this document skips many details that are described in [RFC7296].
Removed.
Many thanks for very thorough review.
The changes can be reviewed here:
https://github.com/smyslov/G-IKEv2/pull/29
Regards,
Valery.
_______________________________________________
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org
