Re: [IPsec] WG adoptation call for draft-smyslov-ipsecme-ikev2-aux-02

["Tobias Guggemos" <[e-mail]>]

Hey all,
we have implemented the draft and found a few issues.
Overall, the separation of IKE_INTERMEDIATE and the
draft-tjhai-ipsecme-hybrid-qske-ikev2-03 is not clear in some points. 

I personally like the idea of having a document on how to add a "pre-auth"
exchange to IKEv2, however we’ve found that the two documents depend quite
strongly on each other, which we found a bit of an implementation issue:

1. The draft does not say anything about payloads to be carried in the
IKE_INTERMEDIATE message (except SK payload), which means it could either
transfer "any payload" or "no payload". 
>From a security perspective, I'd assume "no payload", which means the draft
specifies how to send an empty SK payload between IKE_INIT and IKE_AUTH,
where "empty" means encrypted padding.
So basically, we have a (standard-track RFC) document describing a message
which cannot (I'd almost say MUST NOT) be implemented without the
requirement to implement an additional document describing the payload. 

2. On the other hand, IKE_INTERMEDIATE describes how to use previously
exchanged keys in order to secure (encrypt) the IKE_INTERMEDIATE traffic. 
If IKE_INTERMEDIATE is there to describe the messages and not the key
exchange, I think the document should only say that the current key in the
IKE SA should be used.

I'm not 100% sure if especially point 1 is an actual issue for an IETF
document and if so how to solve it.
One idea would be to define a (maybe informational/experimental) document
like "how to add an additional pre-auth exchange in IKEv2", which can then
be used by e.g. draft-tjhai-ipsecme-hybrid-qske-ikev2-03 to define the
actual exchange.
Another idea would be to define a list of allowed payloads (e.g. by IANA
registry).

If the WG thinks that this is not an issue or can be solved after adoption,
we support adoption and we were about to show and discuss some details on
that (and other PQKE related stuff) in a presentation in Prague.
We just wanted to raise awareness and get a discussion on this (potential)
issue before the adoption call ends.

Regards
Tobias

> -----Ursprüngliche Nachricht-----
> Von: IPsec <[e-mail]> Im Auftrag von Panos Kampanakis
> (pkampana)
> Gesendet: Donnerstag, 14. März 2019 20:07
> An: 'Tero Kivinen' <[e-mail]>; [e-mail]
> Betreff: Re: [IPsec] WG adoptation call for
draft-smyslov-ipsecme-ikev2-aux-
> 02
> 
> +1 on adopting this draft.
> 
> -----Original Message-----
> From: IPsec <[e-mail]> On Behalf Of Valery Smyslov
> Sent: Thursday, March 14, 2019 4:38 AM
> To: 'Tero Kivinen' <[e-mail]>; [e-mail]
> Subject: Re: [IPsec] WG adoptation call for
draft-smyslov-ipsecme-ikev2-aux-
> 02
> 
> Hi,
> 
> as author of the document I (obviously) support its adoption.
> It's a building block for QSKE solution (at least how the WG sees it now)
so I
> think we should adopt it.
> 
> Regards,
> Valery.
> 
> > This document has been stable for some time, and I think it is ready
> > to go forward. Because of that I will start one week long WG
> > adoptation call for this draft which will expire end of next week
> > (2019-03-22).
> >
> > If you have any reasons why this should not be adopted as WG document,
> > send email to the list as soon as possible.
> > --
> > [e-mail]
> >
> > _______________________________________________
> > IPsec mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/ipsec
> 
> _______________________________________________
> IPsec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ipsec
> 
> _______________________________________________
> IPsec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ipsec