Subject: [Ietf-krb-wg] referrals and FAST/TLS

From: Ken Raeburn <[email-masked]>
Date: Tue, 29 Jul 2008 16:32:29 +0100

One of the big reasons that the work on the referrals draft keeps  
dragging on is that each time I look at it, it seems like I find some  
new subtle security issue having to do with not protecting the KDC  
exchange well enough.  The latest draft has yet another attempt to  
protect the integrity of the exchange, and a new section noting a  
security issue with certain kinds of renewal/proxy/validation exchanges.

Since FAST (draft-ietf-krb-wg-preauth-framework) and STARTTLS (draft- 
josefsson-kerberos5-starttls) are already taking steps to address the  
integrity of the KDC exchanges in general, it seems wasteful to try to  
solve the same problem specifically in the context of the referrals  
extension.  Both of these protocols appear to be designed with the  
intent that they be useable for every KDC exchange.

So, I propose to change the referrals draft in the next revision to  
require "a method for protecting the integrity of the KDC exchange",  
with FAST and STARTTLS drafts referenced as examples, and then remove  
all the bits of data that were added to let the client or KDC confirm  
that the exchange hasn't been messed with.  For example, I think the  
ClientReferralInfo type would no longer need to include a copy of the  
client principal name originally requested by the client, and PA- 
CLIENT-CANONICALIZED wouldn't need to have a checksum.

It's not all flowers and fluffy bunnies, though.  Neither FAST nor  
STARTTLS have been standardized yet; one or the other would need to be  
deployed in order to get secure handling of referrals and  
canonicalization.  (Yes, I'm sidestepping the "FAST vs STARTTLS"  
issue.)  I'm not sure it would even make sense to publish it as a  
standards-track RFC before FAST or STARTTLS also gets published on  
standards track.  (I suppose IPsec could provide the protection, but I  
wasn't going to try to work up such a spec.)  And if for whatever  
reason we were to decide not to standardize either one, the security  
would have to be re-added in referrals.

Comments?

Ken
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg