Subject: [secdir] draft-ietf-ipsecme-ikev2-null-auth-06 SECDIR review

From: Donald Eastlake <[email-masked]>
Date: Tue, 26 May 2015 07:57:32 -0400

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG. These
comments should be treated like other last call comments.

This draft provides a null authentication method and a null identity for
use in IPsec, specifically the Internet Key Exchange Protocol version 2
(IKEv2).

Overall this is an excellent draft and useful in countering pervasive
surveillance in IKEv2.

The Security Considerations section is quite thorough. I did notice one
small thing: Section 3.1 is labeled "Audit trail and peer identification".
But the content of that Security Considerations section is about not
trusting identification when null authentication is used. It seems to me
that a few words to the effect that some clear indication should be present
in audit/log trails when a purported identity has not been authentication
should  be included, as I expected them to be from the section heading.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Tue, 26 May 2015 10:20:31 -0400 (EDT)

On Tue, 26 May 2015, Donald Eastlake wrote:

Thanks for the review Donald,

> The Security Considerations section is quite thorough. I did notice one small thing: Section 3.1 is labeled
> "Audit trail and peer identification". But the content of that Security Considerations section is about not
> trusting identification when null authentication is used. It seems to me that a few words to the effect that
> some clear indication should be present in audit/log trails when a purported identity has not been
> authentication should  be included, as I expected them to be from the section heading.

The bulk of that section was moved into section 2.2i and 3.2.

How about:

OLD:

    With NULL Authentication an established IKE session is no longer
    guaranteed to provide a verifiable (authenticated) entity known to
    the system or network.  Implementers that implement NULL
    Authentication should ensure their implementation does not make any
    assumptions that depend on IKE peers being "friendly", "trusted" or
    "identifiable".

NEW:

    With NULL Authentication an established IKE session is no longer
    guaranteed to provide a verifiable (authenticated) entity known to
    the system or network. Any logging of unproven ID payloads that
    were not authenticated should be clearly marked and treated as
    "untrusted", possibly accompanied by logging the remote IP address
    of the IKE session. Rate limiting of logging might be required to
    prevent excessive logging causing system damage.

then move this bit:

    Implementers that implement NULL
    Authentication should ensure their implementation does not make any
    assumptions that depend on IKE peers being "friendly", "trusted" or
    "identifiable".

To just above the "While implementations should..." in section 3.2

Paul

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 26 May 2015 11:46:53 -0400

I'm okay with that change.  I thought that we discussed this last, there
was an emphasis on the possibility to avoid logging unauthenticated
sessions though?  I see there is wiggle room to allow for that still.  Does
the new text meet your needs and still allow for logging of authenticated
sessions (my previous concern that was addressed).

Thanks,
Kathleen

On Tue, May 26, 2015 at 10:20 AM, Paul Wouters <[email-masked]> wrote:

>> small thing: Section 3.1 is labeled
>> that a few words to the effect that

-- 

Best regards,
Kathleen

---

From: Paul Wouters <[email-masked]>
Date: Tue, 26 May 2015 12:06:11 -0400 (EDT)

On Tue, 26 May 2015, Kathleen Moriarty wrote:

> I'm okay with that change.  I thought that we discussed this last, there was an emphasis on the possibility to
> avoid logging unauthenticated sessions though?

We mostly talked about not using unauthenticated IDs and only use them
for logging. Then Tero wanted it for additional debug and we loosened
up to allow ID's other than ID_NULL for AUTH_NULL. We added text to
ensure no security decisions are based on unauthenticated IDs in
section 2.2.

We never talked about completely not logging unauthenticated sessions.
I'm sure everyone would like at least some logging of that. What we
noticed in our deployment though is that logging failures is what
really kills you - in our Opportunistic IPsec we clearly enounter 99.99
percent of "no IKE daemon, so incoming ICMP message", followed by a
0.01% chance we found an IKE server that was never meant to talk IKE
to us, returning a NO_PROPOSAL_CHOSEN. On an open DNS resolver (yes
we like real hammer tests) this filled up on 4GB log disk in 15 minutes.
So we are making changes to minimize logging in the Opportunistic case.

But these considerations are not specific to AUTH_NULL and should go
into the (to be created) Opportunistic IPsec document.

>  I see there is wiggle room to allow for that still.  Does the
> new text meet your needs and still allow for logging of authenticated sessions (my previous concern that was
> addressed).

As I read the new text, it makes no statement about authenticted IKE,
only about things to do or not do when using unauthenticated IKE

Paul