Subject: [IPsec] My comments to the Null Authentication Method draft

From: Tero Kivinen <[email-masked]>
Date: Mon, 19 Jan 2015 17:50:55 +0200

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. 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.

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-masked], and then
admin can check out the logs or mangement information for that ID.

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?

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. 

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?

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.

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.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.

Also if the device sent some other ID than ID_NULL, we could again do
liveness check for those IKE SAs which have same ID than the new
connection coming in, but of course you would want to rate limit those
just in case someone makes implementation where everybody uses
"[email-masked]" or similar as their ID, so everybody has exactly
same ID (doing that would be stupid, but that has never stopped people
to do things).

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).

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/

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).

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.

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. In such cases the client can
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...

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.

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. 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.

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...

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? I.e why would there ever
be use case where any two different users should be allowed to steal
other users IPsec SAs (i.e. replace / overwrite them)? I would assume
that if user1 has Child SA, then user2 should not be able to create
Child SA that steals user1's traffic. I think this should be true even
if user1 is authenticated and user2 is not, or vice versa. It should
also be true even if both user1 and user2 are un-authenticated (i.e.
all un-authenticated users are by definition different users).

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).

So I would think the section 3.3 should be formatted better.

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.

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.

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.

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.

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), and also perhaps talk about per flow SAs etc.
The second part should talk about the address stealing and policy
checks on traffic selectors.
-- 
[email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Mon, 19 Jan 2015 11:59:24 -0500 (EST)

On Mon, 19 Jan 2015, Tero Kivinen wrote:

> 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,

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 ?

> 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)

> actually ignores the ID field?

Is there a rule that says you cannot say MUST if you cannot confirm
compliance?

> 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".

> 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.

> then we should mention it here.

I had not thought about that, but it is a good point. Will do.

> IKE SA, we could do liveness check for that SA, as that is the most

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)

> IP-address. We cannot just remove it as the IP-address might be the

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 :)

> created when software is installed, or once per week or something like

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.

> I assume that s/MUST only attempted/MUST only be attempted/

yes.

> 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.

> 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.

> 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.

> 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? :)

> INITIAL_CONTACT is received.

I'll sync those sections.

> 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

If you can track to user, so can active attackers doing MITM. That's
the problem.

> implementors that their assumptions might not be valid anymore...

Sure :) I was not aware of such creative customers.

> replace them IPsec SAs. Is this intentional?

No. I will fix that.

> 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

> selectors. Moving all text related to it to separate subsection might

Sure, once we reach agreement of what can/should/must not be done with
traffic selectors.

> SINGLE_PAIR_REQUIRED is also possible if there is no trigger packet

I'm fine with TS_UNACCEPTABLE (38)

> else even if only one of them is in use. Same thing with prefix given

Sure.

> attacks, and their counter measures.

That sounds fair.

> /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

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 20 Jan 2015 16:53:23 +0300

Hi Tero,

thanks for your detailed review. Please see inline.
I commented only the issues where we disagree with Paul.

> the exception for the SHOULD?

It could be used, for example, in the first IKE_AUTH message sent from
the client when EAP authentication is requested. If SGW is acting
as pass-through between client and backend authentication server
(e.g. RADIUS), that server will typically start EAP session from 
requesting EAP Identity anyway, so the ID Payload received
from the client becomes useless.

> then we should mention it here.

This is another example when ID_NULL could be used with non-NULL
authentication.

> IKE SA, we could do liveness check for that SA, as that is the most

The intent was to hint to implementers, that the event of creating 
new unauthenticated IKE SA MAY be considered as a trigger for 
liveness check procedure on inactive unauthenticated SAs. There is 
no requirement that this check be immediately done on all the SAs.
But without such advise naive implementation may ends up 
having a lot of stale IKE SAs (for example, if it performs
liveness check only if it needs to send data over SA).

> those connections have same IP-address, thus to clean up state, it is

Not necessary. Depending on the ISP the client may get new IP address.

> IP-address. We cannot just remove it as the IP-address might be the

