[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipsec
Subject:    Re: [IPsec] My comments to the Null Authentication Method draft
From:       Tero Kivinen <kivinen () iki ! fi>
Date:       2015-01-26 17:21:34
Message-ID: 21702.30622.341411.862146 () fireball ! kivinen ! iki ! fi
[Download RAW message or body]

Paul Wouters writes:
> > I think that requirement is too strict. I.e. I think we should be able
> > to use un-authenticated IKE sessions even when when we are using
> > 40-bit WEP on the link. With your text we cannot, as Un-authenticated
> > IKE sessions MUST only be attemtpetd when the ... only alternative
> > would be to send plaintext. 40-bit WEP is not plaintext, thus we
> > cannot use un-authenticated IKE...
> 
> I think the text clearly does not refer to the underlying smoke signals or
> avian carriers. plaintext clearly refers to "not encrypted by IKE/IPsec".

If you mean that you should say so. I think not everybody think https
as plaintext for example, but you seem to consider it so. 

> > We can only provide false sense of security if we somehow show this to
> > user. For example in tcpinc the general consensus seems to be that
> > users should never see if tcpinc is on or off, thus we cannot give
> > false sense of security. Same thing here. If you do consider
> > un-authenticated IKE as plaintext, you cannot give false sense of
> > security. If you only put "lock" on when you actually do authenticated
> > IKE then there is no problem.
> 
> I would like to remain completely outside the realm of GUI and The User.
> For example, OTR has a state "unverified" to indicate encryption without
> authentication. I do not wish this document to forbid that.

Agree, but you started talking about false sense of security, which is
only possible if you have gui that leaks that information to user. 

> > The reason why you want to use un-authenticated connections sometimes,
> > might be when the authentication is annoying, for example when using
> > securID or similar interactive method.
> 
> So you want to use AUTH_NULL to bypass the administrative policies ? :)

No. I want to express adminstrative policy which only requires
authentication in those operations actually needing it. You want to
enforce the policy by the protocol, and I do not think that is good
thing to do.

> > You seem to have very limited use case for this thing, and I would
> > like to see much wider user case, i.e. actually going to similar use
> > cases than tcpinc has, but not restricted on the tcp layer, but also
> > working with udp and other protocols.
> 
> I believe you are needlessly trying to complicate a very simple concept.

Actually you are restricting it, I want it to be open for all possible
use cases... 

> How about I rephrase the original:
> 
>     Un-authenticated IKE
>     sessions MUST only attempted when authenticated IKE sessions are not
>     possible for the remote host and the only alternative would be to
>     send plaintext.
> 
> to:
> 
>     Un-authenticated IKE
>     sessions MUST only be attempted when authenticated IKE sessions are not
>     possible for the remote host and the only alternative would be to
>     not us IKE at all.

No, as I have already pointed out, I actally do want to use mixed
authenticated and un-authenticated IKE if such thing is ALLOWED by the
policy. I do not want it to be restricted at all on the protocol
level. 

> And actually, now I feel I need to clarify this further to allow
> properly for servers preferring anonymous IKE clients:
> 
>     An IKE initiator that wishes to use NULL Authentication for itself
>     SHOULD attempt to authenticate its IKE peer. An IKE responder MAY
>     allow its peer to remain un-authenticated but SHOULD attempt to
>     establish an IKE session where it can be authenticated by the IKE
>     initiator.  A mutually un-authenticated IKE session should only be
>     used if the alternative is to not use IKE at all.

Again I would rather say that all that is dictated by the policy, not
by SHOULDs etc in the RFC. 

> >> You are right it might not compromise it, but it also might. For
> >> instance your phone switching between LTE and Wifi while using the
> >> same "random ID".
> >
> > So you should say that not using ID_NULL might compromise the client
> > anonymity, not that it will compromise it.
> 
> We do say that earlier in the document:
> 
>     Furthermore, sending a traditional ID field might
>     unwittingly compromise the anonimity of the peer.
> 
> But in the security section we say:
> 
>     Using an ID Type other than ID_NULL with the NULL Authentication
>     Method compromises the client's anonimity.
> 
> (spelling fixed in -03)
> 
> So I agree this is a little conflicting. Note that there are two cases
> here to consider:
> 
> 1) the anonymity of the client to the server
> 2) the anonymity of the client to an active MITM atacker
> 
> So perhaps we can rewrite the security section item to:
> 
>     Using an ID Type other than ID_NULL with the NULL Authentication
>     Method can compromise the client's anonimity in case of an active
>     MITM attack [and should be avoided].

There is nothing that restricts null authentication to anonymous uses.
It seems you are again thinking more about the opportunistic use case
than the null authentication.

I would suggest chaning can to may and removing the stuff at the end:

     Using an ID Type other than ID_NULL with the NULL Authentication
     Method may compromise the client's anonimity in case of an active
     MITM attack.

> > Yes, it might be problem in some cases, but not all use cases for the
> > null require anonymity. Actually almost all of the uses I have in
> > mind do not.
> 
> The -03 version has this relaxed. Although from reading your emails, you
> are doing _exactly_ what I think we should urge implementors not to do.
> Making decisions based on a completely falsifiable piece of information.

