Subject: [IPsec] Quantum Resistant IKEv2

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Tue, 6 Dec 2016 21:31:54 +0000

In the WG meeting in Seoul, we discussed the Quantum Resistant proposal for IKEv2, and decided to make the current draft (draft-fluhrer-qr-ikev2-03) as work item.

During the discussion, two items were raised, and I would like to hear how the wider WG feels about these two items:

-          The first item is "how exactly do we stir in the preshared key (PPK) into the keying material".  By my count, three options were on the table:

o   There is the option listed in the draft, where we modify both the KEYMAT and SKEYSEED computations; stirring it into the KEYMAT implies that the IPsec SAs are generated with QR-resistant keying material, while stirring it into the SKEYSEED implies that any child IKE SAs implies that any IKE SA (other than the initial one) also has QR-resistant keying material.  This latter was done specifically so that an implementation can have protected IKE SAs (by negotiating a child SA immediately)

o   Dan Harkins suggested that we modify only the KEYMAT.  This is a simpler option, and will continue to protect the IPsec SAs; however this implies that any data protected by the IKE SA could potentially be recovered by a Quantum Computer.

o   Valery Smyslov gave a suggestion that we instead stir in the PPK into the initial SK_d; as all keying material is generated based on that, this would also mean that IPsec SAs and any child IKE SAs are also protected.  This also means that an implementation would not need to remember the PPK after the initial negotiation.  The only downside I can see is that we would have to be a bit careful about when we update the SK_d (obviously, before we actually use it).
To me, all three strike me as reasonable ideas (unless we decide that we will need to protect the real identity data encrypted via the IKE SA; in that case, Dan's idea doesn't protect that).  Can I get opinions as to which strikes the group as the best?  Are there any fourth options that people would want to put on the table?

-          The second item is anonymity; some people were interested in preserving anonymity (however, not at the expense of excessive complexity).  One idea that was brought up was that the initial exchange would be done using pseudonyms (which would be sufficient for the responder to identity the PPK), and then once initial IKE SAs have been established (in a QR form), exchange the real identities.  My questions:

o   Would this idea of pseudonyms actually give any real identity protection?  Wouldn't that assume that several initiators use the same PPK (so they could use the same pseudonym)?  Is that the sort of thing we should be encouraging?

o   Should this be addressed in this draft, or could it be addressed in a follow-up draft?

o   If it would be addressed in a follow-up, would any hooks be required?  For example, would we want to introduce an opaque bit in a notify message to indicate this?

o   Would we be happy with always negotiating a child SA (as none of the three proposals for stirring in the PPK attempt to protect the initial IKE SA)?
My opinion is that this could be placed in a follow-up draft.

Thoughts???

---

From: Michael Richardson <[email-masked]>
Date: Wed, 07 Dec 2016 18:43:51 -0500

Scott Fluhrer (sfluhrer) <[email-masked]> wrote:
    > o There is the option listed in the draft, where we modify both the
    > KEYMAT and SKEYSEED computations; stirring it into the KEYMAT implies

I read through the three options, and I have difficulty picking.

...
    > o Valery Smyslov gave a suggestion that we instead stir in the PPK
    > into the initial SK_d; as all keying material is generated based on
    > that, this would also mean that IPsec SAs and any child IKE SAs are
    > also protected. This also means that an implementation would not need
    > to remember the PPK after the initial negotiation. The only downside I
    > can see is that we would have to be a bit careful about when we update
    > the SK_d (obviously, before we actually use it).

If we can make this work, it seems like the best, as it means we can forget
more things sooner.

    > o Would this idea of pseudonyms actually give any real identity
    > protection? Wouldn’t that assume that several initiators use the same
    > PPK (so they could use the same pseudonym)? Is that the sort of thing
    > we should be encouraging?

I need to think about this.