It is not enough to check only SAs with same IP-address.
However, as I've written above, there is no need to 
immediately perform liveness check on all SAs.
The event of creating new unauthenticated IKE SA is just a hint, 
that some of other such SAs might become stale and 
they need to be checked (no rush though).
It is implementation dependant how this check is done - 
implementations may check all the SAs if there are 
a handfull of them, check first SAs with the same IP
address and let the other to be checked on a time-based basis,
or ignore this event at all and rely on usual regular checking.
I don't think the document should mandate such things.

> liveness check for those IKE SAs which have same ID than the new

The -01 version of the draft recommended doing so.
Do you think it is worth put it back?

Sure.

> same ID (doing that would be stupid, but that has never stopped people

...

> MUST NOT be used". But even that will restrict some use cases.

I think this wording is too restrictive.

Well, the question is: why do we need NULL auth at all.
If it is intended only for opportunistic security, then yes,
it must only be used if the peers cannot authenticate
themselves. But there are use cases when the user is able
to authenticate himself/herself, but he/she doesn't want
to do it for the particular SA. For example, if I'm an Wikipedia
editor, then I need to be able to authentiacte myself while
I perform edits. But I want to keep anonimity while I read
Wikipedia to prevent tracing back what I'm interested in. 

> connections might use per TCP-flow Child SAs...

Exactly.

Regards,
Valery.

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 20 Jan 2015 23:30:32 +0200

> IP addresses to strangers :)

Assigning IP address to clients makes things easier, especially if the
client is behind NAT. If client is behind NAT it will have
non-routeable, perhaps overlapping addresses, thus using the real
client address is hard, and the server will most likely need to do
internal NAT for the address (specific to each Child SA) before it is
given to the IP stack of the server.

Giving address to the client makes things bit easier, as this is
standard, widely used method of doing this, and then server can use
this address it allocated from its own address pool without any
problems, as it can ensure that there are no overlaps, and those
addresses in the address pool are so that they will be routed
properly. 

> advise. If your use cases are valid then we should address it

Yes, MAY is another possibility, but I think actually SHOULD is good
compromize. Not everybody wants to use ID for anything, and if you
really do unauthenticated, and anonymous connections only, there is no
point of using ID. If you do unauthenticated, but not necessarily
anonymous (in a sense that clients can claim to be same person than
before, or give their identification information, even when they
cannot proof it) then using ID has valid points.

I myself claim that there are use cases where clients might have valid
use cases for giving some kind of ID, even when they do not
authenticate the ID. 

> be introduced for your use cases? ID_SESSION ?

No. I do not want that. I want to use currently defined IDs. For
example I might configure my client to use ID of [email-masked] when I
am connecting to the forum, even when I do not authenticate that ID
anyway to the server. I myself usually do not try to be anonymous, but
I do see value of having encryption, even when it would be
unauthenticated.

The forum adminstrator might then log that information, and might even
contact me using that completely untrusted information, just because
it happens to be there. This is similar to many other information I
give to those stupid registration pages, some of those are true, quite
often they are just "none", "none", etc as I see no reason to give
some information to them just because they ask them. I do usually give
my real name, and quite often also real email address...

I understand that not everybody want to do that, and I agree that
there are some uses cases where you do not want to give any identity
information, but I do want this document to remove possibility for
giving that information...

> going to accomplish the same (or "show IP" if on a LAN)

Not really, as the IP-addresses used changes quite often. Especially
on mobile devices roaming around the world... Yes, my home-ip happens
to be stable, but my laptop IP isn't, so I have no idea what IP I used
last week on my laptop when in IEEE meeting, or in the hotel room. If
the issue happens just now, then show IP might work, if it happened
last week that does not help. The configured ID will help.

> Is there a rule that says you cannot say MUST if you cannot confirm

No, but when you receive customer request to provide you the line
numbers in your source where you ignore that ID, then it gets fun.

We did get customer asking us where we implement "MUST NOT send
certain packets", i.e. what are the exact code lines where we do that
"MUST NOT"... (or something like that). I think we responded that all
of the lines in our source code implement that, as none of the lines
send those packets :-)

Also of course we should be able to provide matrix that we have two
independent implementations do implement that MUST... 

> Works for me. If I can also add a "SHOULD NOT be sent when anonimity is

That works. 

