On Thu, 6 Feb 2025, Valery Smyslov wrote:
[ Removed everything where there is agreement ]
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.
Then maybe this should be started somewhere clearly.
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).
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.
You are right. I missed Appendix A. You indeed do something similar to
MLS.
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.
Since I am now going by the presumption regular IKE SAs and group IKE
SAs cant mix, I don't understand the use of "other exchanges defined in
this document". Because it kinda applies to "all other exchanges". Maybe
just say something like "The GSA_AUTH exchange MUST follow the IKE_SA_INIT
(or IKE_INTERMEDIARY) exchanges."
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 draft here (Section 2.3.1) is talking about errors that
prevent the GM to join the group:
Ok that was not clear to me. The figure says "GSA_AUTH Error Response"
and an AUTH error is also an error.
Perhaps add a sentence (and fix AUTH to be [AUTH]* with some text like:
* If the initiator's authentication fails, the AUTH payload MUST be
omited.
I think the original IKEv2 did this mainly to prevent DDoS attacks by
sending garbage and forcing the responder the compute an AUTH signature.
The GMs are expected to not delete IKE SA on their own.
Then that should be written down. But also how does that interact with
things like liveness ?
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.
Maybe add this text as well :)
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.
And this :)
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.
I understand. I was just whining :) :)
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.
I am just unsure why it can't sign the "plaintext" and then let it all
get encrypted and sent. Why does it need this special handling of double
signing similar data - once plain and once encrypted. I understand the
final packets entire encryption can be decrypted by all group members,
and the outer encryption cannot be used as authentication.
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.
Perhaps a reminder sentence there could be added (I know it states this
elsewhere in the document)
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 :-)
Yes, but now the GCKS will have to do like 3000 DH's when all the GMs
come back at once. Maybe say if this causes load/strain, the GCKS can
return TEMPORARY_FAILURE ?
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.
Maybe "values other than NONE" as you could have multiple INTEG transforms?
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
Ok, this is all fine with me.
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.
That's fine, thanks.
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.
Ah, thanks for that pointer. Now this all makes sense.
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 :-)
That's fine.
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.
Thanks. It might be worth adding this text to the draft to clarify.
Paul
_______________________________________________
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org
