[4] in Kerberos
Re: Kerberos Support for Remote Serv
jon@ATHENA.MIT.EDU (jon@ATHENA.MIT.EDU)
Sun Aug 9 21:12:08 1987
From Saltzer@ATHENA.MIT.EDU Mon Jun 9 00:52:57 1986
Date: Mon, 9 Jun 86 00:47:25 EDT
Subject: re: Kerberos Support for Remote Services, Project Description (long)
To: Mark Colan <mtc@ATHENA.MIT.EDU>
Cc: geer@ATHENA.MIT.EDU, bcn@ATHENA.MIT.EDU, spm@ATHENA.MIT.EDU,
charlie@ATHENA.MIT.EDU, noah@ATHENA.MIT.EDU, jis@ATHENA.MIT.EDU
In-Reply-To: Mark Colan <mtc@ATHENA.MIT.EDU>'s message of Tue, 03 Jun 86 17:12:41 -0500
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
Originating-Client: <Saltzer-PC>
Mark,
That plan looks fairly good. Here are some minor questions. (Your
writeup assumes rather substantial recall of a lot of Kerberos
details; since I didn't memorize them, some of the answers to these
questions may seem obvious to you.)
1.
> To start
> an authenticated rlogin session, a user creates a set of encrypted
> tickets (via vxlogin) that absolutely identify him to a remote host.
What is "vxlogin"?
2.
>Changes to rlogin.c
>
> Find the port number for a Kerberos login session (from /etc/services)
> If not found, punt the Kerberos login session and try normal rlogin.
> Otherwise, create a KTEXT object and fill it in (via mk_ap_req).
The management of Kerberos service keys isn't clear here. Does every
server that might allow Kerberos-mediated rlogin have a different
key? Or is there a standard Kerberos-mediated rlogin key that every
server must know? Assuming the former, just what does the
prospective client ask for by way of a ticket? How does the proper
UNIX user id get into the ticket? Do you assume that the Kerberos
name of the user is identical to the UNIX user id to be used at the
rlogin server?
3. Are the same service keys used for rsh, rcp, and rlogin?
4.
> Add new routine doKerberosLogin(). It snarfs a KTEXT object off of
> the connection stream via GetKerberosData() (see rcmd.c). Then gets
> the lusername (ie, rusername sent by rlogin) and terminal
> characteristics.
Where does the rlogin service store the private key it uses for
deciphering Kerberos tickets?
5.
> A feature of my approach is that it requires a new port number for
> the Kerberos-authenticated services.
This feature strikes me as being more of a bug. Have you established
for certain that you can't just extend the present protocol in a way
that produces a well-defined error response if you try to use the
Kerberos extensions in talking to a server that doesn't know about
Kerberos? I would expect that you could define a couple of new
operation types within the protocol that request a Kerberos login and
that supply the Kerberos ticket.
Jerry
