Subject: RE: Handling of krb_error checksums

From: "John Brezak" <[email-masked]>
Date: Wed, 23 Jan 2002 15:35:36 -0800

As long as the typed hole for e-data is preserved. We also need to move
forward on at least the use of TypedData for constructing the e-data in
the krb-error.

Also one other observation - for the "2" messages can the protocol
version number be moved (copied) to the outer asn.1 encoding that
contains the checksum? This would make the protocol version number
useful in the future. Same is true for the ticket version number.

> -----Original Message-----
> From: Sam Hartman [mailto:[email-masked]] 
> Sent: Wednesday, January 23, 2002 12:34 PM
> To: [email-masked]
> Subject: Handling of krb_error checksums
> 
> 
> We briefly discussed krb_error checksums at the working group 
> and I indicated I would get back with a more detailed 
> proposal.  Here is that proposal.  I believe this is the 
> right direction to go, although it does complicate the 
> krb_error message a bit.
> 
> There are three places in the protocol where krb-errors can be
> generated: in response to AS requests, in response to TGS 
> requests and in response to ap-reqs.
> 
> We believe we can provide general criteria for when to sign 
> these errors.  First we want to avoid signing a request when 
> we aren't sure what key to use for the signature.  Clients 
> are very likely to ignore errors with checksums that do not 
> match, and this is to be encouraged so creating situations 
> where clients receive bad checksums because the server 
> guessed what key to use and guessed incorrectly is a bad 
> idea. Secondly, we want to avoid making it too easy to mount 
> known-plaintext attacks especially against long-term keys.  
> We certainly must not mandate that a checksum be created in a 
> long-term key when the server would have been unwilling to 
> encrypt text in a long-term key for a successful request.  
> Similarly we want to avoid forcing an implementation to sign 
> an error in a long-term key when the request failed because 
> preauthentication should have been provided to avoid exposing 
> the long-term key.
> 
> Whithin these constraints though we want to require errors be 
> signed whenever possible to avoid DOS attacks.  Thus the KDC 
> needs some mechanism to communicate preauthentication back to 
> the client so the client can know what key to use to verify 
> the error.  Currently we have such a mechanism for 
> preauthentication required errors, but we need to extend that 
> mechanism.  So we propose that all KDC-REQ errors need to be 
> able to carry preauth information even if they are not 
> preauthentication required errors.
> 
> Unfortunately this means that krb-error ends up with a lot of 
> typed holes.  It already has edata.  This preauth requirement 
> means that we add a hole to carry preauth data to every error 
> other than preauth required.  We already planned on replacing 
> the use of typeddata stored in the edata hole with  a typed 
> hole in the message.  
> 
> So basically we want to mandate that if the authentication of 
> the request succeeds (preauth for AS-req, authenticator and 
> checksum verification for others) and if the server knows 
> what key would be used for a successful reply, then the error 
> is signed.  IS this the direction we want to take?
> 
> 
> 
> --Sam
>

---

From: Sam Hartman <[email-masked]>
Date: 23 Jan 2002 20:05:23 -0500

>>>>> "John" == John Brezak <[email-masked]> writes:

    John> As long as the typed hole for e-data is preserved. We also
    John> need to move forward on at least the use of TypedData for
    John> constructing the e-data in the krb-error.

e-data isn't a typed hole, that's the problem.

    John> Also one other observation - for the "2" messages can the
    John> protocol version number be moved (copied) to the outer asn.1
    John> encoding that contains the checksum? This would make the
    John> protocol version number useful in the future. Same is true
    John> for the ticket version number.

I think so.  I believe the reason this was not done is that you and
Matt were expected to object and it didn't seem worth arguing over.
Tom, comments?