On Mon, 26 Jan 2015, Tero Kivinen wrote:
I was not commenting about the "when authenticated IKE sessions are
not possible" (== with VPN we do have authenticated IKE sessions, so
it is clear it overrides the un-authenticated IKE sessions). I was
commeting on the second requirement, i.e. that "only alternative would
be to send plaintext".
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".
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.
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 ? :)
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.
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.
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.
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].
If you can track to user, so can active attackers doing MITM. That's
the problem.
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.
devices using same resource (i.e. moving video stream from your mobile
phone to your laptop by just connecting from your laptop and creating
new Child SA with same traffic selectors and disconnecting your mobile
phone, so all traffic will now go to the laptop (which have requested
same internal address associated with the user from the server).
First of all, if you crashed there is nothing anyone can do. There is no
way to tell you apart from another new connection. Unless you abuse the
random ID and store it across reboots which is _really_ putting in too
much trust, because now I can obtain/hack/reverse engineer your random
ID to actually obtain your encrypted IP streams. I really don't want to
go there.
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 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.
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.
Second, if you want to move your video stream from your phone to your
laptop, explain to me how I cannot abuse that mechanism to streal your
phone's videostream to _my_ laptop?
If it is un-authenticated, there is nothing restricting that. That is
what null authentication is all about. If it is not anonymous, but
uses some kind of random IDs or pseudonyms, you need first break my
random ID before you can do that, so it adds more protection.
I don't need to break it! I can just MITM you and you will give it to
me. You will just hit reload and now you have your cats and I have your
random identity.
The only way I can think of is if your securely transfer your
"random ID" from one device to the other, meaning it is easier
really easy for you to type in, or you are using an authenticated
connection between your laptop and phone, in which case you should
just transfer the entire IKE and IPsec state without needing a
protocol change here.
Or the random id might be derived from my long lived secret I already
have in all those devices, and the current date / time.
how long to you want to be able to switch between laptop and phone?
Watching 45 minutes of cat video's? Your random id has to be valid
for more then just 1 minute if you want to pass that along. The longer
you keep it using the same ID the worse things get.
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.
As for your cat video hand-over, how about handing over the reference
pointer of the video stream instead between devices :P
Having applications being able to move the IKE and IPsec state over is
bit more challenging than sending information about to where to
connect and what ID to use... For example I think chrome-browser now
have this feature where you can say that move this stream of video
from this screen to some other screen logged in as same user. Then the
link to url will go through the cloud service provided by the
application and is protected by that application. The url could
include your random ID or something.
Use authenticated IKE......
Also, your "random ID" is beginning to look a lot like a kerberos token :P
Not really, as that would be authenticated token. In this case it
would simply be random pseudonym of me, which I could share between
few devices, and which I might change at will without telling anybody.
Create ID_PSEUDONYM.
Section 3.4 should most likely also mention RFC5739 as it allows
assigning full /64 address block to client, and with that you might
use wider traffic selectors. I think we need separate section for the
traffic selectors. Now some of that is in the section 3.3 (not
replacing IPsec SA), and some are in 3.4. The title of "Network
topology changes" does not really describe the problem with traffic
selectors. Moving all text related to it to separate subsection might
make things easier.
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.
and also perhaps talk about per flow SAs etc.
I still have not understood a valid use case for this, let alone one
that justifies the potential negative effects allowing multiple IPsec
SA's gives.
What are negative effects there are? If you do not have resources,
then do not allow. That is what policies are for. If you have
resources for it, and the policy allows it, go for it.
More features lead to more interop problems. More negotiation
mismatches leads to more negotiation packets which lead to delays
in IKE and IPsec SAs and everything needs to carry.
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.
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.
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
Paul
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
