Hi Jeffrey, Thanks!
> Speaking as the other author of draft-ietf-krb-wg-krb-dns-locate-03, I > have no objection to revisiting the discussion of using TXT records > Kerberos in order to further reduce the need for client side > configuration. However, I would be unhappy if the implemented > "_kerberos.<fqdn>" entry be standardized as-is. Good to hear. I have been surprised about the current spec also; I had also stumbled on RFC 1464 and didn’t dare to propose it (since I already feel like I’m pushy in trying to get TXT back installed). I wholeheartedly agree with your suggestion of > "v=<protocol><version>; [tag=value;]+" > > For Kerberos an initial version describing only the REALM might be: > > "v=krb1; r=REALM;” And with that v=krb1 you can drop the _kerberos prefix, which I assume is what you have in mind, right? A few other design choices I’ve realised are: * There might be multiple suggestions of a REALM by placing multiple TXT records under one name. This can benefit cross-realm authentication, where a remote site may suggest two or three realms to its users, for which the service name has a key in its keytab. * We could discuss whether to mention s= with a service name as well. Clients already iterate over guesses of realm names, so they too could do this, but less efficiently than when directed; especially for cross-realm applications involving public key crypto this may be a decisive argument. On the other side, it would release service availability information in DNS, which may feel improper to some. On the whole, I’d say that s= should be an optional addition. * I think walking up along the DNS chain is potentially dangerous, because it lands up in parent zones. I would prefer to stay within the realm that holds the FQDN for the service. This is possible; when a query for TXT under the service’s FQDN fails, an SOA will be released, and it incorporates the zone apex, under which the same TXT could be queried. > which would permit use to distribute other mandatory configuration in > the future. However, I could imagine other information being provided > such as pre-auth hints; and public key information for the realm. Good point. So, other character strings may be registered for use with this record, based on a TBD procedure? > This discussion would be best held on the IETF Kitten mailing list. Yes. It is currently part of my TLS-KDH proposal, but perhaps it is better to take it out and make a separate proposal for this, so people are in a position to add such things as pre-auth hints easily. Shall I write this as an I-D and post it on Kitten? Or would you want to do this and/or play an active role in it? Cheers, -Rick
smime.p7s
Description: S/MIME cryptographic signature
________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