It only matters to "road warriors", i.e. remote access situations where the
end user can move around.  This includes many more site to site VPNs these
days due to CGN and just poor network architecture, such as the Cloud
operators' baked in NAT44.

I'm concerned that we would wind up with a new Group PSK like we had with IKEv1.

    > o Would we be happy with always negotiating a child SA (as none of the
    > three proposals for stirring in the PPK attempt to protect the initial
    > IKE SA)?

I wonder if this might be simpler and more reliable to just always do it, and
specify it up front.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Yoav Nir <[email-masked]>
Date: Thu, 8 Dec 2016 08:48:24 +0200

> On 8 Dec 2016, at 1:43, Michael Richardson <[email-masked]> wrote:
> 
> 

Me too. I’m not too worried about information in the IKE SA, so I wouldn’t disqualify Dan’t on that basis.

> If we can make this work, it seems like the best, as it means we can forget

I’m guessing this would be something along these lines:

OLD:
   {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr }
                   = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr )

NEW:
   {SK_proto_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr }
                   = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr )n

   SK_d = prf(PPK, SK_proto_d}

So assuming this works and is secure, it seems like an easy change.

> I'm concerned that we would wind up with a new Group PSK like we had with IKEv1.

Pseudonyms are not too difficult on the protocol level, but managing them makes products and configuration very difficult. So you’re giving groups of people the same pseudonym and the same PPK? How do you group people together? With non-careful grouping of users you can make it worse than exposing real names (not “ynir”, but “RND_ACCESS_GROUP”, which is more useful to an attacker). And that is the kind of exposure that we can’t fix in protocol - we’re trusting administrators to balance convenience, privacy and corporate information security. I think they’ll all choose a single PPK and single pseudonym for everybody.

> I wonder if this might be simpler and more reliable to just always do it, and

Simple, yes. Reliable, yes. Necessary? IDK

Yoav

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 8 Dec 2016 11:29:26 +0300

Hi,

OLD:

NEW:

I also thought of something like this.

 

Yes, and the simplicity was the main reason I suggested this variant.

It allows to have the only place in the code where you have to change

key derivation logic and to deal with PPK. Obviously, I vote for it.

 

I fail to understand how mandating to always negotiate Child SA helps protect anonymity.

The only place where IKEv2 peers exchange identities is currently IKE_AUTH exchange.

The current draft suggests that in case of PPK the peers should immediately initiate 

CREATE_CHILD_SA exchange and rekey the IKE SA using PPK. But CREATE_CHILD_SA

doesn’t allow to exchange identities. So, if pseudonyms were used in IKE_AUTH,

how are you going to exchange real identities? Even if we modify CREATE_CHILD_SA

to optionally include IDi & IDr, this won’t be enough, because the first CREATE_CHILD_SA

(right after IKE_AUTH is finished) will have no protection against QC (since PPK is not

used in original IKE SA and the first CREATE_CHILD_SA will be protected using

keys created during initial exchange). So, to protect identities from QC the peers

need to initiate the second CREATE_CHILD_SA (or INFORMATIONAL) exchange. 

And the peers must also somehow prove their real identities, so AUTH payloads 

must also be included, and we end up with something like full IKE_AUTH exchange...

Isn’t it too complex? 

If protecting identities is so much a concern, then we’d probably rather

go back to original draft, where PPK was used in initial exchanges

and the identities were protected by it.

So, I think that the problem of protecting anonymity cannot be easily solved

now without substantial complicating of the protocol (unless I misunderstood something

very obvious). My vote is for follow-up draft (if it happen to appear at all) or

for going back to original QR proposal. 

Regards,

Valery.

Yoav

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 8 Dec 2016 15:06:51 +0200

> If we can make this work, it seems like the best, as it means we can forget

I agree on that, and I really like the fact that we can remove PPK
from the memory immediately after the initial exchange is finished.

> I'm concerned that we would wind up with a new Group PSK like we had