> your logging Id option. I think perhaps we changed the wrong MUST to

Ok.

> I had not thought about that, but it is a good point. Will do.

Ok. 

> I'd say just always do that check, and ignore INITIAL_CONTACT.

Thats fine. Initial contact is not that important in IKEv2 anymore, as
we do have other ways of cleaning up state. 

> ID". That's my compromise :)

I was not saying only for logging. I was saying there are uses for it,
and one of those uses is for example logging. There are other uses for
it, and matching pervious connections is one of them. That is not
trust or policy decision, it is just decision whether to do liveness
check or not for some specific IKE SA, and that will be something that
will help the server to handle its resources...

Again we are talking about unauthenticated connections, not
necessarily anonymous connections.

> optimising and fails to be useful for the actual malicious case.

It does not really add complexity as the code is already there. That
is what is done for normal authenticated initial contacts. The only
thing we want to do there is not to delete it immediately, but instead
trigger liveness check instead.

Also most of the time you are NOT under attack, so maintaining
resources during that time is also nice...

Telechat in 2 minutes, need to stop now... I'll be back...
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 26 Jan 2015 16:39:53 +0200

> 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...

> The use case would be inheritently unsafe and provide a false sense

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. 

> 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. 

> decade of IKE deployments to make it universally available. Let's talk

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. 

> instance your phone switching between LTE and Wifi while using the

So you should say that not using ID_NULL might compromise the client
anonymity, not that it will compromise it. 

> If you can track to user, so can active attackers doing MITM. That's

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. 

> 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".

> ID to actually obtain your encrypted IP streams. I really don't want to

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...

> 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.  

> Sure, once we reach agreement of what can/should/must not be done with

Yes, that is big part missing from the draft.

> that justifies the potential negative effects allowing multiple IPsec

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-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 26 Jan 2015 17:04:45 +0200

> from the client becomes useless.

Nope. The IKE ID payloads needs to be used, and the EAP identity
reqeuest and respond SHOULD NOT be used (from RFC7296 section 3.16):

   Note that since IKE passes an indication of initiator identity in the
   first message in the IKE_AUTH exchange, the responder SHOULD NOT send
   EAP Identity requests.  The initiator MAY, however, respond to such
   requests if it receives them.

Also section 2.16 warns that if EAP Identity is used, there might be
mismatch with the ID payloads, and correct one needs to be used for
policy lookups:

   When the initiator authentication uses EAP, it is possible that the
   contents of the IDi payload is used only for Authentication,
   Authorization, and Accounting (AAA) routing purposes and selecting
   which EAP method to use.  This value may be different from the
   identity authenticated by the EAP method.  It is important that
   policy lookups and access control decisions use the actual
   authenticated identity.  Often the EAP server is implemented in a
   separate AAA server that communicates with the IKEv2 responder.  In
   this case, the authenticated identity, if different from that in the
   IDi payload, has to be sent from the AAA server to the IKEv2
   responder.

> liveness check only if it needs to send data over SA).

On the other hand if it has enough resources, there is not really a
problem having lots of stale IKE SAs. Storing those IKE SAs in the
memory does not really increase the power consumption of the device
(yes, there might be devices where this might actually be true, and in
that case it should most likely use more aggressive cleanup policy).

If the device is running out of resources, then it should start doing
some cleanup processes (most likely way ahead of when it actually runs
out of resources). 

> Not necessary. Depending on the ISP the client may get new IP

Yes, but very commonly it will get same IP and that is the case we
should optimize for. Doing one liveness check for one IP is cheap.
Starting to do it for 10000 IKE SAs is expensive... Especially if we
have new un-authenticated IKE connections at the rate of 10/sec...
(i.e. the average connection time is few hours). 

> It is not enough to check only SAs with same IP-address.

We do not need to clear out all stale IKE SA from the memory, we need
to make sure we optimize and clean up the most likely one. The rest
are taken care of by the normal cleanup routines.

> they need to be checked (no rush though).

I would expect that servers having so many users that liveness checks
really matter, will have so many new sessions per second, that this
statement is compeltely useless, as you would get this hint several
times per second, which means it is useless hint.

