Subject: [IPsec] AD review of draft-ietf-ipsecme-ikev2-null-auth

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 16 Mar 2015 20:03:06 -0400

Hello,

Thank you for your work on draft-ietf-ipsecme-ikev2-null-auth, it's great
to see progress on OS in protocols.  I have a nit and a couple of
comments/questions before we progress the draft.

Comments & questions:

Security Considerations:

The following sentence may ned a little work:

   Implementations might have made
   assumptions that are no longer valid.

I assume this is referring to the assumption that one would only want
authenticated sessions to preventing man-in-the-middle attacks.  It
could be read as the assumptions being that we are fine with
main-in-the-middle attacks now, as opposed to we now understand the
need for additional use cases to support both authenticated and
unauthenticated sessions.

How about the following (assuming I'm making the right assumption
about your assumptions ;-) ):

   Implementations might have made
   assumed there were no scenarios where a connection without
authentication would be desired, which is no longer valid.

Section 3.1

 Shouldn't this new requirement only apply to unauthenticated
sessions?  Wouldn't requirements for existing authenticated sessions
remain in terms of audit capabilities and logging?  This should be
made clear to help implementers.

Nits:
Section 2.3, first sentence of last paragraph:

Implementations should weight the resource consumption of sending

s/weight/weigh/

Thanks.

-- 

Best regards,
Kathleen

---

From: Paul Wouters <[email-masked]>
Date: Mon, 16 Mar 2015 20:10:45 -0400 (EDT)

On Mon, 16 Mar 2015, Kathleen Moriarty wrote:

> I assume this is referring to the assumption that one would only want authenticated sessions to preventing man-in-th
> e-middle attacks.  It could be read as the assumptions being that we are fine with main-in-the-middle attacks now, a
> s opposed to we now understand the need for additional use cases to support both authenticated and unauthenticated s
> essions.
> How about the following (assuming I'm making the right assumption about your assumptions ;-) ):
>    assumed there were no scenarios where a connection without authentication would be desired, which is no longer va
> lid.

We actually meant the assumption that you "know who is connecting to
you" because they authenticate. And by authenticating, it means you
have a way to address abusive behaviour or the client - as in you
probably know where they live :)

With auth_null, these people are untracable strangers.

> Section 3.1
>  Shouldn't this new requirement only apply to unauthenticated sessions?  Wouldn't requirements for existing authenti
> cated sessions remain in terms of audit capabilities and logging?  This should be made clear to help implementers.

Would this work:

old:

 	An established IKE session [...]

new:

 	An established IKE session using AUTH_NULL [...]

> Implementations should weight the resource consumption of sending

Will fix, thanks!

Paul

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 16 Mar 2015 20:15:07 -0400

Thanks for the quick response!  Inline.

On Mon, Mar 16, 2015 at 8:10 PM, Paul Wouters <[email-masked]> wrote:

>>    assumptions that are no longer valid. I assume this is referring to
>> the assumption that one would only want authenticated sessions to
>> preventing man-in-th
>> e-middle attacks.  It could be read as the assumptions being that we are
>> fine with main-in-the-middle attacks now, a
>> s opposed to we now understand the need for additional use cases to
>> support both authenticated and unauthenticated s
>> essions.

Ok, can you update the text with the assumption you meant?  Thanks!

>
>
>  Section 3.1
>>  Shouldn't this new requirement only apply to unauthenticated sessions?
>> Wouldn't requirements for existing authenti
>> cated sessions remain in terms of audit capabilities and logging?  This
>> should be made clear to help implementers.
>>
>
> Would this work:
>
> old:
>

Yes, thanks.  That helps and is that what the WG had agreed upon or was it
not discussed?

>> Implementations should weight the resource consumption of sending

Thank you!

-- 

Best regards,
Kathleen

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 17 Mar 2015 15:26:06 +0200

Kathleen Moriarty writes:
>         sessions?  Wouldn't requirements for existing authenti
>         cated sessions remain in terms of audit capabilities and logging? 
>         This should be made clear to help implementers.
> 
>     Would this work:
>    
>     old:
>    

The IKE sessions using AUTH_NULL is subset of IKE sessions, and as
only that subset can have sessions which do not have verifiable
entity, the statement is still true if we add "using AUTH_NULL". On
the other hand the architectural change this draft does is that now
IKE sessions might not have verifiable authenticated entity associated
with it anymore, and that means the meaning of IKE sessions is
changed. 

The rest of the section is talking about assumptions for IKE sessions
in general, i.e. originally when you could not have unauthenticated
IKE sessions, your implementation might have assumed that certain
level of trust can be put on the information you receive from the
other end. Those assumptions might not be valid anymore when
unauthenticated IKE sessions are added.

Those assumptions needs to be verified for all IKE sessions, i.e. if
it matters whether the IKE session is unauthenticated or not, then
specific checks needs to be added that IKE session is properly
authenticated before trusting information.

So I think it would be better to keep the original version talking
about IKE sessions in general, and not limiting it only to AUTH_NULL
cases, as implementations need to verify all cases where it make
assumptions about IKE sessions and peers associated to it. 
-- 
[email-masked]

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 17 Mar 2015 15:19:55 -0400

Hi Tero,

Thanks for your response, just one question inline.

> with it anymore, and that means the meaning of IKE sessions is

Yes, I like the addition, but wanted to make sure the WG agreed that audit
features only change for NULL authentication and expectations of fully
authenticated sessions remain in tact.

> unauthenticated IKE sessions are added.

OK, is there a way to distinguish trust for authenticated vs.
unauthenticated sessions so trust assumptions would vary based on
connection type?  If this can be made distinct, it would serve the user
bases equally well for their intended scenarios.  If not, then we are
affecting trust levels for existing scenarios where this is implemented and
I don't think that's what we want to do.  I'd just like to make sure it's
clear.

> authenticated before trusting information.

OK, I think we are in agreement here and just want to make sure the draft
reflects this.

> assumptions about IKE sessions and peers associated to it.

I think that muddies the water for existing IKE sessions with
authentication and could affect their assumptions of trust levels.

Once we get this sorted, we can move the draft to IETF last call.  I just
want to make sure the WG agrees on this point before going forward
(whatever that agreement is - it's fine to tell me I am wrong and why).

Thanks,
Kathleen

-- 

Best regards,
Kathleen

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 18 Mar 2015 18:43:11 +0300

Hi Tero,

> assumptions about IKE sessions and peers associated to it.

How about the following variant:

     old:

     new:

     With NULL Authentication an established IKE session [...]

Just to emphasize that it is support for NULL Authentication
that could make some assumptions about IKE SAs uncertain.

Regards,
Valery.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 23 Mar 2015 15:01:27 -0500

The window is open for submitting new drafts. It would be great to have the -05 dealing with Kathleen's requests submitted this week, before the meeting Friday.

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Mon, 23 Mar 2015 16:22:05 -0400 (EDT)

On Mon, 23 Mar 2015, Paul Hoffman wrote:

> Subject: Re: [IPsec] AD review of draft-ietf-ipsecme-ikev2-null-auth
> 

I'll send the updated version to Valerie today, so it should be in for
you tomorrow if Valerie has some time to check it while we sleep.

Paul