"pl" == Peter Lister, Cranfield Computer Centre
<P.Lister@cranfield.ac.uk> writes:
pl> In a nutshell, the problem is the HTTP server saying to the client
pl> "I'm foo, you must provide me with authentication for service
pl> foo". A malevolent server can persuade the client that it is
pl> genuine, and plant false information or obtain secret information
pl> in a query. The (reasonable) assumption of Kerberos is that the
pl> client knows with which prinicpal it must mutually authenticate
pl> *before* making the connection. Since the only information known
pl> beforehand is the URL, we must map the URL to a Kerberos
pl> principal.
I think you've here stated the problem more clearly than I was able
to in my previous posts. This is indeed the situation I tried to
describe.
pl> Current Kerberos practise seems to be to use dots in the instance,
pl> which can be touch confusing, since the instance is generally
pl> separated from the name with a dot, but it's liveable with, and
pl> I'd be happier with dots than underscores. I also reckon that
pl> "k4-" is redundant. So my preference in your example would be
pl> "http.bob.foo.com@FOO.COM", where the instance is "bob.foo.com".
As we use short hostnames for instances. I did not know if dots were
permitted in instances, hence the underscores. I comment below on my
use of ``k4-.''
>> I'm not familiar enough with HTTP to know what information the
>> browser is ``allowed'' to get from the URL, but the browser needs
>> to get the authentication identity from someplace other than the
>> server. The advantage of using the URL is that it is already there
>> and should contain all the necessary authencation identity
>> information.
pl> Hmm. Interesting point. The principal consists of three parts
pl> The principal name is unique to the service. I suggest we use
pl> "http", the URL type, but it doesn't matter as long as everyone
pl> agrees and we stick to one. Protocol versions are
pl> irrelevant. Logically, the scheme extends to other URL types,
pl> e.g. gopher,ftp. Anyone know what the URL/URN people feel about
pl> this?
The different protocols to which I refer are the authentication
protocols--k4, pgp, k5, etc.--not the connection methods--ftp, gopher,
http. I propose that the two together would, for Kerberos, be the
principal's name, e.g., k5-gopher.bob.foo.com@FOO.COM,
k4-http.bob.foo.com@FOO.COM. This would allow each connection method
to determine the authentication protocol.
pl> The instance is conventionally the name of the server machine,
pl> either the short form or fully qualified domain name. At
pl> Cranfield, POP uses pop.xdm001; AFS uses
pl> afs.pegasus.cranfield.ac.uk (the fully qualified cell name). My
pl> preference is to use the URL server name verbatim as the instance,
pl> e.g. http://www.cranfield.ac.uk/ =>
pl> http.www.cranfield.ac.uk.
I think one would, as you suggest, have to use the full server name.
For large sites, just the hostname sans domain name will not be
sufficient, e.g., Bob in Accounting should use
k4-http.bob.acct.foo.com@FOO.COM as opposed to k4-http.bob@FOO.COM
since the latter would collide with the machine for Bob in Sales,
bob.sales.foo.com.
pl> This does mean that if the same alias applies to several machines,
pl> their servers must all have the identical srvtab. No big deal,
pl> though it makes changing the service key harder in traditional
pl> Kerberos if it has to be done simultaneously on multiple machines.
Since this is currently a problem for Kerberos in general, using
HTTP with Kerberos would not introduce this as a new problem.
pl> We have to hand the server name in the URL to Kerberos and leave
pl> it to Do The Right Thing to work out the realm. Typically, a local
pl> (hence trusted) file e.g. krb.realms (or Transarc's CellServDB)
pl> maps remote domain names to realm (e.g. cranfield.ac.uk =>
pl> PEGASUS.CRANFIELD.AC.UK, as is the case at Cranfield).
I guess it was wishful thinking on my part to forget about the local
realm/cell config file.
pl> So I reckon the only info we need from the URL is just the server
pl> name, and I'm sure we're allowed to extract that.
>> Use of the URL means that the client, of course, needs to get the
>> URL from a trusted source (widely available documentation, an HTML
>> document acquired through a secure channel, etc.).
pl> Would a trusted URN -> URL translations service satisfy this? Have
pl> the URN guys considered this?
I'm not familiar with the workings of URNs--I think the HTTP spec I
have lists them as "to be specified."
michael