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

[bam: Re: ssh vs kerberos]

Arrgh! I meant to post this letter to the whole list. Sorry about that.

I believe the message to be relevant to everybody so I am reposting.

I hope nobody minds...

-- 
Brian May <bam@snoopy.apana.org.au>
--- Begin Message --- 
In article <[🔎] 19990629231238.A7439@csh.rit.edu> you write:
>Disclaimer: My experience with Kerberos is limited, though I do have
>some.  Feel free to correct my facts.

Disclaimer, I have played around with kerberos a little bit, read
some articles, hence claim to be an expert ;-) Seriously - I am not!

>This sounds like both sites are trusting a common KDC.  You are getting
>tickets from it (trust), and the remote system is believing that you
>are who it says you are (trust).  This is part of the administrative
>problem.
>
>The other half of the problem is letting snoopy know who the KDC is for
>the MONASH.EDU.AU realm.  As far as I know, this has to be configured
>by the administrator [postscript: more on this below].  If I'm not an
>administrator on the remote system, or its administrator isn't willing
>to configure my realm there, then Kerberos won't do what I want.

This is the most serious problem with inter-realm security, I have seen
people complaining about it, but so far no solution (that I have seen).
I have seen proposals for doing inter-realm security with public key
encryption, but couldn't download the article as the http link was old.
I don't know if it would help.

Hence, I would probably just log onto each realm seperately...
I can't see any real great need for inter-realm security myself.

>> 2. log into each realm that you may use manually. There is no reason
>> that you have to use anything special to do this. Currently though,
>> this involves manually keeping track of seperate ticket files for each
>> realm. With respect to other problem, of finding the realm and server
>> for a given hostname, there is a proposed solution to add DNS entries to
>> contain this information.
>> 
>> Of course, logging into multiple realms requires another password for
>> each realm, but IMHO, this is better then sharing a common private key
>> for multiple hosts (ssh method). Anyway, how many completely seperate
>> realms are you likely to access in one session?
>
>SSH supports a number of authentication methods, including (but not
>limited to) "pure" RSA authentication, which you've described.  There
>is no reason that I have to trust private keys on multiple hosts at
>all.  In fact, the most common way I use SSH (and in my opinion, its
>most broadly useful mode) is with simple password-based authentication.

Sorry to get picky - you do have to trust the remote host not to steal
your password... (While this is also a problem when typing your password
into kerberos, kerberos in the future could be altered to support OTP,
one time passwords, etc).

>If the remote server is running sshd, ssh will simply connect, verify the
>host keys, do a secure key exchange, and allow me to use existing
>authentication mechanisms in a more secure fashion.  No site-specific
>configuration is required on either side.

Perhaps if inter-realm security can be improved, this will be less
of a problem...

However, I guess it kerberos's advantage will always be that it is
centrally administrated, where as ssh's advantage is that it isn't.
People who don't like the organisations security policies, might be
better of using ssh.

FYI: ssh1 can support kerberos tickets... It hasn't been implemented
in ssh2 yet though.

>The idea of finding the realm and KDC via DNS is interesting...is
>anyone using this today?  That would perhaps solve the configuration
>difficulties that I outlined above.  Do you have any pointers to more
>information?

Yes. I found the discussion on the comp.protocols.kerberos newsgroups.
Please see attached messages - this shows the main proposal, I think. If
you want me to post you the entire sub thread, then please let me know -
I probably have missed a number of important points.

>If you want to do RSA-based authentication, you can do that, and try to
>protect your private keys, but it's not necessary.  If you choose to do
>this, you can also limit the privilege of a given private key (for example,
>by only allowing it to execute a particular command).

True. I tend to think though that time limited tickets are more useful
then command limited keys - who uses command limited keys? I would be
interested in knowing useful applications, in areas where it increases
security...

>I have used Kerberos within an organization, and it seems to work well
>for that (except for the lack of non-UNIX support), but I find that

I think this might be improving - not sure though, as I usually just
skip other messages about Windows support. I believe Microsoft has plans
to support Kerberos in WNT5 and Windows 2000, whether it is going to
be compatable that is something else entirely... See the kerberos FAQ,
available from a link under http://web.mit.edu/kerberos/www/ for more
information.

