Re: [IPsec] New Version Notification for draft-tjhai-ipsecme-hybrid-qske-ikev2-03.txt

["Valery Smyslov" <[e-mail]>]

Hi Leonie,

> Hi,
> 
> The draft specifies how to use additional key exchanges for Child SAs. It states that if several key exchanges
> are negotiated in CREATE_CHILD_SA, key shares are transmitted in a series of INFORMATIONAL exchanges.
> So I was wondering if keys are updated after each INFORMATIONAL exchange, similar as its done with the
> INTERMEDIATE exchange?

It's a good question. We haven't discuss this issue yet among authors, but I think there is no reason 
(and I believe no reliable way) to update the keys used to protect the current IKE SA.
Instead, we can just use subsequent Key Exchanges as additional inputs into prf as follows:

For IKE SA rekey:
SKEYSEED = prf(SK_d_current, KE1  | Ni1 | Nr1 | KE2  | Ni2 | Nr2 ... KEn  | Nin | Nrn)

For new Child SA or its rekey:
KEYMAT = prf+(SK_d_current, KE1  | Ni1 | Nr1 | KE2  | Ni2 | Nr2 ... KEn  | Nin | Nrn)

where KE1, Ni|r1 - from CREATE_CHILD_SA, other KE and Ni|r - fron subsequent INFORMATIONAL.

But I'd rather let cryptographers comment on this and probably suggest better ways to do it.

And in any case this should definitely be clarified in the draft, as well as some other things 
(e.g. how collisions would be handled in this case etc.)

> Besides, has anybody experiences with fragmenting INFORMATIONAL exchange? I’m not aware that
> INFORMATIONAL exchange has been used to transmit such large payloads before.

RFC 7383 explicitly says that if IKE fragmentation was negotiated, then any subsequent protected 
exchange may be sent in fragmented form. It's true that so far IKE fragmentation was 
primarily used in the IKE_AUTH exchange, however any compliant implementation must be able
to use it in any exchange containing Encrypted payload.

Regards,
Valery.

> Regards,
> Leonie
> 
> > -----Ursprüngliche Nachricht-----
> > Von: IPsec [mailto:[e-mail]] Im Auftrag von Valery Smyslov
> > Gesendet: Mittwoch, 16. Januar 2019 08:16
> > An: IPsecME WG
> > Cc: [e-mail]
> > Betreff: Re: [IPsec] New Version Notification for draft-tjhai-ipsecme-hybrid-
> > qske-ikev2-03.txt
> >
> > Hi,
> >
> > a new version (-03) of the QSKE draft is published. It contains quite a lot of
> > changes from the -02 version:
> >
> > 1. Negotiation method is changed to standard (via new Transform Types in
> > SA payload)
> > 2. Using multiple key exchanges in the CREATE_CHILD_SA exchange is
> > addressed
> > 3. "IKE_AUX" is changed to "INTERMEDIATE" (to align with the draft-smyslov-
> > ipsecme-ikev2-aux-02)
> > 4. IANA considerations section is added
> > 5. Temporary IDs for PQ KE methods (using VendorID) are removed
> >
> > Please, review the draft. Some issues have already been discussed and the
> > changes reflect the WG consensus,
> > some are new and the text reflects only the authors' current opinion.
> >
> > Regards,
> > Valery (for the authors)
> >
> > > A new version of I-D, draft-tjhai-ipsecme-hybrid-qske-ikev2-03.txt
> > > has been successfully submitted by C. Tjhai and posted to the
> > > IETF repository.
> > >
> > > Name:		draft-tjhai-ipsecme-hybrid-qske-ikev2
> > > Revision:	03
> > > Title:		Framework to Integrate Post-quantum Key Exchanges into
> > Internet Key Exchange Protocol
> > > Version 2 (IKEv2)
> > > Document date:	2019-01-14
> > > Group:		Individual Submission
> > > Pages:		19
> > > URL:            https://www.ietf.org/internet-drafts/draft-tjhai-ipsecme-
> > hybrid-qske-ikev2-03.txt
> > > Status:         https://datatracker.ietf.org/doc/draft-tjhai-ipsecme-hybrid-
> > qske-ikev2/
> > > Htmlized:       https://tools.ietf.org/html/draft-tjhai-ipsecme-hybrid-qske-
> > ikev2-03
> > > Htmlized:       https://datatracker.ietf.org/doc/html/draft-tjhai-ipsecme-
> > hybrid-qske-ikev2
> > > Diff:           https://www.ietf.org/rfcdiff?url2=draft-tjhai-ipsecme-hybrid-
> > qske-ikev2-03
> > >
> > > Abstract:
> > >    This document describes how to extend Internet Key Exchange Protocol
> > >    Version 2 (IKEv2) so that the shared secret exchanged between peers
> > >    has resistance against quantum computer attacks.  The basic idea is
> > >    to exchange one or more post-quantum key exchange payloads in
> > >    conjunction with the existing (Elliptic Curve) Diffie-Hellman
> > >    payload.
> > >
> > >
> > >
> > >
> > > Please note that it may take a couple of minutes from the time of
> > submission
> > > until the htmlized version and diff are available at tools.ietf.org.
> > >
> > > The IETF Secretariat
> >
> > _______________________________________________
> > IPsec mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/ipsec
> 
> _______________________________________________
> IPsec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ipsec