The issue with Group PSK was that any client could fake to be server,
and if the next authentication in IKEv1 was normal password
authentication where password was sent from the client to the server
for verification protected by the group PSK, which meant anybody in
group could steal other peoples passwords.

Here we will be doing normal IKEv2 authentication in addition to the
PPK, so even if the PPK is shared between people, if the server and
client use proper authentication (cert + eap for exmple), then they
are not vulnerable for this kind of attacks.

My take on the proposed protocol would be same as in the
draft-fluhrer-qr-ikev2-03:

   Initiator                       Responder
   ------------------------------------------------------------------
   HDR, SK {IDi, [CERT,] [CERTREQ,]
       [IDr,] AUTH, SAi2,
       TS, TSr, N(PPK_NOTIFY)}  --->

                             <--- HDR, SK {IDr, [CERT,] AUTH,
                                      SAr2, TSi, TSr, N(PPK_NOTIFY)}

but instead of the PPK_NOTIFY to be empty, I would say that the
PPK_NOTIFY contains the opaque binary object identifying the PPK that
will be used in the exchange, i.e., PPK_ID. The actual format of the
PPK_ID is implementation dependant, and it could be static, or it
could contain some changeable parts.

Some examples could be:

	PPK_ID = [email-masked]
	       	 (unique id for each user)
	PPK_ID = \x1234
	       	 (unique id number for each user)
	PPK_ID = \x0001
		 (group id or version number of the PPK)
	PPK_ID = \x00001234\x00000001
	         (user id 0x1234 and version number 0x1 for him).
	PPK_ID = asn1 blob identifying file name, and offset in file

etc...

The client would send the PPK_ID, and server would either accept it or
not, and if server accepts PPK_ID, it will reply with its own
PPK_NOTIFY, which may contain anything (i.e., it can be used to
backchannel from server to client, for example server could send
PPK_ID saying next number to use in the list is \x0002).

For the pseudonyms, we do not really need to do anything, we can
simply say that IDi can be ID_KEY_ID and contain random opaque octet
stream identifying the user pseudonym.

Then later we can make protocol that says that we do IKEv2 SA rekey to
gain QR for the IKEv2 SA, and then we simply send CFG_SET to pseudonym
configuration attribute which indiates the next random ID_KEY_ID
object we are going to be using next time we log in...

For now we do not need to do anything yet, it is simply enough that we
do have clear way of forward in the future, and we do not limit our
options unnecessarily. 

>     > three proposals for stirring in the PPK attempt to protect the initial

If you do not want to have the child sa, just use the RFC6023.

> I wonder if this might be simpler and more reliable to just always
> do it, and specify it up front.
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 8 Dec 2016 15:20:55 +0200

Valery Smyslov writes:

> CREATE_CHILD_SA exchange and rekey the IKE SA using PPK. But
> CREATE_CHILD_SA doesn’t allow to exchange identities. So, if
> pseudonyms were used in IKE_AUTH, how are you going to exchange real
> identities?

Real IDs are never exchanged over wire. The server sees pseudonym
ID_KEY_ID \x1c747c060d209a223d1f9f51b0351b54, it looks it up from its
table and finds a mapping from there to [email-masked]. From then on
it uses [email-masked] as authenticated identifier, and verifies that
the raw public key, or shared key used to authenticate the user
actually matches the one configured to the [email-masked].

Using certificates in this case would leak out the identity anyways,
so they cannot be used, or at least transmitted over wire. Even if
using raw public keys, the actual public keys must not be sent over
wire, it needs to be taken from the configuration.

> And the peers must also somehow prove their real identities, so AUTH
> payloads must also be included, and we end up with something like
> full IKE_AUTH exchange...

This all is done in the server, i.e. instead of using the ID sent over
the wire, the server uses the ID sent over wire as handle to the
table, and fetches the real ID to be used for policy decisions and
authentication from the that table.

