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

[Rick van Rein <[e-mail]>]

Hello Niall / Tony / list,

Good post, thanks!

> Don't you end up with a potentially large but sparse matrix of
> valid tag/value pairs in this model, Rick?
>
No, it's not supposed to be sparse.  If things belong together you put
them in the same KREALM record.  If they don't belong together you put
them in separate ones.  The idea is to capture what belongs together by
putting them in the same KREALM record, for brevity of DNS data.

For instance, "service" declarations would be part of a hostname,
together with the "realm" declarations supported; chances are that
www.example.com has realm "EXAMPLE.COM" and "EXAMPLE.ORG" and service
"HTTP" defined, and perhaps also "host" (for remote login) and "cifs". 
This gives rise to all combinations

HTTP/[e-mail]
HTTP/[e-mail]
host/[e-mail]
host/[e-mail]
cifs/[e-mail]
cifs/[e-mail]

Since this is located at the server name (www) rather than the
DNS-mapped realm name (example.com and example.org) this is not as
sparse as you are thinking, if I guess correctly.
 
The reason for keeping those within one KREALM RDATA structure is that
it enables me to specify one KREALM that definces service=HTTP for both
realms, and the other two could only be made available to one of the
realms.  Note that there is no explicit name for that distinction, but
we could wonder if the realm name would be the prime cause of wanting to
make such distinctions, and that is what you are addressing below.

> Would a two-stage representation of the data you need work?
> I'm thinking of normalization and foreign keys.
>
Very interesting idea.  In fact I was already doing that somewhat, with
a KREALM "reference  record" at the service name (www) that points to
the "home record" where a more elaborate KREALM "home record" is
located.  The "admin" tag would be typically something to find near the
"home record", which is indeed what I specified.  Still, you are making
it more explicit, which is indeed useful.

You are triggering a lot of thoughts with this, which is good, but it'll
need some time for me to think them over.  I started responding in
detail (left below) but it's unfinished.  It'll will take a few walks in
nature and probably lead to a modified proposal, possibly different on
details.  My start should be to clearly state the use cases for the
KREALM record, and finding the best ways of embedding that into DNS.

Thanks a lot so far!
 -Rick


> Here's an example below.
>
> ; advertise realms to which $ORIGIN belongs
> ; so that clients can perform discovery
> ; this RRset is the REALM-SET
> @ KREALM "realm" "EXAMPLE.COM"
> @ KREALM "realm" "EXAMPLE.ORG"

Here, $ORIGIN as you call it would be the hostname for the service, so
"www.example.com" for a service like HTTP/www.example.com

> ;
> ; for each realm at $ORIGIN, advertise its attributes
> ;
> ; this RRset is the ATTRIBUTE-SET for realm "EXAMPLE.COM" at $ORIGIN
> EXAMPLE.COM._realm KREALM "admin" "carl"
> EXAMPLE.COM._realm KREALM "service" "HTTP"
> ;
> ; this RRset is the ATTRIBUTE-SET for realm "EXAMPLE.ORG" at $ORIGIN
> EXAMPLE.ORG._realm KREALM "admin" "mary"
> EXAMPLE.ORG._realm KREALM "service" "imap"
>
And this too would fall under that hostname "www.example.com" and add
details.

There are two things that you've triggered.

The things I described as "home tags" are properties of the realm; the
"admin" tag is the running example.  That would not be defined for
individual services, but under the DNS-mapped realm name (which is just
reading a DNS-formatted realm name with ignored case sensitivity).  So I
would suggest to write those simply as

example.com. KREALM "admin" carl"
example.org. KREALM "admin" "mary"

Now, the service tags could be stored underneath the _realm subname. 
Interestingly, this enables wildcard notation *._realm as well, for example

example.org._realm KREALM "service" "imap"
example.com._realm KREALM "service" "host"
*._realm KREALM "service" "HTTP"

I do like this.  And although the mapping to DNS names as done here
looses the case of the realm, it is no problem, because RFC 4120
prescribes in 7.2.3.1 that "it is necessary that only one of the
possible combinations of upper- and lowercase characters be used in
realm names." -- so the case-sensitive realm name mapped to a
case-insensitive DNS-name as you do it here is supported by the Kerberos
specification.

Note my assumption -- you meant to lookup realm names under _realm
rather than the hostname of a server.

The cost of this is one more DNS query, but targeted at the precise
thing we're looking for, so no search pattern.

Defining a "service" tag in this manner makes it impossible to have a
catchall "realm" tag for an entire domain and apply it to everything. 
But that was also the case with the initial proposal I made.  Drop
"service" tags and it does become possible.  We could debate whether it
is a good idea to always specify the "service" tag and not make the
upward search that I've been looking to settle securely.  I suppose
maximum flexibility is desirable here; especially because the Kerberos
client is built into a protocol-specific client, so it'll know if the
service is available.  That in fact enables another approach, which is
to use service names as the index instead of realm names.

; Alternative approach
HTTP._ksvc KREALM "realm" "EXAMPLE.COM"
HTTP._ksvc KREALM "realm" "EXAMPLE.ORG"
imap._ksvc KREALM "realm" "EXAMPLE.ORG"

The client could now lookup the service that it knows it should use,
under the server's name.  So http://www.example.com would query for
KREALM at HTTP._realm.www.example.com -- again a pattern that won't work
well with wildcards that capture an entire domain, and again that's
related to defining a service in the first place; a wildcard KREALM
would refer everything but this record might be overridden for services,
which feels right.

Notes: I'm not sure if case distinction is getting a problem here.  I'm
assuming the service name doesn't need an underscore prefix, but I don't
know the habits here, SRV does it of course.

> If the realm isn't really "at" $ORIGIN, a CNAME reference might be
> appropriate.
>
Hmm, that sounds like a nest of hornets to me, but it might work.  I'm
not sure it is the best way though; references should contain their
KREALM explicitly and point at the realm name, and KREALM records
defining a home location for kerberos are always going to be local to
the DNS-name that they sort-of claim to hold.

> If this approach risks string overflow in the owner names, an
> alternative might be to use
>
> @ KREALM <realm-handle> <realm-name>
>
> for the REALM-SET, and use the same handle in composing the owner
> name of the ATTRIBUTE-SET, so:
>
> @ KREALM "r1" "EXAMPLE.COM"
> @ KREALM "r2" "EXAMPLE.ORG"
> r1._realm KREALM "admin" "carl"
> ; ...
> r2._realm KREALM "admin" "mary"
>
> As I write, it occurs to me that it may be more "natural" to assign
> the RDATE fields in the REALM-SET in the reverse order. That's a
> detail which just needs to be unambiguously specified. 8-)
>
> This-all seems to keep the option of re-using HINFO as Tony suggested.
>
> ATB
> Niall
>
> Rick van Rein <mailto:[e-mail]>
> 11 September 2015 13:14
> Hi Tony,
>
> Thanks for thinking along!
>
>
> That would make it impossible to express everything that is desired.
> The level of alternation that you are using here has been reserved for
> independent statements; the combined tag=value statements form a
> cross-product; for example all the realms mentioned combine with all the
> admins mentioned in the same RDATA portion. If another realm has
> another admin set it will be specified in a separate KREALM.
>
> This is why I end up with a variable list of tag=value assignments under
> one KREALM, and as explained that strikes me as an oddball solution in
> DNS. Do you agree?
>
> Note that more base64 data is incorporated into DNS already, for
> instance certificates (where, I admit, there is no choice due to the
> tightness of the signatures).
>
> -Rick
> Tony Finch <mailto:[e-mail]>
> 11 September 2015 13:09
>
> I was thinking
>
> @ KREALM "realm" "EXAMPLE.COM"
> KREALM "realm" "EXAMPLE.ORG"
> KREALM "admin" "carl"
> KREALM "admin" "mary"
> KREALM "service" "HTTP"
> KREALM "service" "imap"
>
> Tony.
> Rick van Rein <mailto:[e-mail]>
> 11 September 2015 13:04
> Hi Tony,
>
>
> Ah. That would call for more complex parsing. I hadn't expected that
> to be preferred by the DNS community, over simplicity. Is the reason
> readability of zone files?
>
> HINFO uses precisely 2 strings, with KREALM it'd be variable, but
> could be done with something like
>
> @ IN KREALM ( "realm=EXAMPLE.COM" "realm=EXAMPLE.ORG"
> admin=carl "admin=mary"
> service=HTTP "service=imap" )
>
> The parser then MAY check the presence of an = sign in the string but
> otherwise keep tag and value together.
>
> Each of these strings would then independently translate to a separate
> <character-string>, namely
>
> 12 72 65 61 6c 6d 3d 45 58 41 4d 50 4c 45 2e 43 4f 4d
> 12 72 65 61 6c 6d 3d 45 58 41 4d 50 4c 45 2e 4f 52 47
> 0b 61 64 6d 69 6e 3d 63 61 72 6c
> 0b 61 64 6d 69 6e 3d 6d 61 72 79
> 0d 73 65 72 76 69 63 65 3d 48 54 54 50
> 0d 73 65 72 76 69 63 65 3d 69 6d 61 70
>
> But that's a variable number of strings in the textual format *and* in
> the RDATA format. The RDATA is preceded by RDLENGTH, so it would be
> possible, but I am hesitant about such new approaches to DNS.
>
> Alternatively, we could incorporate separator characters such as
> comma's but that would constrain the possible string values (and call
> for even more escaping and another level, which isn't my favourite
> place to go).
>
> I expect an uproar from both alternatives to be honest. Or not?
>
> -Rick
> Tony Finch <mailto:[e-mail]>
> 11 September 2015 12:18
> Rick van Rein <[e-mail]> wrote:
>> I can't seem to find a tag/value definition format for HINFO though; can
>> you give me a reference?  I wanted to avoid requesting a parser that
>> specific, but if it's already there then it's certainly a good idea.
>
> HINFO is just a pair of strings. (Similar to a TXT record, except a TXT
> record can have any number of strings.)
>
> https://tools.ietf.org/html/rfc1035#section-3.3.2
>
>> Note that ASN.1 is a home game to Kerberos, so from that perspective the
>> wire format makes a lot of sense, I think.  You are not proposing to
>> change the wire format, right?
>
> Yes, I think the wire format and presentation format should be native DNS
> not ASN.1.
>
> Tony.