[OSPF] draft-bhatia-karp-ospf-ip-layer-protection-03.txt

[Curtis Villamizar <[e-mail]>]

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