On Mon, 19 Jan 2015, Tero Kivinen wrote:
In section 2.2. it still says that ID presented MUST be ignored.
I think this needs to be changed to SHOULD.
There are valid cases where we would like to use the ID, for example
we might want to assign the same ID same IP-address every time, just
to make things easier.
Of course that's just a band-aid for the ill advised idea of handing out
IP addresses to strangers :)
This does not mean we trust the ID in any way,
it would be used just in same way as DHCP client id is used, it is
just conveniency feature, not security feature.
Another use case for it is to audit it in the logs, or show it to
adminstrators.
If we say SHOULD, that would conflict with your use cases. I don't want
to give advise in a document only to have common practise ignore that
advise. If your use cases are valid then we should address it
differently.
It seems to be that what you want is something that is neither ID_NONE
nor any of the currently defined ID types. Perhaps a new ID Type should
be introduced for your use cases? ID_SESSION ?
I.e. in some environments the users do not have reason to lie for
their ID, but they still might not want to do authentication. Yes
attacker can fake the ID, and there is nothing we can do for it, but
when the user contacts the admin and wants to complain something, it
much easier if he can say that I use ID [email protected], and then
admin can check out the logs or mangement information for that ID.
Honestly, in those use cases asking them for whatsmyipaddress.com is
going to accomplish the same (or "show IP" if on a LAN)
Also how are you going to validate that the server actually follows
that MUST? How do you verify form outside that the implementation
actually ignores the ID field?
Is there a rule that says you cannot say MUST if you cannot confirm
compliance?
I would recommend changing that text to either say that SHOULD, or to
change it to say where it it is ignored, i.e "MUST be ignored for
trust and policy checking", or something similar.
Works for me. If I can also add a "SHOULD NOT be sent when anonimity is
a concern".
On the other hand same section says that ID_NULL SHOULD only be used
with NULL authentication method. In which scenarios do you think
ID_NULL can be used when using normal authentication? I.e. which is
the exception for the SHOULD?
I'm thinking this was mostly an editing mistake. We did want to give you
your logging Id option. I think perhaps we changed the wrong MUST to
SHOULD.
One such case might be when using Raw public key authentication, i.e.
in which case the ID is not really in the ID payload, but the public
key is the identity instead. If this is the reason why you say SHOULD,
then we should mention it here.
I had not thought about that, but it is a good point. Will do.
The section 2.3, I do not think there is ever reason to do liveness
check for all other IKE SAs using null authentication. There is
already normal inactivity based liveness checks, so that will take
care of the SAs already, there is nothing we need to do when we
receive INITIAL_CONTACT for some other IP address. What we can do that
if we do receive INITIAL_CONTACT from same IP-address we already have
IKE SA, we could do liveness check for that SA, as that is the most
common case.
I fully agree, except replacing INITIAL_CONTACT with "new
unauthenticated IKE SA". INITIAL_CONTACT is meanngless in the context
of unauthenticated SAs. If you would take that into account, an attacker
could launch a zilltion IKE SAs with you omiting INITIAL_CONTACT to fill
up your memory without itself needing to keep its IKE SAs in memory.
Much better to ignore INITIAL_CONTACT and send liveness probes for the
same IP address, so that if this is an attacker, they also have to keep
up all the IKE SAs. (and still an easy defense is not more than XXX IKE
SA's per IP address, sure some CGN might suffer, but they're CGN :P)
I.e. device creates anonymous IKE SA with server, then device is
restarted, and it creates new IKE SA and now it will send
INITIAL_CONTACT as it does not have any SAs with server. Most likely
those connections have same IP-address, thus to clean up state, it is
enough to just do liveness check for old IKE SA from the same
IP-address. We cannot just remove it as the IP-address might be the
address of the NAT box.
I'd say just always do that check, and ignore INITIAL_CONTACT.
Also if the device sent some other ID than ID_NULL, we could
Please don't make any decisions based on IDs of unauthenticated IKE SA's.
You keep saying "only for logging" and keep trying to be smart and
use it for other things.. Keep it simple, "nothing but logging of the
ID". That's my compromise :)
Btw, this INITIAL_CONTACT cleanup might be one reason why people might
have good reasons to use unique valid IDs (perhaps random KEY_ID
created when software is installed, or once per week or something like
that).
unfortunately, the nice user that causes a few lingering SA's is not a
problem at all. It's a few bytes in the kernel and IKE daemon. It's
the malicious clients that matter, and they can tweak using or not
using INITIAL_CONTACT and unverifiable IDs. So in my opinion, this
adds complexity and optimises only for the case that does not need
optimising and fails to be useful for the actual malicious case.
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.
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.
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.
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? :)
You repeat the ID processing rules in the security section, but the
MUST is different, as here you do have the logging exception (which
you did not have in section 2.2). But there might also be other uses
in addition to the logging for the ID, for example the INITIAL_CONTACT
notification matching, i.e. which peers to check for liveness when
INITIAL_CONTACT is received.
I'll sync those sections.
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".
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.
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.
In section 3.3 you only say that un-authenticated IKE peers MUST NOT
be able to replace the IPsec SAs of an authenticated IKE peer, but not
that authenticated IKE peer cannot steal un-authenticated, i.e.
replace them IPsec SAs. Is this intentional?
No. I will fix that.
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.
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? 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.
Also, your "random ID" is beginning to look a lot like a kerberos token :P
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.
Also what error is used when client tries to use traffic selectors
which are already in use, or which are not allowed for it (i.e. trying
to steal 8.8.8.8)?
For stealing attempts the TS_UNACCEPTABLE would be correct, as servers
policy should not allow such traffic selectors. Or
SINGLE_PAIR_REQUIRED is also possible if there is no trigger packet
information.
I'm fine with TS_UNACCEPTABLE (38)
If you try to reuse traffic selectors in use, I think the
TS_UNACCEPTABLE is ok for that too, as this could also be considered
similar policy error as described in the rfc7296:
o If the responder's policy does not allow it to accept any part of
the proposed Traffic Selectors, it responds with a TS_UNACCEPTABLE
Notify message.
Note, that we do want to put policy blocks for all addresses given to
the client, not only those which are in use now. I.e. if IP A and B
are given to client, both of them should be blocked from everybody
else even if only one of them is in use. Same thing with prefix given
by RFC5739.
Sure.
In general I think we still need more work on this draft, especially
in the security considerations section, and actually moving some text
away from there to the actual body would be good. I.e. adding new
section between 2.2 and 2.3 about the traffic selectors, and moving
discussion about the traffic selectors and what kind of policy checks
to do for those, and what kind of use cases there might be is needed,
and the security considerations section should have more about the
attacks, and their counter measures.
That sounds fair.
I.e. the first section would say that server could be configured to
only allow IP-IP transport mode connection, or always give client a
address using configuration mode, and limit client end to it (or to
/64 given by RFC5739),
Sure.
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.
Thanks for your review! We will put out an updated version after
collecting other feedback during this WGLC.
Paul
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
