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

From: "John Brezak" <[email-masked]>
Date: Thu, 6 Dec 2001 12:40:57 -0800

Bringing Nico's user-to-user issue up top.

What about any tickets in the additional-tickets field of a TGS-REQ? Can
they be mixed?

Also the PA-AS-REQ would need to have exactly the same PA types as the
base AS-REQ. In many cases when the client knows that PA is required, it
can and will send the PA-ENC-TIMESTAMP or PA-PKINIT in the initial
as-req.

-----Original Message-----
From: Nicolas Williams [mailto:[email-masked]] 
Sent: Thursday, December 06, 2001 10:05 AM
To: Sam Hartman
Cc: Douglas E. Engert; [email-masked]
Subject: Re: [extensibility 3] details of negotiation and guidelines

On Thu, Dec 06, 2001 at 12:46:39PM -0500, Sam Hartman wrote:
> >>>>> "Nicolas" == Nicolas Williams <[email-masked]> 
> >>>>> writes:
> 
>     Nicolas> On Thu, Dec 06, 2001 at 12:24:59PM -0500, Sam Hartman
>     Nicolas> wrote:
>     >> >>>>> "Nicolas" == Nicolas Williams <[email-masked]>
>     >> writes:
>     >> 
>     Nicolas> I would say that sysadmins must not allow the use of new
>     Nicolas> Kerberos on hosts that have a mixture of old-only and new
>     Nicolas> Kerberos software support. Easy enough, yes? You just
>     Nicolas> refrain from telling your mixed hosts' KDCs that they are
>     Nicolas> ready for new Kerberos.
>     >> 
>     >> 
>     >> For services, sure, or at least handle it on a principal by
>     >> principal basis.  Really you probably want to have clever
>     >> tricks in your application for updating service keys so
>     >> sysadmins mostly don't think about it.
> 
>     Nicolas> Key updates are not hard -- if you do nothing special in
>     Nicolas> kadm5.acl any principal can change its own keys, so it's
>     Nicolas> not hard to cobble a cronjob to change a host's keys
>     Nicolas> periodically...
> 
> Yeah, kadmin and a cron job is a fine solution if you are using MIT 
> Kerberos.  You might want to use an implementation of 
> kerberos-set-password for a more interoperable solution.

Granted. There is none for MIT KDCs yet, correct?

>     >> But for clients it is more complex.  It seems desirable to me
>     >> to be able to take advantage of the new features when talking
>     >> to services that support it even if some applications like
>     >> Oracle use old antequated code.
> 
>     Nicolas> If you have a mixture of old-only and new Kerberos client
>     Nicolas> software support on one host, and you want to be able to
>     Nicolas> use new Kerberos then you need to use separate ccaches
>     Nicolas> for the old-only and new Kerberos clients... no?
> 
> Well, that depends on your client implementation; I suspect that MIT 
> will use CCAPI and have a shared ccache that stores ticket1, tickt2 
> and krb4 tickets all in one object.
> 
> But yes at some level they are distinct.
> 
> The question basically boils down to how much protocol support do we 
> give you?  We could for example let you use a ticket2 TGT to get a 
> ticket1.  This would allow you to forward ticket1 when appropriate or 
> if you are using CCAPI and you find that you don't have a ticket1 but 
> need one then cons one up behind the scenes.

Well, new Kerberos MUST support using a new TGT to get an old service
ticket for a principal which does not support new Kerberos.

And if you can make old-AP-REQs with new tickets, then old clients can
use new tickets to make old TGS-REQs.

As long as the old client has the ticket encpart, its session key and
the ticket's target principal name (there's the rub, wrt UTF-8 princ
names) it should all work, even with new tickets.

Now, wrt UTF-8 names -- old [MIT/Heimdal] clients would be unable to use
old Kerberos with new services with non-ASCII names. This is true
regardless of whether the old clients in question have new or old TGTs
in their ccaches...

So, I suspect that even old MIT clients will be able to use new TGTs,
but, tickets with non-ASCII princ names might cause the old clients,
possibly, to crash (I also doubt this, since old MIT clients treat names
as strings of 8-bit chars with no nulls, which is what UTF-8 names would
look like to them).

> Alternatively we could completely ignore the issue at the protocol 
> level.  You could either kinit twice or more likely have a kinit that 
> created two ccaches at once.

I'd prefer not to use new Kerberos on a given host until all software on
it supports new Kerberos. I say this as a sysadmin.

> 
>     Nicolas> If you have old-only services which accept forwarded
>     Nicolas> creds and new clients on the same host, no big deal --
>     Nicolas> remote clients will only forward old creds.
> 
>     Nicolas> If you have new services and old-only clients on the same
>     Nicolas> host, then you must not allow new creds to be forwarded
>     Nicolas> to such hosts, which is probably best done by indicating
>     Nicolas> in the hosts' realm database entries that they do not
>     Nicolas> support new kerberos.
> 
> You could do this.   I'm not convinced it is right.

Why would it not be right?!

What I suggest amounts to waiting till all software on a given host
supports new Kerberos before using new Kerberos with that host. I mean,
heck, if you have no new Kerberos support on a given host then you must
wait until you do to use new Kerberos.

****

Things will get a bit more interesting with user-to-user exchanges...

KDCs can be asked to know if a given host principal supports new
Kerberos because host principals are associated with hosts which, in
turn host software which in turn can be upgraded and inventoried.

But can KDCs be asked to know whether a user principal supports new
Kerberos, considering that that user principal can be using pretty much
any host any time? Can the KDC be expected to map HostAddresses to host
principals and determine new Kerberos status from that?

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.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 6 Dec 2001 16:03:44 -0500

> Bringing Nico's user-to-user issue up top.

Well, I don't use, need or really care about u2u authentication [yet!]

:^)

> What about any tickets in the additional-tickets field of a TGS-REQ? Can

I'd say yes. The ticket/AS-REQ used in the PA-TGS-REQ should determine
whether the request is new or not, right?

> can and will send the PA-ENC-TIMESTAMP or PA-PKINIT in the initial

Well, yes, otherwise it wouldn't be a very extesnible new protocol, that
is, if it didn't support existing PA types... :)

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.-

---

From: "Douglas E. Engert" <[email-masked]>
Date: Thu, 06 Dec 2001 15:51:38 -0600

Another interesting point came up on the krbdev list. 

With the KerberosString,  how is a realm stored in the transited 
field? It was designed to have realm names, and has a compression 
algorithm to keep the field short. This will have to be extensible 
as well.

-- 

 Douglas E. Engert  <[email-masked]>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 7 Dec 2001 13:15:48 -0500

Hmmm, the revisions are fairly quiet as to whether tr-data are to be
interpreted as VisibleString or what. The ASN.1 treats it as and octet
string. Which is nice. Because

 - generally, old clients and old services may not communicate with
   principals whose names are not ASCII
 - generally, old clients and old services may not communicate with
   principals from realms whose realm names are not ASCII

 - it stands to reason that old clients and old services may not
   communicate with any principal such that the ticketing must transit a
   realm that has a non-ASCII realm name.

So if a ticket is a ticket2 then the transited data should be in UTF-8.
This should not get in the way of the special characters used in
transited field compression.

Right? Wrong?

Nico