Then psedonym update protocol is run later, after we have done IKEv2
SA rekey to gain QR for IKEv2 SA too, and that would say update the
ID_KEY_ID from \x1c747c060d209a223d1f9f51b0351b54 to
\x7ca765c1972372cecf78184d1a628d05, and next time client comes in he
does not use the ID_KEYID of \x1c747c060d209a223d1f9f51b0351b54, but
he uses the new ID_KEY_ID \x7ca765c1972372cecf78184d1a628d05 instead.

Note, again that how those pseudonyms are generated and what kind of
format they have is outside the scope of this protocol.

Of course the pseudonum protocol most likely would need some kind of
safe guards against getting out of sync in client and server, for
example client could send 10 next pseudonyms, and server could allow
any one of them to be used.

> So, I think that the problem of protecting anonymity cannot be
> easily solved now without substantial complicating of the protocol
> (unless I misunderstood something very obvious). My vote is for
> follow-up draft (if it happen to appear at all) or

I disagree on, that but that does not matter, as we do not need to
specify it now. I am convinced that we can do it separately provided
we have a way to making IKEv2 SA also protected against QR attacks
somehow (i.e., make IKEv2 SA rekey to provide IKEv2 SA QR properties).
-- 
[email-masked]

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 8 Dec 2016 16:30:46 +0300

Hi Tero,

> Real IDs are never exchanged over wire. The server sees pseudonym

Then what is the content of IDi and IDr in IKE_AUTH in this case?

> authentication from the that table.

Again, what role the usual authentication (in IKE_AUTH) and
usual IKE Identities play in this scenario?

Regards,
Valery.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 08 Dec 2016 11:00:02 -0500

> he uses the new ID_KEY_ID \x7ca765c1972372cecf78184d1a628d05 instead.

I can buy this.
It seems independantly useful to me.

---

From: Russ Housley <[email-masked]>
Date: Thu, 8 Dec 2016 12:02:46 -0500

Scott:

> -          The first item is “how exactly do we stir in the preshared key (PPK) into the keying material”.  By my count, three options were on the table:
> To me, all three strike me as reasonable ideas (unless we decide that we will need to protect the real identity data encrypted via the IKE SA; in that case, Dan’s idea doesn’t protect that).  Can I get opinions as to which strikes the group as the best?  Are there any fourth options that people would want to put on the table?

I would like to see the preshared key used in a manner that protects the IKE SA as well as the child SA.  I have a mild preference for the third alternative over the first one.

> o   Would this idea of pseudonyms actually give any real identity protection?  Wouldn’t that assume that several initiators use the same PPK (so they could use the same pseudonym)?  Is that the sort of thing we should be encouraging?

+1.  Please do not delay the quantum resistant work while this gets sorted out.  In the past, the discussions of identity protection have not been short.

Russ

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Thu, 8 Dec 2016 21:26:31 +0000

From: IPsec [mailto:[email-masked]] On Behalf Of Russ Housley
Sent: Thursday, December 08, 2016 12:03 PM
To: Scott Fluhrer (sfluhrer)
Cc: IETF IPsec
Subject: Re: [IPsec] Quantum Resistant IKEv2

Scott:

Actually, in terms of what IPsec/IKE traffic is immune from recovery from an adversary with a Quantum Computer, the first and third options are identical.

In both cases, the traffic that is protected by the initial IKE SA can be recovered; that's because that traffic is encrypted by the initial SK_ei, SK_er keys, and those would be recoverable.  In both cases, any IPsec traffic and any traffic protected by a child IKE SA would be safe (in the first option, because we deliberately stir in the ppk when we generate them; in the third option, because we stir in the ppk to form the updated SK_d, and then we use that SK_d to generate those keys).

Russ

---

From: Russ Housley <[email-masked]>
Date: Thu, 8 Dec 2016 17:02:24 -0500

> Actually, in terms of what IPsec/IKE traffic is immune from recovery from an adversary with a Quantum Computer, the first and third options are identical.

