Subject: RE: IAKERB draft

From: "Mike Swift (NT)" <[email-masked]>
Date: Mon, 17 Nov 1997 16:58:26 -0800

I have no problem with extending the existing Kerberos V5 mechanism - I
thought it might be easier to propose an extension as a separate mechansim,
as it allows it to be negotiated via SPNEGO.

In terms of acquiring the initial credentials, extension functions certainly
could be used for supplying the credentials to the mechanism. I don't think
that GSS_init_sec_context should prompt, as there are far too many cases
where prompting is the wrong thing. 
In Microsoft's implementation of Kerberos, credentials (user name, realm,
and password) may be supplied through an extended version of
GSS_acquire_cred_handle. If I was to supply credentials to
GSS_init_sec_context, I would have the caller format a token that could be
passed in to the package on the first call. This is not how mechanisms
currently function, but then they also don't currently allow you to supply
alternate credentials.

- Mike

> -----Original Message-----
> From:	David Margrave [SMTP:[email-masked]]
> Sent:	Monday, November 17, 1997 2:15 PM
> To:	[email-masked]
> Subject:	IAKERB draft
> 
> 
> 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: David Margrave <[email-masked]>
Date: Tue, 18 Nov 1997 11:50:45 -0800

To summarize and expand on what's been discussed up to now (my
additions/remarks noted with *** instead of - ):

- The proposed extensions for initial authentication will be implemented
within the existing mechanism with the OID {iso(1) member-body(2) United
States(840) mit(113554) infosys(1) gssapi(2) krb5(2)}.

*** The framing for per-message, error, and context deletion tokens shall
be identical to RFC-1964.

*** The encapsulated AS and TGS messages will be referred to as
"credential retrieval" tokens to distinguish them from per-message,
context establishment, error, and context deletion tokens.

- "Credential retrieval" tokens will use the following token IDs:

Message	TOK_ID

KRB-AS-REQ 	00 03

KRB-AS-REP 	01 03

KRB-TGS-REQ 	02 03

KRB-TGS-REP 	03 03

- The AS and TGS exchanges are optional.  Implementations supporting the
IAKERB extensions shall be backward compatible with applications written
to Kerberos V5 GSS-API implementations which do not attempt to make use
of IAKERB extensions.

*** Kerberos V5 GSS-API implementations which do not support IAKERB
should return an appropriate error message (GSS_S_CALL_BAD_STRUCTURE,
GSS_S_DEFECTIVE_TOKEN, or GSS_S_FAILURE) when gss_init_sec_context or
gss_accept_sec_context() is called with an IAKERB credential retrieval
token as input_token. 

*** The caller shall be responsible for supplying a properly formatted
IAKERB credential retrieval token as input_token on the initial call to
gss_init_sec_context(), or optionally to specify GSS_C_NULL_CREDENTIAL
for claimant_cred and GSS_C_NULL_BUFFER for input_token to use the
default credentials.  If input_token is supplied, gss_init_sec_context()
will perform consistency checks on input_token and on success, return the
identical token in output_token and return GSS_S_CONTINUE_NEEDED.  If the
token is valid, the initial call to gss_init_sec_context will essentially
be a no-op, but it should be structured this way to preserve the logic of
looping while GSS_S_CONTINUE_NEEDED is returned.

<paraindent><param>left</param>*** If the initiator has no TGT and no
service ticket for the context acceptor in the same realm, then the
caller then the caller shall be required to supply a valid IAKERB
credential retrieval token as input_token, containing an AS-REQ message
for the krbtgt/REALM service, OR containing an AS-REQ message for the
context acceptor's service principal.  How the caller chooses to generate
the input_token shall be implementation specific. On success,
output_token will return the same token as input_token (an embedded
AS-REQ message for the krbtgt/REALM service , OR an AS-REQ message for
the end-service) and gss_init_sec_context() will return
GSS_CONTINUE_NEEDED.

*** If the initiator has no TGT and no service ticket for the context
acceptor in a different realm, then the caller shall be required to
supply a valid IAKERB credential retrieval token containing a Kerberos V5
AS-REQ message the the krbtgt/SREALM service.

On success, output_token will return the same token as input_token (an
embedded AS-REQ message for the krbtgt/SREALM service) and
gss_init_sec_context will return GSS_CONTINUE_NEEDED.

