Subject: Re: Working Group Last call - draft-ietf-cat-iakerb-07.txt

From: Nicolas Williams <[email-masked]>
Date: Tue, 7 Aug 2001 14:13:20 -0400

I've developed a bunch of new comments.

Is it too late to share these?

Nico

On Mon, Jul 02, 2001 at 02:08:35PM -0500, Douglas E. Engert wrote:
> A revised version of the IAKERB document is now ready for Working Group 
> Last Call. 
> 
>         Title           : Extending the GSS Kerberos Mechanism for Initial      
>                           Kerberos Authentication (IAKERB)
>         Author(s)       : M. Swift, J. Trostle, B. Aboba, G. Zorn
>         Filename        : draft-ietf-cat-iakerb-07.txt
>         Pages           : 9
>         Date            : 28-Jun-01
> 
> The draft can be found at:
> 
> http://www.ietf.org/internet-drafts/draft-ietf-cat-iakerb-07.txt
> 
> This document has had minor changes from the last revision, and the authors
> will be sending out to the list of changes shortly. 
> 
> We will start a two week last call, which should end on July 18. 
> 
> 
> -- 
> 
>  Douglas E. Engert  <[email-masked]>
>  Argonne National Laboratory
>  9700 South Cass Avenue
>  Argonne, Illinois  60439 
>  (630) 252-5444
--
. 

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: Tue, 7 Aug 2001 23:57:55 -0400

Well, no answer. And tomorrow is the IETF meeting, and I'm not able to
attend.

But I'd still like to comment.

1. How are GSS context flags/options sent by an IAKERB initiator? Or are
   they to be sent by the acceptor when it sends its AP-REQ?

2. How is credential delegation (from initiator to acceptor) performed?

3. The optional TKT_PUSH message may break existing applications.
   Whereas the idea of a three message handshake and all that can be
   implemented at the library level without changes to existing
   applications, the optional TKT_PUSH message would probably break
   existing apps because, once a context is established, they expect no
   further context-setup tokens and the GSS-API C Bindings do not provide,
   (if I recall) a clean and recommended way for dealing with additional
   gss context setup tokens after completion of context establishment
   (it's late -- correct me if I'm wrong).

4. The AS-REQ-based alternative proposed does not work in cross-realm
   situations.

These two points are mightily unclear to me given a reading of the
current draft. On the first point (1) the draft implies that the
acceptor sends what would otherwise be the initial GSS context setup
token and that includes the GSS flags as per RFC1964, however this does
not allow the initiator to negotiate any flags and also does not allow
the initiator to forward credentials to the acceptor (only acceptor to
initiator, but I think that usually that will not be desired).

I'd like to propose a variation of IAKERB, based on the spirit of it,
but where instead of the initiator sending a TKT_PUSH it sends a
TGS-REQ:

 - The acceptor pulls out the initiator's TGT from the TGS-REQ's
   PA-TGS-REQ's AP-REQ's ticket and uses that to obtain a ticket with
   the initiator as the target; the acceptor then also forwards the
   initiator's TGS-REQ to the TGS _with a second PA-TGS-REQ included
   with the acceptor as the client_ -- this second PA-TGS-REQ is used
   to indicate to the TGS that: a) this is an IAKERB proxy situation
   and b) to modify its check of the request's source address / listed
   addresses (the second PA-TGS-REQ's AP-REQ will contain the
   acceptor's address(es).

 - The response from the IAKERB proxy/acceptor to the initiator consists
   of the TGS-REP from the KDC (the response to the forwarded TGS-REQ)
   with the second PA-DATA item (a PA-TGS-REP -- see above) replaced
   with a PA-TGS-REQ containing an AP-REQ from the acceptor/proxy to
   the initiator -- this AP-REQ should include GSS context flags and so
   on as per-RFC1964. This TGS-REP includes, by definition, the
   initiator's ticket with the acceptor as the target.

 - The third and last message in the context setup phase is from the
   initiator to the acceptor and must contain:

    - the initiator's AP-REP response to the acceptor's AP-REQ
    - the initiator's requested GSS flags (protected)
    - the initiator's KRB-CRED, if any

 - Finally, the acceptor *may* respond with an error if the client's
   requested GSS context options are not accepted.

This protocol is a three message handshake between the initiator and the
acceptor. It introduces no new ASN.1 (whereas the draft does: TKT_PUSH).
It requires a [minor] change to KDC behaviour. It seems more elegant to
me. The use of a TGS-REQ instead of TKT_PUSH is similar to the draft's
proposed use of AS-REQ, but with the benefit of working in cross-realm
situations.

So I think this variation on the IAKERB proposal is small, but
significant.

I may, of course, be missing some reason why the above could not work.
Please let me know if I am.

In a separate mail I'll describe several enhancements to Kerberos that I
think are possible and which are based on the notion that initial-type
pa-data and PA-TGS-REQ/PA-TGS-REP, or two or more PA-TGS-REQ in a
TGS-REQ can be mixed in a single request. In fact, I've already
described an improvement to draft-ietf-krb-wg-hw-auth-00.txt along those
lines.

The improvements I envision are:

 - draft-ietf-krb-wg-hw-auth-00.txt using PA-TGS-REQ instead of the
   proposed PA-ALT-PRINC.

 - the use of a host-based principal's AP-REQ in a PA-TGS-REQ in
   AS-REQs for providing AS-REP/KRB-ERROR authentication of the AS to
   the host-based principal used in the request.

 - a variation on draft-ietf-krb-wg-hw-auth-00.txt (using PA-TGS-REQ
   instead of PA-ALT-PRINC for an impersonation service (a SUDO for
   Kerberos).

 - a generic KDC proxy.

 - an impersonation proxy.

 - IAKERB modified as described above.

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: Wed, 08 Aug 2001 04:35:41 -0500

> Is it too late to share these?

Actually its to late, The "LAST CALL" ended weeks ago. Unless you have a fatal
protocol error. But I don't see that in your comments, which appear to be a set of
questions and suggested changes. 

--

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 8 Aug 2001 07:47:26 -0400

> questions and suggested changes. 

Sigh. Note, however, that some of the questions I had relate to possible
difficulties with IAKERB.

Nico