Yes, and I would still like to do so in the future. All these emails I
have been replying to are based on the emails which are completely
falsifiable, and I think it is fine for me to continue assuming that
they are proper unless someone points out otherwise.

Similar usecases are possible in the IKE. 

> > Your use cases are more restrictive than mine. I can see uses cases
> > where that is useful, especially when we are talking about anonymous
> > opportunistic uses.
> >
> > I mean if there is no authentication, the video stream does not have
> > any secret information in it. I mean yes, you could steal someones
> > youtube stream that way (again not talking about specially youtube, as
> > it uses http, but similar kind of service or class of services), but
> > what is the gain. You could have started looking at the same cat-video
> > yourself.
> 
> The cat video is fine. Unfortunately your software used a persistent
> random_id when you watched that Snowden documentory afterwards....

In wihch case then I would want to do something to hide that
information, i.e. use tor or something else. Changing my ID does not
help at all as my IP would still be stable, so what is the benefits
for me of using ID_NULL all the time?

> > In some use cases there might be some information that might be leaked
> > out if for example the great firewall of country x suspects someone is
> > looking unsafe cat-videos, and would want to verify that by stealing
> > users connection, but it might be easier to just do that from the
> > start...
> 
> How or when they attempt to does not matter. What matters is that you
> are not using an identifiable marker to put a target on your back.

Unfortunately there is already IP-address which are already tied down
to my name...

If I want to hide myself from the network I need to use tor or
similar, just using un-authenticated IKE connection using ID_NULL does
not help me at all. 

> > For normal user the conveniency of being able to move things around is
> > more important than the fact that someone might steal his cat-videos.
> 
> And for some users having encrypted chats be logged to disk automatically
> is more convenient than for others, such as a whistleblower that is now
> sitting in jail because of that. I'm sorry, but in my opinion that use
> case trumps your cat videos.

So you want to provide false sense of security for that 0.0000001% of
user base who are whistleblowers, and cause annoyance for the rest of
the users?

And as I pointed out claiming that un-authenticated IKE is safe for
whistleblowers to use is really creating false sense of security. 

> Again, your abuse of the unverifiable but tracable ID is EXACTLY why
> the RFC should limit its use to "logging only" and "debugging only"
> and it should STRONGLY recommend only using ID_NONE.

You seem to think this is "Anonymous Authentication mode in IKE"? It
is un-authenticated authentication method. There is nothing there that
requires anonymity for NULL authentication to be useful. None of the
use cases described in the introduction require anonymity.

Actually in use case 1 the user might want to use non-anonymous
un-authenticated connections. In use case 2 the sensor does not really
care what identity server provides, and as server by definition has
fixed IP-address there is no anonymity there at all anyways.

for the 3rd use cases there is word "anonymous" added there, which
should not be there. To protect against pervasive monitoring does not
need to provide anonymity.

I would actually change the last sentence of the use case 3 to say
"This case might use a fully anonymous un-authenticated key
exchange.". 

I agree there might be use cases for anonymous uses for the NULL
authentication, but I do not think all use cases are anonymous.
Because of that I think it is good idea to define ID_NULL that can be
used if anonymity is needed, but I do not see any reason why NULL
authentication should only use it.

> >> Sure, once we reach agreement of what can/should/must not be done with
> >> traffic selectors.
> >
> > Yes, that is big part missing from the draft.
> 
> Yes, that's still a little bit of a problem in the -03 draft too.
> Another case of allowing many cool things versus the security risk
> and interop problems.

Which is why I think this draft should not say that much about it, but
most of the stuff should be put to the opportunistics use case draft. 

> We also have no way currently in the IPSECKEY record of advertising
> "only request encryption foo strength for address bar port baz". So
> it will just lead to a lot of useless CREATE_CHILD_SA requests failing.

You do not need to use the per flow SAs if you do not like. You might
also say that in your opportunistic IPsec those are forbidden. Other
people might have other uses for null authentication than your
opportunistic IPsec...

> Allowing it when you have the resources for the additional SAs will just
> lead to attackers filling up your memory and now you are always running
> at scarce resources for real clients and real clients cannot request
> port specific SAs anymore and have to default to the full host-host SA
> anyway. You're just wasting resources with the same endresult.

For attackers it is about as hard to create 10000 IKE SAs each having
one Child SA, than creating 1000 IKE SAs each having 10 Child SAs. So
if you put Child SA limit too low, attackers will create more IKE SAs
and vice versa. 

> > I do not see reason why we should restrict it out here.
> 
> That has been the problem with IKE/IPsec :P A swiss army knife to cut
> yourself with :P

Hah, you have not seen swiss army knife of protocol before you start
reading IEEE 802.15.4... Nothing is fixed there, everything is left
open for implementors or next higher layer to solve. IKE is so simple
and does not even have any options compared to it (or 802.11 too I
think)...

Anyways we are talking about generic protocol concept here, not some
specific use case. Opportunistic IPsec should restrict all kind of
things, this NULL authentication should allow policy to allow
different things. If you do not want to implement such policy or such
RFC specifying such policy, you do not need.
-- 
kivinen@iki.fi

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
[prev in list] [next in list] [prev in thread] [next in thread]