Paul Wouters writes: > On Mon, 19 Jan 2015, Tero Kivinen wrote: > > In security considerations section there is text: > > > > 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. > > > > I assume that s/MUST only attempted/MUST only be attempted/ > > yes. > > > but also I do not think we cannot use un-authenticated IKE session > > even when there was 3rot13 method to "encrypt" the packet. In your > > text we cannot replace 3rot13 method with Un-authenticated IKE > > sessions as it is not plaintext (you can also replace 3rot13 with > > other weak cipher for example 40-bit RC4, or single DES). > > Yes, if you have a corporate VPN tunnel defined that uses authentication > and dictates 3rot13 encryption, I believe it should pick your corporate > VPN and not do unauthenticated IKE with unbreakable threefish. Because > your undecryptable threefish can still be trivially MITM'ed. We should > not start evaluating whether we think MITM'able threefish is more secure > than authenticated 3rot13 or not. The decision was made when you > configured that authenticated VPN.
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... > > Also limiting un-authenticated IKE sessions this way really restricts > > the use cases for this. I would rather says that "If authenticated IKE > > sessions are possible between the hosts, then un-authenticated IKE > > MUST NOT be used". But even that will restrict some use cases. > > I'm fine with that text. If it restricts a use case, then that's great. > The use case would be inheritently unsafe and provide a false sense > of security. 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. The use case I was talking about was this kind of anonymous un-authenticated reading of forums, but requiring authentication and encryption for posting. And in this context consider forums as general name for all kind of services we might run on server, not all of those need to be interactive. We might also have cloud service storing some kind of measurements from your phone. To submit new entry you would require authentication. To reading information there might not be need for authenticaiton, thus un-authenticated encrypted connection might be ok. 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. > > For example some forum site might want to restrict posting of new > > comments to authenticated users, but would still want to allow reading > > of entries without doing authentication. > > That's really an application level issue. We are just talking about > encrypting the transport where the alternative is plaintext. Your > forum should have HTTP basic auth to identify users, the user > identification does not belong at the IKE layer. HTTP basic might work for forums, but as I explained above, the protocol used might not be http, and the connection might not be coming from user. The authentication might require user interaction, which is the reason we might not want to do it all the time. 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. > > be configured to be able to do both. In normal case the user will > > always do un-authenticated connection to read entries, and when he > > decides to post a reply or new comment, the software would > > automatically create new authenticated IKE SA and do the actual post > > through that, even when still at the same time keep the > > un-authenticated connection for reading... Btw, in such cases the > > connections might use per TCP-flow Child SAs... > > Apache is not going to talk to the IKE daemon to do user authentication. > That's far more expensive than HTTP Basic Auth, and would require a > decade of IKE deployments to make it universally available. Let's talk > about real use cases? :) IKE has about the same expense than doing TLS. You are saying that no http server never runs TLS, because that is much more expensive than HTTP basic auth... And I used forum as example of classes of services you might run. All kind of cloud services are another class of services you might run.The forum might also be using nntp instead of http interface to provide the forum services. I talked about the forums, you assumed I talked about web/http. There are other ways of implementing forums than http. > > You also claim that using ID type other than ID_NULL will compromise > > the clients anonymity. I do not agree on this statement. Using > > pseudonyms, or completely random ID for each connection will not > > compromise anonymity, but will allow certain use cases. In some cases > > there might be reasons to allow matching old and new sessions to same > > client (for example INITIAL_CONTACT) but even that does not compromise > > the anonymity. > > 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. > > Even if you know that same ID is used, and it might be > > same user than last time, that does not mean that you know who the > > user is. > > 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. > > Section 3.1 asks for implemntations to "audit implementations for any > > assumptions". I think better wording is needed, I do not want to > > provide our customers a audit records for this kind of things (and I > > know some of our customers would be reading this text in such way that > > we must provide those audit records). > > > > Perhaps the text should say that implemenations should verify that > > their assumptions are still valid or something like that. Or just warn > > implementors that their assumptions might not be valid anymore... > > Sure :) I was not aware of such creative customers. You are so lucky... We have had customers reading appendix of RFCs listing choises the authors considered, but didn't select and reasons for not selecting them, and then asking for us to provide those options. And the reason for why they need it: "it is in the RFC". > > There are use cases where user1 wants to replace Child SAs created by > > same user1, i.e. when you reconnect after crash, or you have multiple > > 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. 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... 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. If someone does active attack and steals it, then he just needs to start it again... > 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. > 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. Or I might simply transfer the request to move the date over bluetooth and include the secret there or whatever. 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. > 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. > > 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. > > 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. I do not see reason why we should restrict it out here. -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