I recognize that.

I would like to see the preshared key used in a manner that protects the IKE SA as well as the child SA, and between the two alternatives that offer that, I have a mild preference for the third alternative.

Russ

---

From: "Graham Bartlett (grbartle)" <[email-masked]>
Date: Fri, 9 Dec 2016 23:12:10 +0000

Hi

I too am in favour of Valery¹s option. The rational being, if an attacker
can recover the SKEYSEED using a QC, I would assume that they can then
inject traffic into the IKEv2 SA, examples being to use configuration
payload to manipulate routing, rekey with amended traffic selector etc..
Simply put I feel we need to protect both IPsec SAs and child IKEv2 SAs.

For users concerned against active attacks, the IKEv2 SA should rekey
directly after IKE_AUTH and the new child IKEv2 SA be used for configuration
payload. This should be called out in the draft, but shouldn¹t be mandatory.

cheers

From:  IPsec <[email-masked]> on behalf of Russ Housley
<[email-masked]>
Date:  Thursday, 8 December 2016 22:02
To:  "Scott Fluhrer (sfluhrer)" <[email-masked]>
Cc:  IETF IPsec <[email-masked]>
Subject:  Re: [IPsec] Quantum Resistant IKEv2

>> o   Valery Smyslov gave a suggestion that we instead stir in the PPK into the
>> initial SK_d; as all keying material is generated based on that, this would
>> also mean that IPsec SAs and any child IKE SAs are also protected.  This also
>> means that an implementation would not need to remember the PPK after the
>> initial negotiation.  The only downside I can see is that we would have to be
>> a bit careful about when we update the SK_d (obviously, before we actually
>> use it).
>> To me, all three strike me as reasonable ideas (unless we decide that we will
>> need to protect the real identity data encrypted via the IKE SA; in that
>> case, Dan¹s idea doesn¹t protect that).  Can I get opinions as to which
>> strikes the group as the best?  Are there any fourth options that people
>> would want to put on the table?
>>  
>> I would like to see the preshared key used in a manner that protects the IKE
>> SA as well as the child SA.  I have a mild preference for the third
>> alternative over the first one.
>  
> Actually, in terms of what IPsec/IKE traffic is immune from recovery from an
> adversary with a Quantum Computer, the first and third options are identical.

I recognize that.

I would like to see the preshared key used in a manner that protects the IKE
SA as well as the child SA, and between the two alternatives that offer
that, I have a mild preference for the third alternative.

Russ

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 29 Dec 2016 14:43:19 +0200

> Then what is the content of IDi and IDr in IKE_AUTH in this case?

As I said the IDi would be ID_KEY_D with value of
\x1c747c060d209a223d1f9f51b0351b54. IDr would most likely be the
normal server side identity, as hiding server identity is usually not
useful as server must have static IP so clients can know where to
connect.

If server side identity protection is also needed, then server side
IDr would also be similar pseudonym, but that would require server to
keep track of which IDr was given to which client, and pick suitable
IDr based on the IDi coming in.

> usual IKE Identities play in this scenario?

They would play their normal role, i.e. they would be used to
authenticate the connection. The only difference is that the IDi on
the wire would not be the real identity but the a random pseudonym,
and that pseudonym is then used by the server to fetch the real
identity which would then be used for policy purposes. To provide full
identity protection, even the server should not use any long term
identity like [email-masked], but instead just use some kind of user
id and map that user id to the actual policy.

I.e., the lookup would go like follows:

IDi = ID_KEY_ID \x1c747c060d209a223d1f9f51b0351b54

  -> In server look that id from the known pseudonyms, find entry
     saying:

     Pseudonym_ID = \x1c747c060d209a223d1f9f51b0351b54
     User_ID = KeyId(\x1234)

  -> Use User_ID to search PAD for entry to verify authentication and
     find the related SPD

Then when the user changes their pseudonym using the protocol defined
later the first list of known pseudonyms would be updated to say:

     Pseudonym_ID = \x056f32ee5cf49404607e368bd8d3f2af
     User_ID = KeyId(\x1234)

where the Pseudonym_ID is new random pseudonym to be used after that
for future exchanges. The User_ID stays same, but it is just internal
information inside the server, and is never transmitted over the wire.
Of course the User_ID could also be RFC822([email-masked]) instead of
that kind of random number, but then hacking in to the server could
reveal the real user identities for the clients and their next
pseudonyms, so that would be bad idea if full protection is needed.

Server does not really need to know who is in the other end, he just
needs to know how the other end is going to authenticate himself
(i.e., which PAD entry to use), and what kind of policy is allowed for
that user (i.e., which SPD entries are used). 
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 29 Dec 2016 15:08:57 +0200

Scott Fluhrer (sfluhrer) writes:
> o   There is the option listed in the draft, where we modify both the KEYMAT
> and SKEYSEED computations; stirring it into the KEYMAT implies that the IPsec
> SAs are generated with QR-resistant keying material, while stirring it into
> the SKEYSEED implies that any child IKE SAs implies that any IKE SA (other
> than the initial one) also has QR-resistant keying material.  This latter was
> done specifically so that an implementation can have protected IKE SAs (by
> negotiating a child SA immediately)
> 
> o   Dan Harkins suggested that we modify only the KEYMAT.  This is a simpler
> option, and will continue to protect the IPsec SAs; however this implies that
> any data protected by the IKE SA could potentially be recovered by a Quantum
> Computer.

This has the issue that differences in the PPK will not be detected,
i.e., if PPKs are mismatched because of configuration error, we do get
IKEv2 SA up and running, and we create IPsec Child SAs without errors,
but then all traffic in IPsec SA will simply be dropped as the keying
material is wrong.

Also this does not protect IKE SAs at all.

> a bit careful about when we update the SK_d (obviously, before we actually use
> it).

This would provide protection for the IPsec SAs and Child IKE SA (i.e.
IKE SAs after rekey). It still has same issue that we do not get
verification that PPKs are same.

> need to protect the real identity data encrypted via the IKE SA; in that case,
> Dan’s idea doesn’t protect that).  Can I get opinions as to which strikes the
> group as the best?  Are there any fourth options that people would want to put
> on the table?

I would propose that we add PPK to both SK_d and SK_pi and SK_pr.

SK_d provides quantum resistance for the IPsec SAs and Child IKE SAs.
The SK_pi and SK_pr provides key verification, meaning that incorrect
PPKs will result AUTHENTICATION_FAILURE notification, instead of just
wrong keys.

SK_pi and SK_pr as used to MAC the ID payloads of the peers, and if we
mix PPK in there that might also provide some resistance against
quantum computers even when the attackers can break RSA. I.e., it does
not matter that they can generate valid signatures if they do not know
what they are supposed to sign.

> In both cases, the traffic that is protected by the initial IKE SA can be
> recovered; that’s because that traffic is encrypted by the initial SK_ei,
> SK_er keys, and those would be recoverable.

The important thing is to keep the SK_e*/SK_a* so they do not depend
on the PPK. The problem with them is that if they depend on the PPK,
then we cannot see contents of the packet before we need PPK, so PPK
negotiation needs to happen in clear before IKE_AUTH.

SK_d, SK_pi, and SK_pr all benefit from PPK, and they can and should
use get PPK mixed in to them.

I.e., define

SK_d' = prf(PPK, SK_d)
SK_pi' = prf(PPK, SK_pi)
SK_pr' = prf(PPK, SK_pr)

and change uses of SK_d, SK_pi and SK_pr to use those.

