[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Heimdal DES encryption!!




>>>>> On Tue, 23 Nov 1999, "Ken" == Ken Hornstein wrote:

  +> The hostkey is not the hex value of the key; it is an 'encoded'
  +> value.  I'll leave it as an exercise to the reader to figure out how
  +> to determine the encoding, but you can directly enter an encoded
  +> value in the CLI instead of loading it via tftp. So you could enter
  +> this encoded value on another router and perhaps use a test KDC to
  +> determine the key?  Sounds infeasible to me [+ easier ways to break
  +> in].

  Ken> Actually ... as I understood it from a cisco employee, it's pretty
  Ken> much a straight translation of the host key into a printable format

Well, yeah. It's an 'encoding'. Not an encryption, hash, or other
fancier sounding word. :)

  Ken> (just not hex).  So if you grab it, you could then masquerade as
  Ken> anyone to that router.  Although .... I thought the key for the
  Ken> router was only available to the cisco "superuser" equivalant.  I

Anyone that can do a 'wr t' or 'sh run' can see it. By default the
non-superuser cannot do this. But these commands can be allowed
arbitrarily by users. Typically you would allow low level users to
use commands like this (non destructive/volatile commands).

  Ken> believe under some weird cases (like you have the domestic release
  Ken> and you do some additional magic) then it gets "hidden" by even the
  Ken> UI.

hmm... Never heard of that. I would tend to think this isn't correct
as you typically can restore a config solely from the 'wr t' output.

  +> But as for being able to login, Cisco actually has this part
  +> right.  Kerberos provides authentication, not authorization. Once a
  +> principal's identity is verified, to restrict logins you need to use
  +> tacacs+/xtacacs/radius for authorization. Unfortunately, the 'secret'
  +> for those protocols is directly visible in the UI.

  Ken> I believe we just create local login accounts; seems to work
  Ken> reasonably well.

Yup, that'll work too. Our environment has too many users, too much
churn, and too many devices to do that.

~f