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 initiator decides
I did not even require that. I said you need to provide all PPKs for
that one node at the same time. Or at least that I was trying to say.
I can now see that my text was bit unclear.
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.
Then you can do same thing for other nodes one by one cases. I.e., you
do not need to update the whole network at once, but you need to
provide full configuration for the one device at the same time.
After node A is configure with all PPKs, it will start sending
N(PPK_SUPPORTED) notifications. If it connects to other node which has
been reconfigured, then that node will also respond with
N(PPK_SUPPORTED) and they will use PPK. If it connects to node which
has not yet been reconfigured, then the node will not send
N(PPK_SUPPORTED) and PPK will be disabled.
> which PPK to use (and whether to use a PPK at all; the obvious idea
> would be 'if the initiator doesn't' send a PPK_NOTIFY message, no
> PPK is in use'). With this, the upgrade procedure becomes:
> Step 1: configure the PPKs and the id's on each peer. This
> will allow each side to use this protocol if it was the responder,
> but not insist on it if it's the initiator
> Step 2: for each peer, configure which PPK to use (probably
> based on peer identity), and make its use optional. That is, when
> we're initiating, we'll now use the PPK; however, if we're the
> responder, we'll use the PPK if the initiator asks, but not reject
> the SA if he doesn't
> Step 3: for each peer, make the use of PPK mandatory (and so
> if we're the responder, when we get the initiator's identity, we see
> that the use of PPK was required; if we didn't get PK_NOTIFY, we'll
> reject the request)
> Again, we don't need to upgrade the entire network at once; we
> could incrementally do this by peer-to-peer connection...
Yes. That was there already in my proposal (but text was bit unclear).
> Minus:
> - It makes roll out possible, but (as above) it's a 3 step affair,
> rather than the previous 2 step.
Actually it is not 3 step affair, it is one step affair for each node.
Step 1) Install configuration having PPKs for node A.
Repeat step 1 on all other nodes, at will. Immediately when both pairs
of the connections have been reconfigured they will start using PPK.
If you want to change the configuration so that PPK is required then
that is second reconfiguration for the whole network, but this is not
something that needs to be done, as properly configured systems will
always use PPK if both ends have been reconfigured to have PPKs,
unless initiator explictly disables it for this connection (i.e., for
example for debugging purposes).
Only reason why you want to enforce the PPKs to be used always, is
when you know that your attacker can already break Diffie-Hellman on
real time, and can also break your authentication method in real time.
Then you need to use PPK to protect the authentication, as if attacker
is able to break the authentication in real time, then it can also
modify the packets on the wire by removing the N(PPK_IDENTITY) or
N(PPK_SUPPORTED) notifies and disabled PPK. If the authentication
(and Diffie-Hellman) cannot be broken in real time then authentiation
will prevent attacker disabling PPK.
> - 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.
When both ppk_id and PPK are represented in the user interface
the user interface MUST allow any octet stream to be
represented (i.e., it must not assume that it can safely print
the ppk or ppk_id to screen without any encoding them to
printable characters), and MUST provide a way to input ppk_id
and PPK in base64-encoded ascii string. User interface MAY
allow other formats too, like plain ASCII, UTF-8, or
hex-string. This requirement is only for the user interface,
if the API is used to configure the ppk_id and PPK, then
direct binary representation can be used and no base64 version
of the API is needed.
Note, that both ppk_id and PPK are octet streams, they are not
assumed to be any kind of strings, thus they do not have
associated character sets, and while UTF-8 strings are valid
values for them, there is no character set specific processing
for them.
> Also, with the above tweak, I'm not certain what value the
> PPK_SUPPORTED notify brings to the table; you had it for the
> responder to signal to the initiator that it's been upgraded; the
> above protocol has the initiator expecting whether specific
> responders are upgraded or not. It might make debugging a bit
> easier...
Yes. It will allow setup to be done using 1 phase protocol instead of
3 phases. I.e. as N(PPK_SUPPORTED) tells to both ends whether they
have been configured with the needed information to do PPK, and after
that they will know they can use PPK if they like.
This is also the way we have done things with other extensions, i.e.,
exchange notification in the IKE_SA_INIT for supported features.
> Another thing to consider: what if we're the responder, and the
> initiator uses a PPK (which we have), but not the PPK we would have
> used if we're the initiator. I believe that we want to accept this
> (even if our PPK is marked as mandatory); would that lead to any
> potential problems?
I would say it depends on the PPK. If we use one-time-use PPKs, then
we will reject PPKs we know have already been used earlier. If we are
doing PPK rotation weekly, and other end moves to next PPK earlier
than we would have, we can allow that, as there most likely are reason
for that and this was caused by the adminstrator doing something. For
example the previous PPK was somehow compromized or lost, and the
other peer wants to move the the next one because of that.
--
[email protected]
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
