[5202] in Kerberos
Re: V5: Can principal names have '@' in them?
daemon@ATHENA.MIT.EDU (Theodore Ts'o)
Fri May 19 15:14:22 1995
Date: Fri, 19 May 1995 14:49:11 +0500
From: Theodore Ts'o <tytso@MIT.EDU>
To: Clifford Neuman <bcn@ISI.EDU>
Cc: jik@cam.ov.com, kerberos@MIT.EDU
In-Reply-To: Clifford Neuman's message of Wed, 17 May 1995 13:35:35 -0700,
<199505172035.AA09190@cayman-islands.isi.edu>
Date: Wed, 17 May 1995 13:35:35 -0700
From: Clifford Neuman <bcn@ISI.EDU>
If it isn't, then "foobar@baz@GZA.COM" should parse into the principal
"foobar@baz" in the realm "GZA.COM".
You are correct. This should be parsed as the user foobar@baz in the
realm GZA.COM.
Should it? Or should it be parsed as the user "foobar" in the realm
"bar@GZA.COM"? It's not obvious at all.
The way the MIT implementation deals with this is that its the parse
rules (which are not currently defined by RFC 1510, but which are rather
an implementation-specific detail), is that if you wish to include an
a '.' or an '@' character, you must use a backslash to protect it.
i.e.,
foobar\@bar@GZA.COM
Similarily, if you wish to include an ASCII null in a principal
component name, you may do so by specifying a '\0'. If you wish to
include a backslash in a principal component name, you must specify
'\\'.
I'll make sure that this makes it in. @ should not be illegal in
principal name components. It probably should be illegal in DNS style
realm name, though not illegal for other kinds of realm names. How to
parse in an ambigious situation needs to be thought through.
I already did this thinking roughly two years ago; see
src/lib/krb5/krb/parse.c and src/lib/krb5/krb/unparse.c in the MIT
implementation for the end-results.
My conclusion at the time was that the protocol designers clearly had
put any thought into the parsing problem when they thought up their
delightful generalized principal names. There's an awful lot of
complexity in krb5's parse.c routine to handle the fact that you can put
literally anything, including the entire contents of /vmunix into a
principal component, and this would be considered a syntically valid
Kerberos V5 principal name according to RFC-1510.
- Ted
