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

At Tue, 29 Nov 2005 17:31:37 -0600,
Nicolas Williams <[email protected]> wrote:
> 
> > 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
> carefully).
> 
> Is it wise for Kerberos V applications to be doing this sort of thing?

When I was implementing this part of the spec using MIT krb5 and
Heimdal (when I was not yet involved with editing the draft), it was
much of a bother, though not impossible with accessing the library
internals.  The code is included in
ftp://ftp.kame.net/pub/racoon2/racoon2-20051102a.tgz, but is very
dirty, over-familiar with the library, and fragile with library
upgrades.

On the other hand, rfc1510ter will have checksummed KRB-ERROR.
Doesn't that mean we need API work anyway when rfc1510ter is
standardized, in order to extract key on the failure of krb5_rd_req()?

-- 
KAMADA Ken'ichi <[email protected]>