If you only get new un-authenticate IKE SA every few minutes or so,
then you most likely will not have enough stale IKE SAs for them to
matter (lets say you have 4 hour lifetime for IKE SAs and new
connections every 2 minutes, that will mean you have 120 IKE SA).

> I don't think the document should mandate such things.

I agree. But I think more usefull hint for implementors would be to
check the IKE SAs having same IP address than newly created IKE SA,
than the current one we have.

> Do you think it is worth put it back?

Yes. Especially as the rfc7296 will talk about INITIAL_CONTACT and
authenticated identities. When we are talking about un-authenticated
identities we should just say that this does not automatically clean
up any state, just provide hint that liveness check might be usefull
for that IKE SA.

> I think this wording is too restrictive.

As I pointed out, I too think it might be too restrictive... but it is
better than what we have now there.

> Wikipedia to prevent tracing back what I'm interested in. 

Yep. Altough as Paul will point out that wikipedia uses http, so it
would be using IKE, but I assume you similar class of services, some
of which might be running over UDP etc.

How to formulate the text in the draft is different matter. Perhaps

If authenticated IKE sessions are possible between the hosts, then
un-authenticated IKE SHOULD NOT be used, unless implementations make
sure to keep authenticated and un-authenticated IKE sessions separate,
and has policy rules to specify when to use which IKE session.

Or something like that. 
-- 
[email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Mon, 26 Jan 2015 10:37:58 -0500 (EST)

> 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".

> 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.

> securID or similar interactive method.

So you want to use AUTH_NULL to bypass the administrative policies ? :)

> 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

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.

> 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].

> null require anonymity. Actually almost all of the uses I have in

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.

> what is the gain. You could have started looking at the same cat-video

The cat video is fine. Unfortunately your software used a persistent
random_id when you watched that Snowden documentory afterwards....

> users connection, but it might be easier to just do that from the

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.

> 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.

> 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.

> 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

> include your random ID or something.

Use authenticated IKE......

> few devices, and which I might change at will without telling anybody.

Create ID_PSEUDONYM.

> 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.

> 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

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 26 Jan 2015 19:21:34 +0200

> 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. 

> 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. 

> 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.

> 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... 

>     possible for the remote host and the only alternative would be to

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. 

>     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. 

>     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.

> 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. 

> 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?

> 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. 

> 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. 

> 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.

> Another case of allowing many cool things versus the security risk

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. 

> 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...

> 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. 

> That has been the problem with IKE/IPsec :P A swiss army knife to cut

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.
-- 
[email-masked]

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 27 Jan 2015 10:21:04 +0300

I changed a subject field.

>   requests if it receives them.

First, "SHOULD NOT" is not equal to "MUST NOT". 
It is fully legal for NAS to sent EAP Identity request and
not use IKE Identity. Then, many modern EAP methods 
(like EAP-TLS) have their own means to exchange Identities 
within the method, and in this case the initial IKE Identity becomes 
almost useless.

What about the sentence "The initiator MAY, however, 
respond to such requests if it receives them.", - I think that
it is a mistake and the sentence must not be in the RFC.
It tries to mandates EAP behaviour within IKEv2 spec.
Moreover, it contradicts to the EAP specification (RFC3748),
which states (Section 5.1):

      The Identity Type is used to query the identity of the peer.
      Generally, the authenticator will issue this as the initial
      Request.  An optional displayable message MAY be included to
      prompt the peer in the case where there is an expectation of
      interaction with a user.  A Response of Type 1 (Identity) SHOULD
      be sent in Response to a Request with a Type of 1 (Identity).

It is clear that SHOULD is not equal to MAY. It's unfortunate
we didn't cach this contradiction while preparing RFC7296.

>   IDi payload, has to be sent from the AAA server to the IKEv2

This para only supports my idea, that initiator's identity IDi in case
of EAP plays no important role. It's sole purpose is for Authentication,
Authorization, and Accounting (AAA) routing purposes and selecting
which EAP method to use. And it may be ID_NULL, in which case
the default AAA server will be selected and EAP method will be negotiated
within EAP (in most natural way).

Regards,
Valery.

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 27 Jan 2015 13:08:19 +0200

