No mention of _kerberos TXT in RFCs / but we have DNSSEC now

[Rick van Rein]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4142 bytes
Desc: not available
Url : http://mailman.mit.edu/pipermail/kerberos/attachments/20141018/8ca0b86a/attachment.bin