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

[Paul Wouters <[e-mail]>]

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

> Thanks,
> Kathleen
> 
> On Tue, May 26, 2015 at 10:20 AM, Paul Wouters <[e-mail]> wrote:
>       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
> 
> 
> 
> 
> --
> 
> Best regards,
> Kathleen
> 
>