Subject: IAKERB draft

From: David Margrave <[email-masked]>
Date: Mon, 17 Nov 1997 14:14:50 -0800

Mike,

The IAKERB draft proposes a new mechanism for providing initial
authentication.  Why is a new mechanism proposed instead of proposing a
revision to the existing Kerberos V5 mechanism?  It seems unnecessarily
cumbersome to have to worry about handling multiple mechanisms when its
basically all just RFC-1964 Kerberos V5 below, with a couple new twists.
Then we wouldn't have to worry about TOK_ID conflicts between different
Kerb 5 mechs either.

Since the existing Kerberos V5 mechanism doesn't handle initial
authentication, implementors have used extension functions.  The extension
functions for initial authentication handle details like prompting for
passwords, etc.  I think it would be difficult to get GSS_init_sec_context
to handle prompting.  Couldn't extension functions be used here as well, as
long as the resulting tokens conform to the proposed TOK_IDs?  If
GSS_init_sec_context is used rather than extension functions, how would it
be implemented, i.e. additional req-flags in GSS_init_sec_context,
prompting mechanism, etc.?  

Dave

---

From: Martin Rex <[email-masked]>
Date: Mon, 17 Nov 1997 20:23:32 -0500 (EST)

> prompting mechanism, etc.?  

This is intended for scenarios where the Kerberos Client software
has no idea how to contact the remote KDC, but the application that
uses the GSS-API knows how to contact it's destination and how to
exchange data within the GSS-API model.

Why should gss_init_sec_context() need to do prompting?
It is a completely local matter what each implementation of a mechanism
considers "credentials", how it creates them, where and how long it
keeps them around.

If a specific Kerberos implementation keeps a "password" around, it
can use that as an alternate "initiator credential" to trigger the
new negotiation. This way you would get along completely without changing
the application.

-Martin