</paraindent>

*** Since the AS and TGS exchanges are optional, a call to
gss_init_sec_context() with GSS_C_NULL_CREDENTIAL for claimant_cred and
GSS_C_NULL_BUFFER for input_token will use the default credentials,
meaning that it will pick up where appropriate: 

<paraindent><param>out,out</param>

</paraindent><paraindent><param>left</param>*** If the initiator has a
service ticket for the context acceptor, on success, output_token wil
return an  RFC-1964-style context establishment token (AP-REQ) and
gss_init_sec_context() will return GSS_S_CONTINUE_NEEDED if mutual
authentication was requested (as in RCC-1964).

</paraindent>

<paraindent><param>left</param>*** If the initiator has a TGT but no
service ticket for the context acceptor in the same realm, on success,
output_token will return an embedded TGS-REQ for the context acceptor's
service principal and gss_init_sec_context() will return
GSS_S_CONTINUE_NEEDED.  

</paraindent>

<paraindent><param>left</param>*** If the initiator has a TGT for its
realm but no service ticket for the context acceptor in a different
realm, on success, output_token will return an embedded TGS-REQ message
for an inter-realm TGT and gss_init_sec_context will return
GSS_CONTINUE_NEEDED.

*** If the initiator has no TGT and no service ticket and called
gss_init_sec_context with GSS_C_NULL_CREDENTIAL for claimant_cred and
GSS_C_NULL_BUFFER for input_token, gss_init_sec_context will return
GSS_S_FAILURE and an appropriate error code in minor_status.

</paraindent>

- The context acceptor, on receipt of an IAKERB credential retrieval
token, will de-encapsulate the message (AS-REQ or TGS-REP) and send the
request to the KDC.  On success, the context acceptor will return
encapsulated reply from the KDC (AS-REP, TGS-REP, or KRB-ERROR) as
output_token and gss_init_sec_context will return GSS_S_CONTINUE_NEEDED. 
On receipt of a context establishment token, it will behave as defined in
RFC-1964.

- On subsequent calls to gss_init_sec_context(), the initiator will
supply the reply token from the acceptor as input_token:

<paraindent><param>left</param>-If input_token contained an AS-REP for
the krbtgt/REALM (or krbtgt/SREALM) service, then on success,
gss_init_sec_context() will return a token containing a TGS-REQ message
for the end-service as output_token, and will return
GSS_S_CONTINUE_NEEDED.

-If input_token contained a TGS-REP for the end-service, then on success,
gss_init_sec_context() will return a context establishment token
containing an AP-REQ message as output_token, and will return
GSS_S_CONTINUE_NEEDED if mutual authentication was requested.

-If input_token contained an AP-REP, then gss_init_sec_context will
behave as defined in RFC-1964.

</paraindent>

Open issues:

How will hardware authentication be handled?  If the KDC returns a
KRB_ERROR message in response to an AS-REQ, how will
gss_init_sec_context() on the initiator's side digest this and indicate
whether additional prompting is necessary?

Dave

---

From: "Mike Swift (NT)" <[email-masked]>
Date: Wed, 19 Nov 1997 16:56:29 -0800

I'll be sending a new draft to the ID editor later this week. I added some
comments below.

- Mike

> Sent:	Tuesday, November 18, 1997 11:51 AM
> *** Kerberos V5 GSS-API implementations which do not support IAKERB should
> return an appropriate error message (GSS_S_CALL_BAD_STRUCTURE,
I don't think this needs to be specified in the draft - rfc2078 makes clear
what to return when a mechanism is handed a context token it does not
understand.

> gss_init_sec_context(), or optionally to specify GSS_C_NULL_CREDENTIAL for
> claimant_cred and GSS_C_NULL_BUFFER for input_token to use the default
> credentials.  If input_token is supplied, gss_init_sec_context() will
> perform consistency checks on input_token and on success, return the
I think that it is too restrictive to specify how credentials will be
presented. For some implementations, it may be preferable to supply a user
name / realm name/ password and let the mechanism create the AS request. I
think that given this problem, the issue of whether the mechanism generates
an AS request for the server or an AS request for a TGT can also be set
through a mechanism-specific API.