If a challenge response and session ID is going to be used, the nonce
need not be carried after the session-id is negociated.
The purpose of a nonce is to provide a challenge which the other end
must encrypt and send back using a shared key or its private half of a
public/private key pair. The nonce in both directions plus a session
key must be exchanged and then after that the session key is used. To
prevent replay, the session key and a monotonically increasing
sequence number must be exchanged for subsequent packets.
In pictures:
session + challenge1 ->
<- session + response1 + challenge2
session + response2 ->
where:
response1 = encrypt(session + challenge1)
response2 = encrypt(session + challenge2)
If you are going to keep that sort of method, then it needs to be used
correctly. Only the session ID is needed after negociation.
It would be better to exchange a session key rather than just a
session ID. The reason to do this is so as not to use the same
session key over a long period of time and to use the shared or
public/private keys infrequently to provide very little data on which
to try to reverse engineer the keys.
I don't have strong feeling about whether this type of session ID
should be used or whether the monotonicly increasing reboot count
would be sufficient. I have some concerns about a CPU card going down
or entire router catching fire and being replaced and not knowing what
the reboot count was on the old CPU. The challenge/response has no
requirement for a monotonically increasing reboot count variable.
This may be a call for OSPF but KARP buy-in
IMHO this conversation should be directed to either OSPF or KARP for
now and not both but I cross posted since Manav cross posted a request
to consider the security mechanisms in this draft. OTOH, this sort of
session key negociation could be generic to other protocols (and quite
frankly I borrowed the idea from the well documented kerberos tgt
exchange and other challenge reponse use).
Curtis
_______________________________________________
OSPF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ospf