> First, "SHOULD NOT" is not equal to "MUST NOT". 

Yes, as I pointed out in my reply.

> within the method, and in this case the initial IKE Identity becomes 

And for some EAP libraries getting rid of the EAP Identity
request/reply is almost impossible. That is the reason there is SHOULD
NOT vs MUST NOT.

> It tries to mandates EAP behaviour within IKEv2 spec.

No it does not try to specify what EAP does, it specifis what IKEv2
does. I.e. initiator MAY respond to such query, or abort the whole
negotiation, as the other end is not following the SHOULD NOT
specified in the IKEv2 specification.

If the initiator is not able to extract the identities from the EAP
messages, it really should abort the negotiation, as this would mean
that different identity is used for policy decision (the one in ID
payload), and different one is used for authentication (the one inside
EAP). If implementation does not have ability to verify those two
match (with suitable definition of match, i.e. it might use mapping
table etc to map EAP identity to identity to be used in the policy
checking) it should abort the exchange.

> we didn't cach this contradiction while preparing RFC7296.

They do not need to be equal. They are talking about different things.
EAP talks what EAP SHOULD do. IKEv2 talks what IKEv2 MAY do in that
case. IKEv2 could also say MUST NOT respond, and that would still be
ok. Actually as EAP only says SHOULD not MUST, it is actually valid
for the IKEv2 implementation to continue exchange and not respond to
identity request, but I would expect most EAP methods would fail in
that case. Or IKEv2 might take the ID payload and use that to
construct the EAP Identity response. 

> within EAP (in most natural way).

ID payload is the one which is used to do policy lookups in the PAD,
and the PAD is linked to the SPD, which specifies what kind of Child
SAs can be specified. Because of this the ID is the really important
also in the EAP case. The text above in the RFC7296 is there because
some implementations uses ID payloads which do not follow this rule,
and because of this special code is needed to make sure that the
correct PAD entry is located using the authenticated identity, and
that might be the EAP identity instead of ID payload.

In normal case the authenticated identity is ID payload, in some
special EAP cases it might be EAP identity. The implementation needs
to be able to handle this special case if it wants to support such
implementations, but it is ok acceptable for it to ignore this case,
and use ID payload for all policy lookups, and forbid EAP identity
exchanges completely. Usually this is not a problem as EAP identity
requests are done by the server, which is also tied to the AAA-server,
and server implementation will know whether it supports getting EAP
authenticated identity from the AAA-server, and whether it knows how
to use it for policy lookups, and in that case it also knows that
AAA-server might do EAP identity requests. On the other hand server
EAP may also be configured so it never does EAP identity requests, or
even fakes them inside the server code. I.e. when AAA-server sends EAP
identity request, that request is NOT sent to the client, but instead
the server creates suitable EAP identity response based on the ID
payload sent by the client. Now EAP is happy, and client and server
are happy as they didn't waste one extra roundtrip to do EAP identity
request from the client at all.

The text in RFC7296 specifically does not limit the uses of EAP
identities more than that "SHOULD NOT" just because we wanted to leave
things open so different implementations can do whatever is suitable
for them.
-- 
[email-masked]

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 27 Jan 2015 15:43:43 +0300

> request/reply is almost impossible.

Exactly.

> at is the reason there is SHOULD
> NOT vs MUST NOT.
>

As you pointed out earlier in this message that it is EAP library,
not IKEv2, that makes this Identity Request on Responder.
And it is EAP library on the Initiator that this request is passed to.
Actually, at this point EAP protocol has already been started, so why IKE
need to interfere with EAP and make any decisions to which
EAP request should EAP library answer and to which not?

> checking) it should abort the exchange.

What is the point of this check? For many EAP methods
the EAP Identity in Identity Response message is not authenticated
and just plays the same minor role of AAA server routing.
The real authenticated identity is often hidden inside
the EAP protocol and cannot be obtained by parsing EAP messages.

For example, RFC5216, Section 2.2 (EAP-TLS):

   Since the identity presented in the EAP-Response/Identity need not be
   related to the identity presented in the peer certificate, EAP-TLS
   implementations SHOULD NOT require that they be identical.  However,
   if they are not identical, the identity presented in the EAP-
   Response/Identity is unauthenticated information, and SHOULD NOT be
   used for access control or accounting purposes.

> construct the EAP Identity response.

Why at all should IKEv2 do something at this point?
EAP has been already started and it is EAP's responsibility
to response to Identity Request.

> also in the EAP case.

I disagree. In case of EAP IDi must not be used for PAD lookup,
and the RFC is absolutely clear about it.

> The text above in the RFC7296 is there because

The text clearly says that IDi is not used for policy lookup and control
decisions.

> request from the client at all.

You completely ignore the fact, that some EAP methods
exchange identities themselves and don't use identity,
received in response to EAP Identity request.
And that inner identity is the only authenticated identity.
Even if you manage to save extra roundtrip with all
these complications, it doesn't make IDi an authenticated
EAP identity in this case, even if it matches the EAP identity
in EAP Identity response.

> things open so different implementations can do whatever is suitable

That's why I think that ID_NULL can be used as IDi
in case of EAP - this usage doesn't contradict to IKEv2 spec.

Valery.

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 29 Jan 2015 09:20:04 +0200

> in case of EAP - this usage doesn't contradict to IKEv2 spec.

Hi Valery,

I don't see how this can be done without breaking existing 
implementations, and therefore I am unhappy with the new sentence in 
-03, "Another example is EAP authentication when the client identity in 
ID payload is not used." A responder that receives a new, unknown ID 
type should IMHO reject the exchange as syntactically malformed. Even if 
some reading of the documents might lead you to think that responders 
should be liberal in this case, I see no benefit in breaking the 
non-liberal servers by using a novel ID type here.

Thanks,
	Yaron

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 29 Jan 2015 10:46:06 +0300

Hi Yaron,

> non-liberal servers by using a novel ID type here.

The text is there because the draft doesn't restrict usage of ID_NULL
to NULL AUthentication only and we were asked to provide
some examples of such usage. I agree that current implementations
won't probably tolerate the described scenario, but I also think that we 
should allow ID_NULL to be used in some use cases that might be defined 
in the future.

We may remove this sentence that made you unhappy and replace
it with something like:

    If ID_NULL is used with other authentication methods than NULL
    Authentication, then its usage must be defined in appropriate
    document.

BTW, is another example of using ID_NULL in this para is 
acceptable to you?

Regards,
Valery.

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 29 Jan 2015 15:15:12 +0200

> BTW, is another example of using ID_NULL in this para is 

I think removing the sentence saying "Another example is EAP
authentication when the client identity in ID payload is not used."
would be good. We already have one example in previous sentence (Raw
public key) which points out why you might want to use ID_NULL with
real authentication, and we do not necessarely need second example.
And for the raw public key case, I do not think we need new document
describing how it is used with ID_NULL...

Of course we need to get the oob-pubkey draft published for that part
of text to be really useful.
-- 
[email-masked]

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 29 Jan 2015 15:37:14 +0200

> of text to be really useful.

I agree with Tero.

Thanks,
	Yaron

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 29 Jan 2015 17:35:53 +0300

>> of text to be really useful.

In conclusion, is the following text OK?

   ID_NULL is primarily intended to be used with the NULL
   Authentication, but it MAY also be used in other situations, when the
   content of Identification payload does not matter.  For example,
   ID_NULL can be used when authentication is performed via raw public
   keys and the identities are these keys themselves.  If ID_NULL is
   used with other authentication methods than NULL Authentication, then
   the details of its usage must be defined in appropriate document.

Valery.

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 29 Jan 2015 16:45:51 +0200

Fine with me.

	Yaron

---

From: Paul Wouters <[email-masked]>
Date: Thu, 29 Jan 2015 12:02:54 -0500 (EST)

>  the details of its usage must be defined in appropriate document.

Proposing some minor changes:

 	ID_NULL is primarily intended to be used with NULL Authentication but
 	could be used in other situations where the content of the Identification
 	Payload is not used. For example, ID_NULL could be used when authentication
 	is performed via raw public keys and the identities are the keys
 	themselves. These alternative uses of ID_NULL should be described in
 	their own respective documents.

Paul