[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Last Call: 'Kerberized Internet Negotiation of Keys (KINK)' to Proposed Standard (fwd)

On Tue, Nov 29, 2005 at 06:01:15PM -0500, Chaskiel M Grundman wrote:
> >4.2.3.  KINK_KRB_ERROR Payload [...]
> >
> >  KINK implementations MUST make use of a KINK Cksum field when
> >  returning KINK_KRB_ERROR and the appropriate service key is
> >  available.  In particular, clock skew errors MUST be integrity
> >  protected.
> The kerberos API, such as it is, does not guarantee that the application 
> will have access to the ticket session key if KRB5KRB_AP_ERR_SKEW is 
> returned from krb5_rd_req. neither mit krb5 nor heimdal return the 
> decrypted ticket if krb5_rd_req fails. (current releases of heimdal do not 
> check for clock skew in krb5_rd_req! This will be corrected in a future 
> release) It does not appear that either implementation updates the keyblock 
> stored in the auth_context until after all authenticator checks are 
> complete, so that copy of the key is not available to the application 
> either.

There is no standard krb5 API...

> While implementation concerns like this are not usually critical, in this 
> case, I think they should be considered, since it is far more likely that 
> this part of the spec will be ignored than the kerberos implementations be 
> extended to make it possible for kink implementations to conform to it.

...but I tend to agree.

Ultimately some error notifications simply cannot be integrity
protected, so initiators must be prepared to receive such notifications
and deal with them, either by giving up early or retrying with a
timeout.  Attempting to do better than Kerberos V itself does for error
messages seems likely to create API problems.

The value of protecting skew error messages is this: clients can work
around server-side skew when otherwise they could not.

Such a feature too would require API work: krb5_rd_rep*() would need a
way to output skew between the client and server, and krb5_mk_req*()
would need a skew input (that would have to be used very, very

Is it wise for Kerberos V applications to be doing this sort of thing?

And should Kerberos V clients ever correct for skew other than that
between the client and the KDC?

Why can't the servers do their own KDC exchanges to discover server-side
skew?  (Why, for u2u they'd be engaging in such KDC exchanges anyways...)

I'm convinced, I think.  This feature should be removed.