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 whom it is trying to connect. So you may provide it only with PPKs for some nodes. Then the node A will send PPK_SUPPORTED only in case it is connecting to a peer, for which the node A has a PPK. This way you may deploy PPK incrementally or partially (only to some part of the network). For responder the situation is worse. At the moment it sends PPK_SUPPORTED it doesn't know whether it has a PPK for this particular initiator. So it must be preconfigured with PPKs for all possible initiators before starting to reply with PPK_SUPPORTED. > > - We also need to specify the format of the ppk_id. This isn't that > > hard, however we did want an updated revision Real Soon Now, and > > this format doesn't feel like something I want to just slap > > together.... > > Actually for both ppk_id, and the PPK value used in the calculations, > I would suggest following: > > Both the the ppk_id inside the N(PPK_IDENTITY) and the PPK > value used in the SK_d/SK_pi/SK_pr calculations are opaque > octect streams. Implementations supporting PPK, MUST support > ppk_ids having length of less than 64 octets, and MAY support > longer ppk_id values. The PPK itself MUST have length between > 16 and 64 octets. 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. 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 simplify PPK management in case a host have PPKs of different types and need to look them up in different storages. Regards, Valery. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
