default principal confusion

[Donn Cave]

Quoth klg at lanl.gov (Ken Grady):
|    What is the correct way to do this?  Or is it correct to allow both?
| And should an option be added to SomeNewSSH  to allow either
| functionality (-k1 kerberos original -k2 extra principal...)?
| Openssh-3.1p1 uses the default principal is the same as the client and
| things seem to be compatable as far as using forwarded tickets are
| concerned.  Compatability between differing versions of ssh is
| practically non-existant AFAICT.
|
|     When I kinit I get klg @lanl.gov as the default principal.  An od -c
| of the cache shows that klg is also the client. When I use ssh.com's
| ssh-3.1.0 and "ssh -l acct machine.lanl.gov", I end up with a ticket for
| default principal acct at lanl.gov and client klg at lanl.gov which isn't
| necessarily bad, because I can use that ticket and "ksu" (ticket default
| principal becomes klg at lanl.gov) and I become root (I'm in acct's and
| roots's .k5login files).  The logs on the KDC show that root was
| authenticated as klg at lanl.gov for acct (see below). Where it gets
| confusing is if I "ssh -l root machine.lanl.gov" my default principal is
| root at lanl.gov client klg at lanl.gov, but root at lanl.gov isn't a valid
| kerberos principal.  So should ssh-3.1.0 revert back to klg at lanl.gov or
| should ksu change the principal to root at lanl.gov and just leave the
| client klg at lanl.gov?  The ssh from ssh-3.1.0 doesn't seem to use the
| client info from the ticket cache, so I am unable to ssh with a default
| principal of root at lanl.gov and client of klg at lanl.gov to another machine
| (unless I "ksu klg" first.  What if I don't have an account on the
| machine?) nor am I able to ssh with a default principal of
| acct at lanl.gov.  So the question is "Which is correct?".

I don't have much to do with these things, but since no one else's
followup has appeared yet, here's my opinion.  "Where it gets confusing"
above shows why "-l username" should refer to a remote account and not
a Kerberos principal.  Authorization to that account can be based on
whatever suits sshd.  If Kerberos then the Kerberos principal should be
determined according to general Kerberos rules, i.e., the default
principal from the credentials.  If that's inconvenient, the solution
should apply to Kerberos applications in general, where I would imagine
the use of more than one principal could be better supported.

Whether ssh should forward credentials I don't know for sure, but since
there isn't any "real" mapping between principal and account, only a
set of loose conventions, I guess it should be as happy to forward to
a .k5login-authorized account as to a name==name-authorized account.

	Donn Cave, donn at u.washington.edu

|     The logs show:
| Apr 10 08:11:00 kerb1 krb5kdc[715]: TGS_REQ 123.123.123.2(88):
| ISSUE:authtime 1018447267, klg at lanl.gov for krbtgt/lanl.gov at lanl.gov
| pr 10 08:11:48 kerb1 krb5kdc[715]: TGS_REQ 123.123.123.2(88):
| ISSUE:authtime 1018447267, klg at lanl.gov for
| host/machine.lanl.gov at lanl.gov
| Apr 10 08:11:48 kerb1 ksu[8599]: 'ksu root' authenticated klg at lanl.gov
| for acct on /dev/pts/2
| Apr 10 08:11:48 kerb1 ksu[8599]: Account root: authorization for
| klg at lanl.gov successful