> -          The second item is anonymity; some people were interested in
> preserving anonymity (however, not at the expense of excessive complexity). 
> One idea that was brought up was that the initial exchange would be done using
> pseudonyms (which would be sufficient for the responder to identity the PPK),
> and then once initial IKE SAs have been established (in a QR form), exchange
> the real identities.  My questions:
> 
> o   Would this idea of pseudonyms actually give any real identity protection? 
> Wouldn’t that assume that several initiators use the same PPK (so they could
> use the same pseudonym)?  Is that the sort of thing we should be encouraging?
> 

I think we can do that in follow up draft, and I so there is no need
to complicate things in this draft.

> o   If it would be addressed in a follow-up, would any hooks be required?  For
> example, would we want to introduce an opaque bit in a notify message to
> indicate this?

As I see the pseudonym support, we only need a way to get quantum
resistant IKE SA, and Child IKE SA is fine for that, so we already
have all the features need.
-- 
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Thu, 29 Dec 2016 11:47:23 -0500

Tero Kivinen <[email-masked]> wrote:
    > \x1c747c060d209a223d1f9f51b0351b54. IDr would most likely be the normal
    > server side identity, as hiding server identity is usually not useful
    > as server must have static IP so clients can know where to connect.

While I think that the client IDs might be a local implementation issue,
if we go down this route, I'd like us the standardize the representation of
how they IDs are presented, such that, in theory, a user could type them
in.  Or, come up with a JSON format for presenting the ID+gateway information.
[ I know that many vertically integrated "solutions" have single file solutions
 like the ".pcf" file from Cisco. I'm suggesting standardizing such a thing]

The client ID could well be the real client ID encrypted by the server with a
locally kept key.  That would eliminate the database lookup for some systems,
but that might be important.  Again: a local implementation issue.

    > If server side identity protection is also needed, then server side IDr
    > would also be similar pseudonym, but that would require server to keep
    > track of which IDr was given to which client, and pick suitable IDr
    > based on the IDi coming in.

Wow, this is indeed complex, yet I actually think this might matter to
systems that have the various (not-standardardized, alas), ad-hoc VPN
mechanisms, such that gateways without static IPs can be found.

I think that we can leave it out of scope for now, but perhaps we don't
really need to say a lot about it, except what you just wrote.

    > authenticate the connection. The only difference is that the IDi on the
    > wire would not be the real identity but the a random pseudonym, and
    > that pseudonym is then used by the server to fetch the real identity
    > which would then be used for policy purposes. To provide full identity
    > protection, even the server should not use any long term identity like
    > [email-masked], but instead just use some kind of user id and map that
    > user id to the actual policy.

Previously, in the typical large scale road warrior case, where a client has
a certificate signed by a private CA, and the policy is essentially that any
client with a valid certificate (modified by OCSP and CRLs, etc.), which is
also provided in-band in a CERT payload, and any such client can connect
and gets the same policy, I wonder if we can somehow dispense with the IDi
completely, or use a constant value.

Now, with a Quantum Resistant mechnanism, we are mixing per-host-pair PSK into the
resulting IPsec (and perhaps IKE PARENT SA) sessions keys, but I'm unclear if
we'd still be using RSA/ECDSA/EdDSA certificates at all.  I know that there
are QM resistant asymmetric mechanism envisioned, but I know so little about them.

    > IDi = ID_KEY_ID \x1c747c060d209a223d1f9f51b0351b54

I think that this is a random string you made up, not a constant value.

    >      Pseudonym_ID = \x056f32ee5cf49404607e368bd8d3f2af User_ID =
    > KeyId(\x1234)

    > pseudonyms, so that would be bad idea if full protection is needed.

Is it reasonable to describe this Pseudonum update mechanism seperately, or
do you think it is too heavily connected to the quantum resistance

---

From: Michael Richardson <[email-masked]>
Date: Thu, 29 Dec 2016 11:51:28 -0500

Tero Kivinen <[email-masked]> wrote:
    >> that the IPsec SAs are generated with QR-resistant keying material,
    >> while stirring it into the SKEYSEED implies that any child IKE SAs
    >> implies that any IKE SA (other than the initial one) also has
    >> QR-resistant keying material.  This latter was done specifically so
    >> that an implementation can have protected IKE SAs (by negotiating a
    >> child SA immediately)
    >>
    >> o Dan Harkins suggested that we modify only the KEYMAT.  This is a
    >> simpler option, and will continue to protect the IPsec SAs; however
    >> this implies that any data protected by the IKE SA could potentially
    >> be recovered by a Quantum Computer.

    > but then all traffic in IPsec SA will simply be dropped as the keying

I think that this is a *HUGE* user configuration issue.
It means that the QM resistance will be turned off first thing whenever there
is a problem.

    > PPKs will result AUTHENTICATION_FAILURE notification, instead of just

Would it be reasonable to create some token/nonce from something before the
PPK is mixed in such that we could recognize the different AUTH FAILUREs,
or does that create too much of an oracle for testing PPKs?

    >> In both cases, the traffic that is protected by the initial IKE SA can
    >> be recovered; that’s because that traffic is encrypted by the initial
    >> SK_ei, SK_er keys, and those would be recoverable.

    > The important thing is to keep the SK_e*/SK_a* so they do not depend on
    > the PPK. The problem with them is that if they depend on the PPK, then
    > we cannot see contents of the packet before we need PPK, so PPK

Good.
(I haven't spent the time to understand what the changes are to the math, and
it's been 10 years since I wrote that code, so please consider me a very
clueful end user in these discussions)

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 30 Dec 2016 16:33:38 +0200

> really need to say a lot about it, except what you just wrote.

Yep. Leaving it out of scope for that future draft is fine for me...

> are QM resistant asymmetric mechanism envisioned, but I know so little about them.

If you really care about the identity protection, you cannot transmit
certificates or raw public keys in-band, as those will immediately
reveal your identity (or at least the fact that you are same user than
last time). You might even reveal this to passive attacker, who might
be able to know that this is [email-masked] and this other one is
[email-masked] by just looking that the length of
the IKE_AUTH payload...

So with identity protection you want to keep all that authentication
information local, and when the server receives the random pseudonym,
it can map that to the PAD entry and PAD entry then has either
shared-key, certificate or raw public key associated with it and that
is used for autentication. 

> I think that this is a random string you made up, not a constant value.

Yep, and it can be changed at any time by using some mechanism we have
not yet defined, but which will be run over the IKE SA after we have
made it so that it gains resistance against quantum attackers.

> do you think it is too heavily connected to the quantum resistance

I do not think it is in any way connected to the quantum resistance,
so I think it is better to describe it as separate document. Note,
that we even could simply make simple IPsec SA to the web server in
the SGW and then use the rest API over http over that IPsec SA and
change the pseudonym in that way. The way I described was just one way
we can do it, and the actual draft that will define this protocol,
needs to decide how it is actually going to work.
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 30 Dec 2016 16:37:54 +0200

> It means that the QM resistance will be turned off first thing whenever there

That is why I think it is important that we do detect the failures
correctly. 

> or does that create too much of an oracle for testing PPKs?

I think it is better to keep the AUTHENTICATION_FAILURE to mean both,
i.e., not provide an oracle.
-- 
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Sat, 31 Dec 2016 22:17:02 -0500

>> > SK_d provides quantum resistance for the IPsec SAs and Child IKE
    >> SAs.  > The SK_pi and SK_pr provides key verification, meaning that
    >> incorrect > PPKs will result AUTHENTICATION_FAILURE notification,
    >> instead of just > wrong keys.
    >> 
    >> Would it be reasonable to create some token/nonce from something
    >> before the PPK is mixed in such that we could recognize the different
    >> AUTH FAILUREs, or does that create too much of an oracle for testing
    >> PPKs?

    > i.e., not provide an oracle.

okay, but can we determine the mismatch enough to log it?