[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ms-ospf
Subject:    Re: ospfIfAuthKey
From:       Ran Atkinson <rja () CORP ! HOME ! NET>
Date:       1998-09-24 1:21:27
[Download RAW message or body]


On Sep 18 13:46, John T. Moy wrote:

% No, it was not intended for ospfIfAuthKey to configure
% the 16 byte md5 key. At the time we added MD5, we considered
% SNMP too insecure to be used to configure the keys, so
% we left the keys out of the MIB. However, now with SNMPv3,
% we may want to reconsider (Ran, do you have anything to say
% on the subject?).

        I don't have a firm opinion about what is best to do.
With apologies for that, I'll have a little monologue here
briefly to outline the issue a bit.

        On the one hand, we don't have a widely implemented key management
protocol suitable for OSPF (or RIPv2 for that matter), so maybe extending
the MIB to include the entire "OSPF Security Association" (KEY-ID, Key, and
other parameters) is useful.

        On the other hand, I have some personal distaste for getting
security of one protocol dependent on security of another protocol (except
where the "another" protocol is a security protocol).  I really dislike
cascading vulnerabilities and risks.

        The other thing is that I think I've figured out a scheme for a
really stripped down key management protocol that could work with OSPF (not
documented yet, sorry).  I'd have to specify it using ElGamal to avoid
patent problems.  I wish I had time to write it down and let folks poke
holes in it.

% If we're going to set the MD5 keys in the MIB, we need a new
% table indexed by Interface IP address, IfIndex, AND key ID, since
% you can have multiple keys active on an interface for
% transition purposes.

Good point.  I hadn't thought about that.

Ran
rja@corp.home.net

PS: I'm very happy to see MOSPF move forward.  Once upon a time,
  I had my fingers in a large installation of Proteons running
  M-OSPF.  It was rock solid -- better than mrouted(8) or any PIM
  has ever been since.

[prev in list] [next in list] [prev in thread] [next in thread]