Hi Paul,
> [ Removed everything where there is agreement ]
I also removed topics that require no further discussion.
> >> 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.
I've added the text at the end of Section 2.3:
The established secure channel between the GM and the GCKS is in fact
IKE SA (as defined in [RFC7296]) and is referred to as such
throughout this document. However, it is NOT RECOMMENDED to use this
IKE SA for the purpose of creating unicast Child SAs between the GM
and the GCKS, since authentication requirements for group admission
and for unicast communications may differ. In addition, the
lifecycle of this IKE SA is determined by the GCKS and this SA can be
deleted at any time.
> > 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."
Perhaps we can remove this sentence at all. From the text below
it is clear that GSA_REGISTRATION and GSA_INBAND_REKEY
can only be used after the IKE SA is established, as well as
all other exchanges. To make it clear that the GSA_AUTH exchange
completes establishing IKE SA I changed the first para of Section 2.3:
Initial registration is combined with establishing a secure connection
between the entity seeking for registration and the GCKS. This
process consists of a minimum of two exchanges, IKE_SA_INIT and
GSA_AUTH...
Is it OK?
> >> 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 this would confuse readers: in case of failed authentication IDr and
CERT are both omitted.
Thus we have to show all payloads as optional and this is not helpful for
readers.
Instead, I suggest to point to Section 2.21.2 of RFC7296,
which defines how to handle errors in IKE_AUTH (including failed
authentication),
and clarify that this figure is for group related errors.
Is it OK?
> I think the original IKEv2 did this mainly to prevent DDoS attacks by
sending
> garbage and forcing the responder the compute an AUTH signature.
Perhaps. Another reason - there is no point to compute AUTH payload in this
case,
since if the initiator cannot authenticate itself to the responder, then
it will most probably not be able to verify responder's AUTH payload.
> > 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 ?
In the last para of Section 2.3.3. there is a text:
Once a GM has received GIKE_UPDATE policy during a registration, the
IKE SA MAY be closed. By convention, the GCKS closes the IKE SA.
We can make it stronger:
Once a GM has received GIKE_UPDATE policy during a registration, the
IKE SA MAY be closed. By convention, the GCKS closes the IKE SA, the
GM SHOULD NOT close it.
> > 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 :)
I think this is already clear from the last paras of Sections 2.3.3.
Once a GM has received GIKE_UPDATE policy during a registration, the
IKE SA MAY be closed. By convention, the GCKS closes the IKE SA, the
GM SHOULD NOT close it. The GKCS MAY choose to keep the IKE SA open
for inband rekey, especially for small groups. If inband rekey is
used, then the initial IKE SA can be rekeyed with the standard IKEv2
mechanism described in Section 1.3.2 of IKEv2 [RFC7296]. If for some
reason the IKE SA is closed and no GIKE_UPDATE policy is received
during the registration process, the GM MUST consider itself excluded
from the group. To continue participating in the group, the GM needs
to re-register.
and 2.3.4:
Depending on its policy, the GCKS may have no further need for the
IKE SA (e.g., it does not plan to initiate an GSA_INBAND_REKEY
exchange). If the GM does not initiate another registration exchange
or Notify (e.g., NO_PROPOSAL_CHOSEN), and the GCKS is not intended to
use the SA, then after a short period of time the GCKS SHOULD close
the IKE SA to save resources.
> > 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 :)
Isn't this clear? :-) How this can look like? In particular - what to put in
GSA_AUTH?
If the GCKS ever started a connection, then it would have become a GM :-)
Unlike IKEv2, the G-IKEv2 participants have distinct roles and
the direction of SA establishment depends on these roles (as in TLS).
The GCKS is free to initiate rekey of IKE SA, but this is already stated.
If inband rekey is
used, then the initial IKE SA can be rekeyed with the standard IKEv2
mechanism described in Section 1.3.2 of IKEv2 [RFC7296].
I can add a clarification "by any side":
If inband rekey is
used, then the initial IKE SA can be rekeyed by any side with the
standard IKEv2 mechanism described in Section 1.3.2 of IKEv2
[RFC7296].
> >> 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.
Only plaintext is signed, no double signing.
But the plaintext is split into two parts (up to IV and past IV up to
padding) and the signature is applied
to the concatenation of them. This is to exclude the IV (and possible
padding) from the signed data.
This allows the IV to be generated and inserted on the later stage,
when the packet is encrypted. This also allows to fragment message
using IKE fragmentation and send it as several parts (with different IVs).
> I understand the final packets entire encryption can be
> decrypted by all group members, and the outer encryption cannot be used as
> authentication.
Correct.
> >> 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)
I add a clarification in the para following Figure 9:
HDR is defined in Section 4.1. While GSA_REKEY re-uses IKEv2 header,
the "IKE SA Initiator's SPI" and the "IKE SA Responder's SPI" fields
are treated as a single field with a length of 16 octets containing
the SPI of Rekey SA. The value for this field is provided by the
GCKS in the GSA payload (see Section 4.4.2). ...
Also fixed some inconsistencies of naming "IKE SA Initiator's SPI" and "IKE
SA Responder's SPI"
throughout 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 ?
We can add advice to the last para of Section 2.4.3. for implementers to do
some fuzzing:
It is RECOMMENDED that a GM waits some
randomly chosen time before initiating a registration request in this
situation to avoid overloading the GCKS. This document doesn't
specify the maximum delay, which is implementation-dependent, but it
is believed, that the order of seconds suits most situations.
> > 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?
No, this text is about the GSA payload content, and this payload is sent by
the GCKS to the GM
to specify group policy. Thus, only a single instance of each transform type
is allowed there.
If the GM supports different algorithms, then it would indicate this by
placing
multiple instances of the same transform types in the SAg payload.
To make this clear I updated the text just above Figure 16:
OLD:
Valid Transform Types depend on the SA protocol and are summarized in
the table below.
NEW:
Valid transform types depend on the SA protocol and are summarized in
the table below. Exactly one instance of each mandatory transform
type and at most one instance of each optional transform type MUST be
present in the GSA policy substructure.
> >> 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.
I added a clarification:
...If it is a
sender and does not hold a current Sender-ID value (for example, when
no counter-mode is employed for other Data-Security SAs), it MUST NOT
install the Data-Security SAs. It MUST initiate a re-registration to
the GCKS in order to obtain an Sender-ID value (along with the
current group policy).
Thank you for these comments. The updated PR is here:
https://github.com/smyslov/G-IKEv2/pull/29
Regards,
Valery.
> Paul
_______________________________________________
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org