>Kerberos and SSH are not direct replacements for one another, and in fact
>are quite useful together.

I am not really convinced yet of this - they seem to have conflicting
goals, eg kerberos goal of only entering your password once, but I will
keep an open mind...

For computer security in general, I get fed up with the number of
different passwords I have to remember (and change):
- one shadow password for each computer that doesn't use NIS.
- NIS passwords.
- SMB passwords.
- SSH passwords.
- PGP passwords.
- GPG passwords.
- Windows share passwords.
- Windows login passwords.

Arrgghh! This is one thing I really like about kerberos! How much it
can help, I have still to find out.

-- 
Brian May <bam@snoopy.apana.org.au>
--- Begin Message --- 
In article <3724C70D.B4E5C5EB@blackhawk.nrl.navy.mil>,
Vince Hickey  <vhickey@blackhawk.nrl.navy.mil> wrote:

: Alas, I think you will always have a conf file... it is the flexibility of
: where you put the conf and ticket files
: and where the apps look for it when they run, that I think are important

The point of this thread is that a Kerberized service must be as easy
to install and use as a non-Kerberized version of that service.
If it is not, then Kerberos will not become the mass market solution
to authentication and secure connections.

Are there Kerberized clients available for most major platforms? Yes.

Is it possible for the majority of people to use them?  No.

Can I walk up to one of your machines and authenticate to my KDC?  No.

That is the problem.


    Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2
                 The Kermit Project * Columbia University
              612 West 115th St #716 * New York, NY * 10025
  http://www.kermit-project.org/k95.html * kermit-support@kermit-project.org

--- End Message ---
--- Begin Message --- 
In article <7gfp2g$a07@fermi.cmf.nrl.navy.mil>, kenh@cmf.nrl.navy.mil (Ken Hornstein) writes:
|> In article <7gaft0$ed4$9@nntp.Stanford.EDU>,
|> Jonathan Stone <jonathan@DSG.Stanford.EDU> wrote:
|> >That would help, but its not a very good use of the DNS.  If I want to
|> >be able to access any Stanford host, the Stanford people would have to
|> >add tens of thousands of Kerberos records to their DNS database.
|> 
|> In terms of realms information, you can do this quite easily with DNS
|> SRV records.  I think most people have agreed this is the "right" thing
|> to do.  Only requires a few records.  I've already gotten the code
|> written as a matter of fact :-)  You can use this to find the KDCs
|> and admin servers for a particular realm.  I believe that Heimdal
|> and Microsoft Kerberos do this as well.

Finding the records that map from realm to KDC is the easy part.
If you've got the patches, and Hemidahl and M$ can do this, why arent
they in the MIT krb5 distribution?

[host to realm]

|> _kerberos.hostname.domain.name	IN	TXT	"YOUR.KERBEROS.REALM"
|> _kerberos.domain.name		IN	TXT	"YOUR.KERBEROS.REALM"
|> 
|> By default, try the TXT record corresponding to a host; if it doesn't
|> exist, then try the one for the domain.  This will let you discover
|> which realm a particular host belongs to.

It's a mapping from the host name (a domain) to some other kind of DNS
info; it should really have a record type of its own. You say
yourself, "the TXT record corresponding to a host", but your example
doesn't do that; it prepends "_kerberos."  that's is a hack.

domain.name		IN	REALM	CORPORATE.KERBEROS.REALM
dept.domain.name	IN	REALM	DEPARMENTAL.KERBEROS.REALM
myhost.dept.domain.name	IN	REALM	MY.PRIVATE.KERBEROS.REALM

Where the RHS is interpreted as the name of another (SRV?) record to
fetch -- like MX records.

Did you say there's a strawman proposal for this?


|> >I'm also unsure where per-host info (like v4-instance-convert) really
|> >belongs: with the record for the realm, or with the host itself?
|> 
|> Errr, I think we should punt on this one; if you're still using V4,
|> you deserve to have a large configuration file :-)

Fair enough.

--- End Message ---

Attachment: pgp_MuL3EpkO7.pgp
Description: PGP signature


--- End Message ---
Reply to: