Re: New RRtype "KREALM" in draft-vanrein-dnstxt-krb1-02.txt

Hi all,

Clearly, I should take care of readable / writeable KREALM records,
rather than stuffing things in base64.  Very well...

1.
I propose to introduce a "groupname" in each KREALM, used to group
various records together like I wanted to do with KREALM records before.
Where I wrote
    KREALM "realm=A,realm=B,realm=C,service=S,service=T"
    KREALM "realm=D,service=S"
I was avoiding spelling out a cartesian product; the above was
describing the realm-service combinations
    A-S, B-S, C-S, A-T, B-T, C-T, D-S
An explicit group (arbitrary byte string that matches[*] to keep data
together like the RDATA above did) can be used as a first argument like in
    KREALM 1 realm A
    KREALM 1 realm B
    KREALM 1 realm C
    KREALM 1 service S
    KREALM 1 service T
    KREALM 2 realm D
    KREALM 2 service S
This enables the same compact notation to describe cartesian products,
it lets us define alternate groups of those to handle exceptions and as
a way to specify one-on-one definitions, and it fits into a fixed RDATA
form that can be read and written by DNS admins without base64 tools. 
It also exploits existing DNS structures to manage data lists.

[*] Don't know what "match" means yet.  We might go for something kinky
with wildcards, but that would complicate the data, complicate using it,
and interpret the byte sequence in a particular manner, so my current
gut feeling is to avoid being fancy and just use strcmp()

2.
There are three or four use cases that I see as valuable at this time:
2a. Kerberos client (or his KDC) knows service name + hostname, and
wants to find a realm name
2b. Kerberos node wants to find the case-sensitive realm name for a DNS
name, in a secure manner
2c. Kerberos node wants to find manual contact information for a realm
administrator (possibly "admin" pointers to a defining DNS node with RP,
CERT, ...)
2d / optional.  Kerberos client wants to perform service discovery under
a realm and/or at a DNS name
Based on these, I should be able to formulate the keys and search
patterns for the data.  It will probably also help me further
materialise the home record distinctive feature.

It will take me some time to collect my thoughts on this.  Also, I
intend to discuss it at the Kitten WG.

Thanks!
 -Rick

_______________________________________________
dnsext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsext