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

From: Jeffrey Altman <[email-masked]>
Date: Fri, 14 Dec 2001 14:12:46 EST

Nico wrote:
> On Wed, Dec 12, 2001 at 10:34:27PM -0500, Jeffrey Altman [Kermit Project] wrote:
> > The way that Sam described the PA-AS-REQ is that if the PA-AS-REQ is
> > included that all of the AS-REQ is ignored.
> 
> Yes, but only if the KDC supports new Kerberos. If it doesn't then the
> outer AS-REQ will not be ignored.

The point is that only one of AS-REQ or PA-AS-REQ can ever be looked
at by the KDC.  If the AS-REQ is used, that means that RFC 1510
Kerberos messages are in use.  Character set issues remain as they are
today.  If PA-AS-REQ is used, then new form messages are used for all
future messages.

> > Now if your question is:
> > 
> >     what should a new Kerberos implementation place into the
> >     GeneralString fields of the AS-REQ for use by old Kerberos
> >     implementations?
> > 
> > My answer would be:
> > 
> >     exactly what you place into those fields in your current
> >     implementation.
> > 
> > In other words, if you still have old Kerberos implementations
> > in use at your site, then you should restrict your use of
> > principal and service names to IA5Strings.  And if you can't
> > for whatever reason, then you do so accepting the risks described
> > in draft-ietf-krb-wg-info-ascii-gen-string-00.txt
> 
> If you can't then couldn't you use a bogus, but all-ASCII name? Just so
> you could probe the KDC? If the result is an error about an unknown
> principal, then you know that the KDC does not support new Kerberos.
> Hmmm, then you have to be able to distinguish which name is unknown:
> the name in the outer AS-REQ or the name in the inner AS-REQ?
> 
> This problem comes up only when probing a KDC (realm) to determine
> whether it suports new Kerberos AND the user principal name you want to
> get a ticket for happens to be a non-ASCII name.

If the AS-REQ is being used, then the KDC is an RFC 1510
implementation and it does not support the new messages.  There is no 
reason to try an ASCII only name.

> The alternative is to send the non-ASCII name as GeneralString in the
> outer AS-REQ and hope for the best.

This is what you would do because it is what you already do today.

- Jeff

 Jeffrey Altman * Sr.Software Designer      C-Kermit 8.0 Beta available
 The Kermit Project @ Columbia University   includes Secure Telnet and FTP
 http://www.kermit-project.org/             using Kerberos, SRP, and 
 [email-masked]          OpenSSL.  SSH soon to follow.

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 17 Dec 2001 10:07:57 -0500

> today.  If PA-AS-REQ is used, then new form messages are used for all

Yes, but, AS-REQ w/ PA-AS-REQ is to be used for PROBING KDC support for
new Kerberos. If the KDC lacks that support then the outer AS-REQ has to
be somewhat meaningful. At the very least there must be a cname/crealm
and sname/srealm, which brings up the question of what to use for those
when the intended names are non-ASCII.

> - Jeff

Cheers,

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.