Re: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing

Scott Fluhrer (sfluhrer) writes: > I've been pondering another question, and I think I'll bring it up > before finalizing the next version of the draft. > > After the WG meeting, we (Tero and myself) met in the hallway and > had a little chat. One of the things that I took away from it (and >

Re: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing

Hi Scott, > I've been pondering another question, and I think I'll bring it up before > finalizing the next version of the > draft. > > After the WG meeting, we (Tero and myself) met in the hallway and had a > little chat. One of the things > that I took away from it (and please correct me if

Re: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing

> -Original Message- > From: Paul Wouters [mailto:p...@nohats.ca] > Sent: Wednesday, April 12, 2017 9:48 PM > To: Scott Fluhrer (sfluhrer) > Cc: Tero Kivinen; ipsec@ietf.org > Subject: Re: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing > > On Wed, 12

Re: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing

that into the > draft... > >> -Original Message- >> From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Paul Wouters >> Sent: Monday, April 10, 2017 12:54 PM >> To: Valery Smyslov >> Cc: ipsec@ietf.org WG >> Subject: Re: [IPsec] Quantum Res

Re: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing

, I'll put that into the draft... > -Original Message- > From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Paul Wouters > Sent: Monday, April 10, 2017 12:54 PM > To: Valery Smyslov > Cc: ipsec@ietf.org WG > Subject: Re: [IPsec] Quantum Resistance SK_d, SK_pi, SK_p

Re: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing

On Mon, 10 Apr 2017, Valery Smyslov wrote: I think that it's worth to add an indication of the type of PPK_ID. I.e. the PPK_ID should consist of two fields - PPK_ID type (16 bits, managed by IANA) and PPK_ID data. That would make PPK management a bit easier - the responder would know where to

Re: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing

Wednesday, April 05, 2017 3:30 PM > To: 'Tero Kivinen' > Cc: ipsec@ietf.org > Subject: RE: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing > > Ok, I now see what part of your idea I was (sort of) trying to work around. > To > make it clear to everyone, I'll spel

Re: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing

Michael Richardson writes: > > Tero Kivinen wrote: > > Scott Fluhrer (sfluhrer) writes: > >> Going through this suggestion (and tweaking it a bit): > >> > >> Pluses: - I believe it can be made a bit more flexible than you make > >> it out; it don't believe

Re: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing

Tero Kivinen wrote: > Scott Fluhrer (sfluhrer) writes: >> Going through this suggestion (and tweaking it a bit): >> >> Pluses: - I believe it can be made a bit more flexible than you make >> it out; it don't believe that you actually need to update every node

Re: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing

Hi Paul, > >> For the 3rd option the ppk_id is constructed using the PPK > >> itself and a session parameters, e.g. ppk_id = prf(PPK, Ni | Nr). > >> This would allow the responder to check whether PPK is correct > >> before verifying AUTH payload. > >> > >> In general, having a type value would

Re: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing

On Thu, 6 Apr 2017, Tero Kivinen wrote: For the 3rd option the ppk_id is constructed using the PPK itself and a session parameters, e.g. ppk_id = prf(PPK, Ni | Nr). This would allow the responder to check whether PPK is correct before verifying AUTH payload. In general, having a type value

Re: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing

Scott Fluhrer (sfluhrer) wrote: > With your idea, there are three steps (and so the admin would update > each node in the network twice): > - Step 0 is "never use PPKs"; we're running the standard IKE protocol. > - Step 1 is "if we're the initiator, then use

Re: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing

> > I'd rather add a type field to ppk_id. So the ppk_id is constructed > > of 2 fields: type and value. Types could be: > > 1. raw id > > 2. OTF file offset > > 3. PPK dependent id > > ... > > > > For the 3rd option the ppk_id is constructed using the PPK > > itself and a session parameters, e.g.

Re: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing

Valery Smyslov writes: > Hi Tero, > > > I.e., when you configure node A for PPK use, you need to give node A > > all the PPKs for all peers it has. I.e., the configuration loaded on > > the node A needs to provide all PPKs it will need. > > If node A is mostly an initiator (e.g. a remote access

Re: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing

Scott Fluhrer (sfluhrer) writes: > With your idea, there are three steps (and so the admin would update > each node in the network twice): > > - Step 0 is "never use PPKs"; we're running the standard IKE protocol. > - Step 1 is "if we're the initiator, then use PPKs if the responder >

Re: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing

Hi Scott, > The issue I was pondering was "what if the admin wants to update only part of > their network (say, as a > test)?". As I understood your proposal, the PPK_SUPPORT notify was always on > if any PPKs were > configured; indeed, from a responder side, it has to be that (because the >

Re: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing

Hi Tero, > I.e., when you configure node A for PPK use, you need to give node A > all the PPKs for all peers it has. I.e., the configuration loaded on > the node A needs to provide all PPKs it will need. If node A is mostly an initiator (e.g. a remote access client), then it knows beforehand to

Re: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing

Hi, > > > The NULL authentication (RFC7619) is logically incompatible with this > > > (it being opportunistic and this requiring configuration), so I think > > > we can say this will not be used with it. Or we can just say that can > > > be used, and SK_pi are used as specified here and in the

Re: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing

Ok, I now see what part of your idea I was (sort of) trying to work around. To make it clear to everyone, I'll spell out the problem we're trying to address, and how your idea (with a slight addition on my part) could address it. What we're talking about is "how would someone take a network

Re: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing

On Wed, 5 Apr 2017, Tero Kivinen wrote: This is vulnerable to a DOS attack though. The attacker once inserts themselves to get IDi. Then they connect to the server often enough with increased offsets to fail authentication, depleting the one-time-pad file for the real user, who presumbly then

Re: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing

Scott Fluhrer (sfluhrer) writes: > Going through this suggestion (and tweaking it a bit): > > Pluses: > - I believe it can be made a bit more flexible than you make it out; > it don't believe that you actually need to update every node with > every PPK at the start. With this protocol, the

Re: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing

Paul Wouters writes: > On Tue, 4 Apr 2017, Tero Kivinen wrote: > > > N(PPK_SUPPORTED) --> > > > For example if the PPKs are taken from the 1GB one-time-pad file > > shared by the peers (one file per user), then the ppk_id could simply > > be 32-bit offset to the file, and the external PPK

Re: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing

ipsec@ietf.org > Subject: RE: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing > > [Not wearing any hats] > > Scott Fluhrer (sfluhrer) writes: > > - Move the notifies to the prior messages (that is, in the clear). > > If we do this, then by the time we derive keys, w

Re: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing

On Tue, 4 Apr 2017, Tero Kivinen wrote: N(PPK_SUPPORTED) --> For example if the PPKs are taken from the 1GB one-time-pad file shared by the peers (one file per user), then the ppk_id could simply be 32-bit offset to the file, and the external PPK management module would keep track

Re: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing

Hi Tero, > > I think that if SK_pi and SK_pr are modified, then some information > > should be given to the user to help distinguish PPK errors from > > signature errors. For example, the Initiator can include something like > > > > N(PPK_INDICATOR) = prf(PPK, Ni | Nr | 0) > > > > into the

Re: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing

[Not wearing any hats] Scott Fluhrer (sfluhrer) writes: > - Move the notifies to the prior messages (that is, in the clear). > If we do this, then by the time we derive keys, we know whether > we're using a PPK (even if the responder doesn't know which one it > is until it hears the initiator's

Re: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing

Valery Smyslov writes: > > Modifying the SK_pi, and SK_pr will mean that if the PPK is wrong the > > IKEv2 authentication will fail, and we will get exactly same failure > > for wrong PPK than we do with wrong shared key or digital signature > > failures. This means that attacker do not gain any

Re: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing

Hi Scott, > I started editting the draft to incorporate this change, and I ran into a > conflict with another part of the > protocol: incremental rollout. I'd like some quick advice about how to deal > with the conflict. > > Here's the feature it's in conflict with: in order to support

Re: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing

Hi Paul Would a downgrade attack be possible if the PPK notify is included in the authentication material ? cheers On 03/04/2017, 18:21, "IPsec on behalf of Paul Wouters" wrote: I would think this is the obvious solution. I would not

Re: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing

On Mon, 3 Apr 2017, Scott Fluhrer (sfluhrer) wrote: Some obvious ways to address this: - Move the notifies to the prior messages (that is, in the clear). If we do this, then by the time we derive keys, we know whether we're using a PPK (even if the responder doesn't know which one it is

Re: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing

. Opinions? Does any other options come to mind? > -Original Message- > From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Tero Kivinen > Sent: Wednesday, March 29, 2017 7:11 PM > To: ipsec@ietf.org > Subject: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing

[IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing

So I have proposed earlier that we should mix the ppk to SK_d, SK_pi, and SK_pr, i.e., something like this: SKEYSEED = prf(Ni | Nr, g^ir) {SK_d' | SK_ai | SK_ar | SK_ei | SK_er | SK_pi' | SK_pr'} = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr) If no