Michael Richardson writes:
> > 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.
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.
> > 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.
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 protected]
(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.
> > 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)?
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 protected]
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
