Skip to content

elaborate SK_sub is directional. #7

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
antonyantony wants to merge 1 commit into from
Closed

elaborate SK_sub is directional. #7

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
37 changes: 20 additions & 17 deletions eesp-ikev2.org
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -253,15 +253,14 @@ alternative to large numbers of bidirectional Child SAs with the
same traffic selectors [[RFC7296]], [[RFC9611]].

Each Sub SA is identified by a Sub SA ID, which MUST be carried in
each EESP packet in the Session ID field—consistent with the negotiation of the EESP Child SA. This
Sub SA ID is used to derive a unique key, yielding the following
benefits:
each EESP packet in the Session ID field—consistent with the
negotiation of the EESP Child SA. This Sub SA ID is used to derive
a unique key, yielding the following benefits:
Comment on lines +257 to +258
Copy link
Collaborator

@tobiasbrunner tobiasbrunner Feb 12, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, not sure if these benefits result from that unique key. Some are just benefits of having Sub SAs.


- Unidirectional Operation: In contrast to the per-resource
SAs of [[RFC9611]], which are bidirectional, Sub SAs MAY be
defined strictly in one direction when reverse traffic is
absent. CREATE_CHILD_SA does not otherwise support
unidirectional SAs.
SAs of [[RFC9611]], which are alwaya a pair of unidirectional SAs,
Sub SAs MAY be defined strictly in one direction when reverse traffic is
Comment on lines +261 to +262
Copy link
Collaborator

@tobiasbrunner tobiasbrunner Feb 12, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, this seems a bit confusing as well. How can they be "defined" in strictly one direction? Do you mean that there could be more Sub SAs in one direction than the other? (One peer just wanting to accept one sub SA with Session ID 0 and the other allowing more.)

Copy link
Collaborator

@smyslov smyslov Feb 13, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps there is some misunderstanding of what was agreed upon at the last conference call. My understanding is that each side can create as many Sub SAs (acting as sender) as the other side indicated it is ready to accept (acting as a receiver). There is no requirement that these numbers are equal. During Child SA establishment each side would send a notify, indicating how many Sud SAs it can tolerate as a receiver. There is no negotiation, the values can differ - it is OK that for example when the initiator can handle up to 5 incoming Sub SAs and the responder can handle 20 of them. This is very similar (but simplified) to the concept of STREAMs in QUIC (RFC 9000). In QUIC new streams are created by senders at any time, but the total number of streams they can create is limited by the MAX_STREAMS message, that was sent earlier by the peer. In case of EESP this concept is simplified (no individual deletion of Sub SAs, no dynamic update of the maximum number of Sub SAs, etc.), but the idea is the same.
Are we here on the same page or not?

Copy link
Collaborator Author

@antonyantony antonyantony Feb 13, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes. Valery. I think this what we are trying write down.
Though I have one further question. In the call, did we clarify the number proposed is in one direction or combined ? I think for one direction. I didn't add that to the notifier.

Copy link
Collaborator

@smyslov smyslov Feb 13, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Each side informs the other side about what is the maximum number of incoming Sub SAs it is ready to handle. This doesn't include Sub SAs this party would create as a sender (outgoing). Thus, each proposal (in fact, this is not "proposal", this is an "announcement", since there is no negotiation, just an information) counts only incomimg Sub SAs, not both directions.

absent.

- Zero Additional Setup Time: Sub SAs require no extra IKE
message exchanges, unlike requesting more Child SAs or relying
Expand Down Expand Up @@ -356,13 +355,17 @@ created by either peer and the key derivation for the in- and
outbound EESP SAs of the Child SA are done as described in section
2.17 of [[RFC7296]].


If an SSKDF is selected as part of the proposal, instead of directly
taking keys for the Sub SAs from KEYMAT, as described in section 2.17
of [[RFC7296]], only one "root" key is taken for each EESP SA of the
Child SA. Their length is determined by the key size of the
negotiated SSKDF. The root key for the EESP SA carrying data from
the initiator to the responder is taken before that for the SA going
from the responder to the initiator.
of [[RFC7296]], a "root" key or a set of "root" keys per direction
is derived for each EESP SA per direction of the Child SA. The number
of keys depends on the cryptographic suite: AEAD transforms derive a
single key per direction, while non-AEAD suites may derive separate
keys for encryption and authentication. The input length of these
keys, SK_sub, is determined by the key size of the negotiated SSKDF.
The root key(s) for the initiator-to-responder direction are derivedi
before those for the responder-to-initiator direction.

Copy link
Collaborator

@tobiasbrunner tobiasbrunner Feb 12, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's not correct. We only get keys used for SSKDF here, not the individual keys for encryption/integrity algorithms. So this does not depend on the algorithms at all (except for the SSKDF key size). That difference is only relevant when applying SSKDF later to derive KEYMAT_sub using the key we got here.

Using the EESP SA's root key, SK_sub, the KEYMAT for each Sub SA is
derived as follows:
Expand All @@ -377,11 +380,11 @@ If multiple keys are required for a Sub SA, the encryption key MUST
be taken from the first bits of KEYMAT_sub, the integrity key MUST be
taken from the remaining bits.

Keys for Sub SAs may be derived immediately or on demand when the
first packet is processed. Memory constrained implementations may
even decide to derive the Sub SA keys on the fly for each received
packet as only SK_sub has to be stored to derive the keys of all
Sub SAs.
Keys for Sub SAs may be derived immediately after IKE negoation of
the Child SA or on demand when the first packet is processed. Memory
Comment on lines +383 to +384
Copy link
Collaborator

@tobiasbrunner tobiasbrunner Feb 12, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe use during IKE negotiation because "after" is a bit confusing.

constrained implementations may even decide to derive the
Sub SA keys on the fly for each packet as only SK_sub has
to be stored to derive the keys of all Sub SAs.

Because individual Sub SAs can't be rekeyed, the complete EESP Child
SA MUST be rekeyed when either a cryptographic limit or a time-based
Expand Down