Re: [IPsec] draft-fluhrer-qr-ikev2 AUTH issue

["Valery Smyslov" <[e-mail]>]

Hi Panos,

> Valery,
> It is a good idea. A new optional notification that includes the auth_data as it would be calculated without the
> PPK would work. With that, the corner case of ' PPK_id configured on initiator but missing on the responder' is
> addressed. There is an additional cost of the extra notification message for every initiator that has no-
> mandatory ppk configured for the responder. 

Yes, and there is also an extra cost for initiator of performing AUTH calculation (e.g. digital signature)
twice - one with SK_p' and the other with SK_p. Good news are is that it is 
a) is performed by initiator only, so there is no risk of DoS attack on responder 
b) is needed only if initiator is configured in "permissive" mode - when its policy allows both PPK and non-PPK 
    SAs with the particular responder

> In the worst case scenario the responder would need to go
> through looking up the PPK_id and if that fails then authenticate the auth_data. Even though it is slightly
> more work for the responder, I don't consider that heavy processing that would introduce attack concerns.

Exactly.

> My concerns is that we might be making it too complicated by potentially introducing two separate SK_p's.
> From an ops perspective, if we stated the rule that when we want to go postquantum a PPK should be
> populated on the responder first as Graham and others suggested, then the extra complication of a new
> notification can be avoided. Violation of that rule would lead to IKE_AUTH failure for that initiator only.

In general I think that if protocol allows more flexible operational conditions, then it is a good thing.
If we add this feature, then it will be completely optional for both initiator and responder
(neither initiator is required to send NO_PPK_AUTH, nor responder is required to understand it).
So, if people strictly follow transition plan, then there is no much need in this feature.
However, I suspect that in fields some folks may find these rules too restrictive under some circumstances.
So we can add a bit more flexibility in the protocol for those folks for a relatively low cost. 

Regards,
Valery.

> Vukasin,
> Any thoughts from an implementer's standpoint?
> 
> Panos
> 
> 
> -----Original Message-----
> From: IPsec [mailto:[e-mail]] On Behalf Of Valery Smyslov
> Sent: Monday, August 21, 2017 10:25 AM
> To: Scott Fluhrer (sfluhrer) <[e-mail]>; 'Paul Wouters' <[e-mail]>; [e-mail]
> Cc: 'Vukasin Karadzic' <[e-mail]>
> Subject: Re: [IPsec] draft-fluhrer-qr-ikev2 AUTH issue
> 
> Hi Scott,
> 
> > > then it has to flip a coin on whether or not to send the PPK_SUPPORT
> > > notify and if it guessed wrong, the AUTH payload on the initiator
> > > will be wrong. Sending the notify commits to using a PPK because the
> > > initiator uses it as input to the AUTH payload.
> 
> [...]
> 
> > > One way of solving this could be to allow PPK_SUPPORT to have some
> > > notify data, which could for instance be a hash of the
> > > connection/group name used by the responder.
> > > Another option is to use the PPK as one of the inputs to some hash
> > > algorithm as PPK_SUPPORT data, so the responder can go through its
> > > list of PPKs to match it back to a connection/group. But we would
> > > need to be sure that this does not open up the PPK to attacks
> > > (classic and
> > > quantum)
> >
> > That's what we did in our original proposal (actually, it was a
> > function of the PPK itself).  The problems with that were:
> >
> > - If we made it a nondeterministic function (that is, include a
> > randomizer), then the server had to do a linear scan over all their known PPKs to find the matching one.
> >
> > - If we made it a deterministic function, then someone listening in
> > can trivially determine when we're reusing the same PPK
> >
> > (There's also a minor issue of "which hash function to use"; we haven't negotiated any at this time).
> >
> > A linear scan over possibly 10,000 PPKs was considered unacceptable.
> > One of our proposals even allowed the server to specify the trade-off between the above two; that was
> considered too complex.
> >
> > I'm not thrilled with Tero's answer of "lets be careful about the
> > order we upgrade things in complex networks", but I don't know how to
> > better solve it without adding lots of complexity to the protocol, potential anonymity leaks or requiring
> significant computation on the server side.
> 
> One (relatively) simple solution would be the following.
> 
> If initiator is configured with PPK, but at the same time its policy marks using PPK as optional, then the
> initiator can send two authenticators - one using SK_pi' and the other using SK_pi (where SK_pi = prf(PPK,
> SK_pi')). The one, computed using SK_pi (where PPK is involved) is placed in AUTH payload, and the other,
> computed using SK_pi' (without PPK) is placed in a new optional status notification NO_PPK_AUTH.
> 
>    Initiator                       Responder
>    ------------------------------------------------------------------
>    HDR, SK {IDi, [CERT,] [CERTREQ,]
>        [IDr,] AUTH, SAi2, TSi, TSr,
>        N(PPK_IDENTITY)(PPK_id),
>       [N(NO_PPK_AUTH)(auth_data)] }  --->
> 
> When responder receives this message and cannot find the corresponding PPK based on PPK_id and is
> configured to allow PPK-less SA, it can still authenticate initiator by using the content of NO_PPK_AUTH.
> In this case the Responder replies with the IKE_AUTH response lacking PPK_IDENTITY to let the initiator know
> that AUTH payload is computed as per RFC7296 (using SK_pr', i.e. without using PPK).
> 
> <---   HDR, SK {IDr, [CERT,]
>        AUTH, SAr2, TSi, TSr}
> 
> If the responder has the corresponding PPK, then it computes its AUTH payload using SK_pr and includes
> PPK_IDENTITY notification:
> 
> <---   HDR, SK {IDr, [CERT,]
>        AUTH, SAr2, TSi, TSr,
>        N(PPK_IDENTITY)(PPK_id)}
> 
> This solution allows peers to communicate in different settings and to enforce their own policy.
> For instance, if the initiator is configured to always use PPK, it won't include NO_PPK_AUTH at all. If responder
> is configured to always use PPK, it will just ignore NO_PPK_AUTH and return AUTHENTICATION_FAILED in case
> the proper PPK is not found.
> 
> Regards,
> Valery.
> 
> 
> _______________________________________________
> IPsec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ipsec