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

Tobias races good points to address, but that can be discussed after adoption too.

I’m in favour of adoption and I would like all ambiguity to be resolved so that this document can be implemented independently from any other future documents.

Paul

Sent from mobile device

> On Mar 18, 2019, at 18:02, Tobias Guggemos <guggemos@nm.ifi.lmu.de> wrote:
> 
> 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 <ipsec-bounces@ietf.org> Im Auftrag von Panos Kampanakis
>> (pkampana)
>> Gesendet: Donnerstag, 14. März 2019 20:07
>> An: 'Tero Kivinen' <kivinen@iki.fi>; ipsec@ietf.org
>> Betreff: Re: [IPsec] WG adoptation call for
> draft-smyslov-ipsecme-ikev2-aux-
>> 02
>> 
>> +1 on adopting this draft.
>> 
>> -----Original Message-----
>> From: IPsec <ipsec-bounces@ietf.org> On Behalf Of Valery Smyslov
>> Sent: Thursday, March 14, 2019 4:38 AM
>> To: 'Tero Kivinen' <kivinen@iki.fi>; ipsec@ietf.org
>> 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.
>>> --
>>> kivinen@iki.fi
>>> 
>>> _______________________________________________
>>> IPsec mailing list
>>> IPsec@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ipsec
>> 
>> _______________________________________________
>> IPsec mailing list
>> IPsec@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipsec
>> 
>> _______________________________________________
>> IPsec mailing list
>> IPsec@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipsec
> 
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec