Subject: Re: [IPsec] draft-ietf-ipsecme-ikev2-null-auth-05.txt

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 1 Apr 2015 15:11:13 -0400

Hi Paul,

On Mon, Mar 30, 2015 at 8:51 PM, Paul Hoffman <[email-masked]> wrote:

> On Mar 30, 2015, at 1:56 PM, Kathleen Moriarty <
> [email-masked]> wrote:
>
> > Thanks for making most of the suggested changes to the draft.  I see
> nothing happened in section 2.4 with the 'updates' text.  Since this
> requires changes to the referenced draft, it's easier to just state what is
> being updated in the previous RFC with this draft.  Could we work on that
> change and have it ready soon?  I'd rather do this before IETF last call or
> in IESG review as I think it pretty clearly should be done.
>
> My interpretation from the WG discussion was that there was consensus that
> this document doesn't need to be marked as "updates RFC 4301". I updated
> the shepherd report to indicate that the WG defers to the IESG on judgement
> about this.
>

In looking back at this, the email lists, and talking to a couple of fellow
ADs, I think it's important to tweak some text as it will get held up
otherwise.  This text was not present in RFC4322.

The last sentence of this paragraph is the mail issue:

     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 processing of PAD
   described in Section 4.4.3.4 of [RFC4301] must be updated.

The only change that would be required here is to reword that last sentence
and mark the draft appropriately so it "updates" 4301 for this case. New
text could be something like:

     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 processing of PAD
   described in Section 4.4.3.4 of [RFC4301] is updated for NULL Authentication.

Then you can add a few sentences specific to what is updated and where that
text goes in 4.4.3.4. This keeps the update very specific and we see this
in drafts pretty regularly when just a bit of text is needed.

The other sentence that is problematic in this section is:

To add support for ID_NULL, it needs to be included into the
   list of ID types, specified in Section 4.4.3.1 of [RFC4301].

As such, Section 4.4.3.1 of [RFC4301] is updated as follows:

Old:

New:

You could simply then add a sentence that provides the text to update
the list of ID types, showing where it is added in that section with
surrounding text in the old/new.  The way it is written now leaves you
wondering if that list will get updated at some point in the future.

One AD wasn't too fused and the other agreed (provided an alternative)

     Given the wording in 2.4, this draft most certainly needs to update
RFC 4301.  If it does not update 4301, it needs to subsume the necessary
text from 4301 to make this spec standalone.  From a quick read of 4301,
I think section 2.4 would be augmented with 3-4 blocks indicating what
text in 4301 is updated.

I'm fine with the alternative as well.

Does this draft update RFC4322 at all?  I do see that it wasn't
referenced, so maybe not, but figured I would check to be safe.

Thanks.

> > The next telechat is April 9th and this won't make it on it, so there is
> time to get this update ready without holding up the draft.
>
> Unless you want us to make more changes to the draft, you might as well
> put this into IETF Last Call now, even though it will miss the next
> telechat.
>
> --Paul Hoffman

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 1 Apr 2015 21:57:31 -0400

I went back to the email thread as I wanted to look at the consensus and
don't see it the way Paul does.
Here is the end of the thread:
http://www.ietf.org/mail-archive/web/ipsec/current/msg09668.html

It reads as confusion with the term updates and most being ok with going in
either direction, Paul against and Yaron more in favor.

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'm at a day long conference tomorrow and will be slow to respond.

Thanks.

On Wed, Apr 1, 2015 at 3:11 PM, Kathleen Moriarty <
[email-masked]> wrote:

>> My interpretation from the WG discussion was that there was consensus
>> that this document doesn't need to be marked as "updates RFC 4301". I
>> updated the shepherd report to indicate that the WG defers to the IESG on
>> judgement about this.
>>
>
> In looking back at this, the email lists, and talking to a couple of
> fellow ADs, I think it's important to tweak some text as it will get held
> up otherwise.  This text was not present in RFC4322.
>
> The only change that would be required here is to reword that last
> sentence and mark the draft appropriately so it "updates" 4301 for this
> case. New text could be something like:
>
>
> Then you can add a few sentences specific to what is updated and where
> that text goes in 4.4.3.4. This keeps the update very specific and we see
> this in drafts pretty regularly when just a bit of text is needed.
>
> You could simply then add a sentence that provides the text to update the list of ID types, showing where it is added in that section with surrounding text in the old/new.  The way it is written now leaves you wondering if that list will get updated at some point in the future.
>
>
> Does this draft update RFC4322 at all?  I do see that it wasn't referenced, so maybe not, but figured I would check to be safe.
>
>
> Thanks.
>
>
>
>> > The next telechat is April 9th and this won't make it on it, so there
>> is time to get this update ready without holding up the draft.
>>

-- 

Best regards,
Kathleen

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 1 Apr 2015 19:10:10 -0700

On Apr 1, 2015, at 6:57 PM, Kathleen Moriarty <[email-masked]> wrote:
> 
> I went back to the email thread as I wanted to look at the consensus and don't see it the way Paul does.  
> It reads as confusion with the term updates and most being ok with going in either direction, Paul against and Yaron more in favor.

Yes, exactly. So, it sounds like you see the consensus (and confusion) the way I do.

> 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.

Sounds fine. Who do you want to make that decision?

--Paul Hoffman

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 2 Apr 2015 13:06:57 +0300

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-masked]

---

From: Stephen Kent <[email-masked]>
Date: Thu, 02 Apr 2015 10:21:00 -0400

As the primary author of 4301, and the creator of the PAD, I believe 
this work
does update that section of 4301. I agree with Kathleen that this doc 
needs to
say precisely what parts of 4301 are being updated, perhaps using a 
before/after
approach.

Steve

> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>

---

From: Paul Wouters <[email-masked]>
Date: Sat, 4 Apr 2015 21:00:07 -0400 (EDT)

On Thu, 2 Apr 2015, Stephen Kent wrote:

Hi Steve,

> As the primary author of 4301, and the creator of the PAD, I believe this 
> work
> does update that section of 4301. I agree with Kathleen that this doc needs 
> to

Section 2.4 already describes our the changes to the PAD processing:

https://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-null-auth-05#section-2.4

The original PAD text of 4301 is here:

https://tools.ietf.org/html/rfc4301#section-4.4.3.1

If our text is not suitable, could you perhaps explain what is missing,
or even better, suggest text that would address your concerns with the
current section?

The text currently suggests using a new BOOL to determine if a PAD entry
can use AUTH_NULL/ID_NULL. Would you prefer it rewritten as just another
type of ID that is only added to the PAD authentication types as specified
in 4301?

If our current text is adequate, we can just add the "updated 4301" to
the document.

Thanks,

Paul

---

From: Kathleen Moriarty <[email-masked]>
Date: Sat, 4 Apr 2015 21:44:21 -0400

Sorry for my delay in response, I was at a conference in Thursday and am
still catching up.

> If our current text is adequate, we can just add the "updated 4301" to

The problem is the current wording.  I see Tero's point that you are really
extending 4301, but you say you are updating it in the text with MUST
statements.  If you change that language, and include what you need from
4301, then you are fine with this as stand alone.  Another way to handle it
is to say that you are updating 4301, in a way that is specific to NULL
Auth and this extension/update is only needed for AUTH_NULL/ID_NULL.
That's still an "updates'.

Thanks,
Kathleen

-- 

Best regards,
Kathleen