Subject: Re: Comments on draft-ietf-krb-wg-hw-auth-00.txt

From: Matt Crawford <[email-masked]>
Date: Wed, 21 Nov 2001 14:27:17 -0600

This is a response to a very old (Aug 2) comment on the above-named
draft.  However, to date it is the only comment sent to the WG.

Nicolas Williams wrote:
> It seems to me that PA-TGS-REQ should be used instead of a new padata
> type ("PA-ALT-PRINC"). Using PA-TGS-REQ would provide a session key in
> which to encrypt the resulting ticket, which seems better than using the
> alternate principal's long-term key.

True, using a ticket's session key would be better.  But since a
long-term key is what's used for protecting all other AS-REPs, I
don't see any great virtue in improving this one odd case.  Let some
other new mechanism such as DCE 26.0 or one of John Brezak's
suggestions from the London meeting be implemented to protect all
AS-REPs.

> If there is no need for the KDC to suggest an alternate principal (I
> don't see why it should, other than convenience to the AS client) then
> there is no need for PA-ALT-PRINC at all.

In the draft, the KDC prods the client side to name the alternate
principal when it supplies the hardware preauth challenge data.  In
my implementation and deployment, the alternate principals are host/*
or ftp/* and bear no relation to the client in the AS-REQ.

> Existing KDC software has code to decode PA-TGS-REQ padata so using
> PA-TGS-REQ instead of PA-ALT-PRINC should result in better code
> re-use.

I have to strongly disagree with this.  Because both 1510 and
kerberos-revisions mark the cname field as optional and "used only in
AS-REQ", neither the MIT nor the Heimdal implementations include it
in a TGS-REQ.  You'd have to change quite a bit of library code which
the PA-ALT-PRINC method never touched.

> The use of a session key is preferable over the use of a long-term
> key, no?

Yes, but there's a bootstrapping question.  If you simply go over to
using a TGS-REQ, where did the TGT come from?  Better to protect the
AS-REQ better than to sweep the dust under a different carpet.

> Also, this proposal comes close to being an impersonation service,
> something I'm interested in. I'm writing a draft proposal for such a
> service, the idea being that one could grant some principals the right
> to obtain service tickets in some other principals' names.

That seems like a very different function to me.  In my draft and
application, the alternate principal has no special right of
impersonating the real client.  Rather, the client has, by supplying
the hardware preauth response, authorized the alternate principal's
key to be used to protect delivery of the client's new credential.
The two ideas could be combined, but logically need not be.

			Matt Crawford

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 21 Nov 2001 15:54:57 -0500

Thanks. Inline.

> suggestions from the London meeting be implemented to protect all

I've been thinking of a more generic impersonation service where
additional PA-TGS-REQs can be used to show that the impersonator has
priviledged access to a lost host/* principal, say.

> or ftp/* and bear no relation to the client in the AS-REQ.

Hmmmm.

> the PA-ALT-PRINC method never touched.

PA-TGS-REQ is only used in TGS exchanges, not AS exchanges, but there's
not much difference between AS and TGS exchanges (the app tag, the
INITIAL flag and the sets of PAs).

What I meant wrt code re-use was that the code to make/verify PA-TGS-REQ
is already there (PA-TGS-REQ is just an AP-REQ after all), so it should
be easier to re-use than having to write ASN.1 coding/decoding routines
for a new PA type and so on and so forth.

> AS-REQ better than to sweep the dust under a different carpet.

You're not adding protection to the AS exchange with this. Yes, the
long-term key has to be used in order to get a TGS whose a session key
can be used for the enc part of the KDC-REP as I suggest. BUT, using
PA-TGS-REQ you get to use the long-term key less often and the TGS
session keys instead. Thus you do protect the longe term key by
providing a snooper with less ciphertext for cryptanalysis.

> The two ideas could be combined, but logically need not be.

Yes, but the main thing here, yes, is that by using PA-TGS-REQ to
additionally authenticate the ALT-PRINC you gain something which I want
to use in my impersonation proposal: namely that the client proves that
it's got [priviledged] access to its host/* principal.

So, establishing the principle of using PA-TGS-REQ for authenticating
additional, call them "co-signatory," say, principals is useful, and, in
your case even goes so far as to provide a session key which can be used
instead of the ALT-PRINC's long term key - see above for how this does
help protect said long term key.

> 			Matt Crawford

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: Wed, 21 Nov 2001 16:31:18 -0500

Oops, there's a silly typo below...

> priviledged access to a lost host/* principal, say.
                          ^^^^
			  typo