Valery Smyslov writes:
> > I think this document should update 7296 due to adding non-encrypted
> > payloads to IKE_AUTH - even though the core IKEv2 RFC does not say that
> > is not allowed. Someone implementing 7296 should be aware of it to allow
> > it in their implementation.
>
> Hmmm... Not sure it is needed. As you said RFC 7296 doesn't
> explicitely prohibit that (so we don't violate its requirements) and
> there is a clear negotiation mechanism with puzzles, so that old
> implementations won't be affected.
>
> I think we should be consitent in our policy whether to update core RFC or
> not.
> For example, RFC 5723 (Resumption) defines new exchange IKE_SA_RESUME
> that can be used in conjunction with IKE_AUTH instead of IKE_SA_INIT.
> RFC 7296 tells only about IKE_SA_INIT + IKE_AUTH, however
> RFC 5723 doesn't update IKEv2 RFC. Is our situation much
> different? I don't think so.
>
> To be clear - I'm not against updating RFC 7296, I just think it is
> not needed.
I think the rules are
All documents which do change IKEv2 core behavior are marked as
updates 4306/5996/7296. Currently those are:
5282 Using Authenticated Encryption Algorithms with the Encrypted Payload
of the Internet Key Exchange version 2 (IKEv2) Protocol.
(PROPOSED STANDARD)
Changes the format of the existing IKEv2 encrypted payload
format.
5998 An Extension for EAP-Only Authentication in IKEv2. (PROPOSED
STANDARD)
Changes the core component of IKEv2, i.e. how the authentication
is done.
6989 Additional Diffie-Hellman Tests for the Internet Key Exchange
Protocol Version 2 (IKEv2) (PROPOSED STANDARD)
Changes the mandated behaviro of 5996, by adding new tests.
7427 Signature Authentication in the Internet Key Exchange Version 2
(IKEv2) (PROPOSED STANDARD)
Adds new authentication method, but there is negotiaton for it,
but as this affects how the authentication (core IKEv2 component)
works, this was considered to be something that updates 7296.
7670 Generic Raw Public-Key Support for IKEv2 (PROPOSED STANDARD)
Adds new certificate encoding value, and there is no negotiation
for it, except that implementations can ignore cert payloads they
do not understand.
Note, that RFC4718 IKEv2 Clarifications and Implementation Guidelines
did not update 4306 as it did not change anything, it just clarified
things.
Childless initiation, high availability, secure password methods, EAP
re-authnetication, fragmentation, null authentication,
chacha20/poly1305, cloning etc did not update IKEv2, as in most cases
the extensions are something that do not change the existing behavior,
but adds new things, and on the other hand some of those are
experimental, and it was not clear whether they are going to be used
widely or not.
If there is negotiation of this feature before the IKEv2 behavior
changes I think it does not need to update 7296. If this changes
normal behavior of the IKEv2 (timers, mandatory to implement
protection mechanisms) then it needs to update 7296.
I have not yet read any of the latests drafts, so I cannot say if this
is true...
--
[email protected]
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
