Paul Hoffman writes:
> > Updates can update very specific text in a draft. Since this just
> > applies in this special case, the updates text needs to be clearly
> > worded to reflect that or you copy in all the text that applies
> > from the other draft.
I do not think the ikev2-null-auth updates the RFC4301. I does extend
it, but it does not really change anything that is already there.
In the similar way the RFC4739 (multiple authenticaiton exchanges in
IKEv2) adds multiple authentication exchanges in IKEv2, and while
implementing that rfc, you need to modify your code that handles the
configuration data and processing rules for the authentication data,
i.e. exactly this text we are talking in the RFC4301.
The RFC5998 (EAP only authentication in IKEv2) does the same thing,
i.e. it now allows the IKEv2 to be authenticated using only EAP. This
of course means that the PAD and SPD processing in the RFC4301 needs
to be extended in such way that you can configure that feature for
certain end points.
Neither one of those updates RFC4301, but both of them will extended
the processing rules mentioned in the RFC4301. As those changes in the
RFC4301 are obvious, neither one of them actually spells them out at
all.
The IKEv2-null-auth draft does the same thing, i.e. it just extends
the processing rules of the RFC4301. Implementation which do not
support that draft and does the RFC4301 processing does not need to be
changed at all.
I.e. my understanding is that when you change something that also
causes changes that old implementations need to consider, even when
they do not add that new feature, then you mark document as Updates
RFC XXXX.
For example the RFC 7383 (IKEv2 fragmentation) does NOT update IKEv2,
because it does not require old implementations ont supporting the
fragmentation to be changed at all. The old implementations will be
able to interoperate with implementations doing fragmentation without
any problem.
RFC 6989 (Additional Diffie-Hellman tests for IKEv2) do update IKEv2
(RFC5996) as they add tests that needs to be taken care of also for
old implementations implementing RFC5996. I.e. everybody
implementation RFC5996 should also read the RFC6989.
The reason IKEv2-null-auth mentions RFC4301 at all (while those two
other authentication related drafts do not) is that when implementor
adds support for null auth they need to make sure that they do those
changes properly, and there are some security issues that implementor
might otherwise miss if they are not pointed out.
Anyways old implementations implementing RFC4301 does not need to read
or care about the IKEv2-null-auth at all, unless they plan to
implement that draft. If we mark IKEv2-null-auth as updating RFC4301
that would in my understanding mean that old implementations
supporting RFC4301 would need to go and verify that they do correct
things mentioned in the IKEv2-null-auth, as it supposedly changed
something that is important for them. In the end there is nothing that
implementors of RFC4301 need to do.
> Sounds fine. Who do you want to make that decision?
I would like to keep the "Updates" marking to really mean that "this
RFC has something that everybody using this RFC should read, and
make sure their implementations are updated to what is said in this
RFC".
Something that just "Extends" some RFC should not be marked as
"Updates", as old implementations do not need to care about RFCs that
add new features to old protocol, as long as the original RFC already
has enough text that will make sure that new features can be added
without breaking interoperability.
RFC2223 says:
Updates
To be used as a reference from a new item that cannot be used
alone (i.e., one that supplements a previous document), to refer
to the previous document. The newer publication is a part that
will supplement or be added on to the existing document; e.g., an
addendum, or separate, extra information that is to be added to
the original document.
Which takes very document specific way of interpreting the Updates,
not protocol specific way, and I think lately we have used it more in
the protocol specific way, i.e. you cannot implement any of the IKEv2
extensions without reading the actual IKEv2 RFC (which is why IKEv2 is
normative reference in there).
We could of course remove the text about RFC4301 section 4.4.3.4 in
the null-auth and just explain things without using the RFC 4301
references, but would that be better or not, I do not know.
Something like:
----------------------------------------------------------------------
2.4. Interaction with Peer Authorization Database (PAD)
Section 4.4.3 of [RFC4301] defines the Peer Authorization Database
(PAD), which provides the link between Security Policy Database (SPD)
and the IKEv2. The PAD contains an ordered list of records, with
peers' identities along with corresponding authentication data and
Child SA authorization data. When the IKE SA is being established
the PAD is consulted to determine how the peer should be
authenticated and what Child SAs it is authorized to create.
When using NULL Authentication, the peer identity is not
authenticated and cannot be trusted. If ID_NULL is used with NULL
Authentication, there is no ID at all.
The NULL authentication does not have any authentication data, and
the as ID_NULL does not have any content, the policy rules for
matching it consists only of whether this type is used, i.e. no
actual ID matching is done, as ID_NULL contains no identity data.
When using the NULL authentication method the implementation MUST
make sure that it does not mix authenticated and not-authenticated
SPD rules, i.e. it needs to keep them separately, for example by
adding flag in SPD to tell whether NULL authentication can be used
or not for the entry. I.e. each SPD entry needs to be augmented to
have a flag specifying whether it can be used with NULL
authentication or not, and only those rules that explictly have
that flag turned on can be used with unauthenticated connections.
--
[email protected]
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
