Subject: RE: [extensibility 3] details of negotiation and guidelines

From: "John Brezak" <[email-masked]>
Date: Tue, 11 Dec 2001 22:48:09 -0800

What should be in the names in the "old" AS-REQ if the names cannot be
represented? They could/should carry exactly what they do today - say
Utf8 in GeneralStrings for compat.

Also, how would the client know what flavor of tgs-req should be going
for a cross-realm request?

> -----Original Message-----
> From: Tom Yu [mailto:[email-masked]] 
> Sent: Tuesday, December 11, 2001 10:15 PM
> To: John Brezak
> Cc: Sam Hartman; [email-masked]
> Subject: Re: [extensibility 3] details of negotiation and guidelines
> 
> 
> >>>>> "jbrezak" == John Brezak <[email-masked]> writes:
> 
> jbrezak> What would happen when a client has a username that 
> cannot be 
> jbrezak> expressed in the IA5String (constrained GeneralString) that 
> jbrezak> must be in a as-req?  The PA-AS-REQ can carry the 
> correct names 
> jbrezak> because it can use Utf8String, but isn't it a 
> problem if both 
> jbrezak> of the requests are not carrying the exact same information?
> 
> We could argue that the PA-AS-REQ would be treated as 
> authoritative in that case.
> 
> ---Tom
>

---

From: Ken Raeburn <[email-masked]>
Date: 12 Dec 2001 19:50:15 -0500

> Utf8 in GeneralStrings for compat.

Or the "just send 8" encoding, if that's what an implementation/realm
was using before.  Or "just send EBCDIC", as in Paul's example.

Or, if you never did support non-ASCII names, you could assert that
the use of such names implies that the realm has been updated, so you
could just send the new request and skip the preauth.  (There is the
annoying problem that typing in a UTF-8 name in a realm that hasn't
had its KDC updated to support such names -- i.e., the principal name
isn't actually in the database -- would likely cause a timeout rather
than an error.  Whether that's acceptable might be left to the
implementor or the site admin.)

> for a cross-realm request?

Same as for any other service -- you get a hint from the KDC, which
has to know whether the server supports new messages.

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 12 Dec 2001 20:38:48 -0500

> has to know whether the server supports new messages.

If the client has a TGT for realm A and realm A supports new Kerberos,
then to get a x-realm tickt for realm B the client should do a new TGS-REQ.
The KDC for realm A should either return a new ticket or an old ticket
depending on whether realm B supports new Kerberos. This is easy --
after all, the new Kerberos realms are being asked to keep track of
which service principals support new Kerberos...

No?

Nico
--
-DISCLAIMER: an automatically appended disclaimer may follow. By posting-
-to a public e-mail mailing list I hereby grant permission to distribute-
-and copy this message.-

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.