Subject: [kitten] I-D Action: draft-vanrein-dnstxt-krb1-00

From: Rick van Rein <[email-masked]>
Date: Sun, 19 Oct 2014 16:48:15 +0200

Hello,

After a discussion on [email-masked] about the TXT records that never made it into a standard, we realised that the recent success of DNSSEC provides a new opportunity for this dnsname-to-realmname mapping.  Below is a proposal to that end.

Title: Finding the Kerberos Realm of a Service in DNS
Draft: draft-vanrein-dnstxt-krb1-00
Location: http://datatracker.ietf.org/doc/draft-vanrein-dnstxt-krb1/

This is part of my endeavour to move Kerberos towards realm crossover, for which finding a service’s realmname can be all but trivial.

Any comments on this are highly appreciated!

Cheers,

Rick van Rein
OpenFortress / ARPA2

---

From: [email-masked]
Date: Sun, 19 Oct 2014 19:29:37 +0200

Hi Rick,

thanks for this post.

Comment: having read the draft, it appears that a client can reliably determine in which primary realm (domain) it currently resides once your proposals are implemented. But could you add some extra narrative on how this aids you ultimate aim of cross realm trust relationship negotiation. Probably only a small addition, but it would help those of us not yet attuned to this mind-set.

Incidentally, this draft validates an idea of mine from a paper that was essentially a distillation of my Masters thesis and was subsequently published in December 2013. Namely. "The client can determine the ID-TGS by various means outside this discussion, for example it could be included in DNS information." Although this theme was not the main thrust of that paper.

Link to paper: http://www.ijoee.org//index.php?m=content&c=index&a=show&catid=35&id=61

Hoping to hear from you

Dean Rogers

Gesendet: Sonntag, 19. Oktober 2014 um 16:48 Uhr

Von: "Rick van Rein" <[email-masked]>

An: [email-masked]

Betreff: [kitten] I-D Action: draft-vanrein-dnstxt-krb1-00

Hello,

Cheers,

Rick van Rein

OpenFortress / ARPA2

_______________________________________________

Kitten mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/kitten

---

From: Rick van Rein <[email-masked]>
Date: Sun, 19 Oct 2014 22:15:54 +0200

Hi Dean,

> having read the draft, it appears that a client can reliably determine in which primary realm (domain) it currently resides once your proposals are implemented. But could you add some extra narrative on how this aids you ultimate aim of cross realm trust relationship negotiation. Probably only a small addition, but it would help those of us not yet attuned to this mind-set.

Below is the rationale that you ask for, but my experience is that “visions” in drafts are a source of criticism, because they are too vague for the IETF process.

There are two sides to how I think realm crossover can be achieved; only the first is serviced by draft-vanrein-dnstxt-krb1-00:

1) Client software usually finds a server’s DNS-name from a URL or a NAI or similar.  So it knows the host or domain name of the service; and being a specific protocol client, it also knows the Kerberos name for the service it is trying to use.  What is missing is the realm name to use with service.  Current implementations rely on local/static settings for that on the client machine and/or the KDC.  The TXT records proposed here enable the client to at least know what realm to ask for.

2) KDC software (or libkrb5) may then be requested to contact a realm that it has not encountered before.  It could use its PKINIT certificate to authenticate as a client to the remote KDC, otherwise using the normal PKINIT exchange, to get a cross-realm krbtgt.  The parties may validate the PKINIT certificates through DANE and DNSSEC.  The shared secret between the parties may be created with PKINIT's Diffie-Hellman exchange, so it has Perfect Forward Secrecy.

The second part is likely to raise policy questions (under what conditions to trust a remote realm) and may introduce a need for “reliability levels”, but it helps that Kerberos is only about authentication, not authorisation.  The potential result is very good; it makes Kerberos authentication possible between domains that have not explicitly been coupled.

> "The client can determine the ID-TGS by various means outside this discussion, for example it could be included in DNS information.”

Yes, and setting such things in DNS are advised on
	http://web.mit.edu/kerberos/krb5-1.6/krb5-1.6.3/doc/krb5-admin.html#Mapping-Hostnames-onto-Kerberos-Realms
but at the same time the advise is not to rely on such things from unsecure DNS.  My I-D simply proposes a way to reliably extract the information from DNS, using DNSSEC to reliably authenticate the data found.

Thanks for your response,

Rick van Rein
OpenFortress

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 27 Oct 2014 14:13:55 -0400 (EDT)

> Any comments on this are highly appreciated!

It might be good to also solicit feedback from the DNS types; I'm not
actually sure if that means [email-masked] or somewhere else.  (I am not a
DNS type, so my comments will be limited in scope.)

In section 4, does "the client MUST dismiss any DNS responses that are not
Insecure, Bogus or Indeterminite" have an extra 'not'?

I don't really understand the case-mapping text in the second paragraph of
section 6.1 (there don't seem to be any examples that use it).

Also in 6.1, I don't think the phrase "it is useless to lookup a Kerberos
ticket for ftp.example.com" is a valid use of "kerberos ticket".

"multilple" is a typo

-Ben

---

From: Rick van Rein <[email-masked]>
Date: Tue, 28 Oct 2014 09:31:16 +0100

Hi Benjamin,

> DNS type, so my comments will be limited in scope.)

Good idea.  I am a DNS type, and a DNSSEC type, but there are ones who
are better for sure.

> Insecure, Bogus or Indeterminite" have an extra 'not’?

Well spotted!  I had caught it after publication and it will be gone next time.

> section 6.1 (there don't seem to be any examples that use it).

Examples are a good idea, DNS->realm,

openfortress.nl -> OPENFORTRESS.NL
=example.=c=o=m —> eXAMPLE.com

I need to figure out if the TXT records are really case-insensitive, I found a
text saying it may not be.  Then the aforementioned original mapping in
DNS can be removed.

> ticket for ftp.example.com" is a valid use of "kerberos ticket”.

Do you mean I should say “service ticket”?  That is more accurate indeed.

Thanks!
 -Rick

---

From: Nico Williams <[email-masked]>
Date: Tue, 28 Oct 2014 10:56:30 -0500

On Mon, Oct 27, 2014 at 02:13:55PM -0400, Benjamin Kaduk wrote:
> actually sure if that means [email-masked] or somewhere else.  (I am
> not a DNS type, so my comments will be limited in scope.)

The preference nowadays is to add new RR types wherever possible.

For most cases a DNS resolver style search of a hostname's domain should
suffice to find its realm, using FAST to protect each TGS in the
process, and DNSSEC for every KDC search.  But it is important to not
cross zone cuts in this process, and to limit the number of
domains/realms searched, and to not search TLDs.

E.g., foo.bar.xyz.example, with a zone cut from example. to xyz.example,
could have either BAR.XYZ.EXAMPLE or XYZ.EXAMPLE as its realm, but if
there's a zone cut from xyz.example. to bar.xyz.example. then it could
only have BAR.XYZ.EXAMPLE as its realm.

(Perhaps each zone could indicate whether it's OK to search the parent's
realm.)

If a service in bar.xyz.example. has a realm of, say, FOO.EDU, then a
search won't work.  A 90% solution should suffice.

Nico
--

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 28 Oct 2014 16:05:29 -0400 (EDT)

> Do you mean I should say “service ticket”?  That is more accurate indeed.

The verb "lookup" is problematic as well.
I guess "request" would be best.

-Ben

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 28 Oct 2014 22:50:26 +0000

> Insecure, Bogus or Indeterminite" have an extra 'not'?

You might want to compare with the SMTP with DANE DNS error handling text:

    https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-13#section-2.1.1

The term "indeterminate" sadly has different meanings in RFC 4033
and 4035.  So one needs to be specific about which meaning one has
in mind.  The 4035 variant is essentially a lookup failure condition,
while the 4033 variant is essentially "insecure" for lack of a suitable
trust-anchor rather than an opt-out.

I explain that "bogus" and "indeterminate" (4035) are error conditions
are to be treated in the same way as timeouts, and other transient
problems.

I also explain that "NXDOMAIN" is not an error condition (given
signed proof of non-existence if the containing zone is signed).

With that out of the way, one processes "secure" responses, treates
"insecure" responses and "NXDOMAIN" as absence of data, and treats
all other outcomes as transient errors (applying whatever logic is
appropriate in that case).

-- 
	Viktor.

---

From: Rick van Rein <[email-masked]>
Date: Wed, 29 Oct 2014 09:25:35 +0100

Viktor,

Thanks!

> trust-anchor rather than an opt-out.

I wasn’t aware of this difference.  Will dive in.

> are to be treated in the same way as timeouts, and other transient

Yes, we do need secure denial before we can safely conclude “it’s not
there, let’s try somewhere else”.

> signed proof of non-existence if the containing zone is signed).

Indeed, the habit of TXT records that is currently described (but at the
same time discouraged to rely on) is to try in multiple locations, moving
up from a DNS name to the DNS root.  (I don’t think passing through
the zone apex is a good idea though, so I’m changing that here.)

> appropriate in that case).

Almost.  “insecure” leads to a complete breakdown of the process,
because it is not possible to establish that a name is absent.  If we’d
do as you describe, a DoS could be mounted on one label, and the
next one up could be forced instead.  Absense of data is important
information in this search sequence and must therefore be secure.

-Rick

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 29 Oct 2014 14:49:14 +0000

On Wed, Oct 29, 2014 at 09:25:35AM +0100, Rick van Rein wrote:

> Almost.  ?insecure? leads to a complete breakdown of the process,
> because it is not possible to establish that a name is absent.

Sure, but this is expected, the domain has opted-out of DNSSEC.

> If we'd do as you describe, a DoS could be mounted on one label,

DoS does not cause responses to appear "insecure".  It can only
cause (4035) "indeterminate".

> and the

Speaking of searches, if we're "searching" for a realm.  My proposal
is to avoid "searches" entirely.  By introducing a new RRTYPE (not
overloading TXT), we avoid all ambiguity and no longer need an
"_kerberos" prefix, but more critically, it now becomes possible
to usefully employ wildcard RRs:

	athena.mit.edu. 	IN KRBREALM "ATHENA.MIT.EDU"
	*.athena.mit.edu.	IN KRBREALM "ATHENA.MIT.EDU"

With this any host under athena.mit.edu gets the right realm with
a *signle* DNS lookup, but sub-domains (including individual hosts)
can override the data with their own wildcard:

	dev.athena.mit.edu.	IN KRBREALM "DEV.ATHENA.MIT.EDU"

The past practice of walking up the tree is both latency incurring
and dubious from a security perspective.  And expecting DNS clients
to act differently across zone cuts is a bad idea, zone cuts are
not meant to imply explicit administrative boundaries, they are
just about data management.

-- 
	Viktor.

---

From: Nico Williams <[email-masked]>
Date: Wed, 29 Oct 2014 09:53:08 -0500

FWIW, searches need not add latency.  You can asynchronously fire off
all the lookups needed.  (Yes, I know, would that actual
implementations did that.)

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 29 Oct 2014 14:57:09 +0000

> implementations did that.)

That's fine for data you know you'll need, but abusive when it is
data you almost certainly won't (_kerber.com, and the like, for
example).  Far cleaner to make exactly one lookup, and place the
burden of reducing data duplication on the zone publisher (who
can publish a wildcard).

-- 
	Viktor.

---

From: Rick van Rein <[email-masked]>
Date: Wed, 29 Oct 2014 16:02:56 +0100

Ah!

> Sure, but this is expected, the domain has opted-out of DNSSEC.

This is a vital point.  DNS records are not reliable for this purpose
if they are not signed.  DNSSEC is a MUST for this entire process.

> cause (4035) "indeterminate”.

Sorry, I meant Kaminsky — which is an overdose of responses, but
indeed not quite the same as a DoS.

> 	*.athena.mit.edu.	IN KRBREALM “ATHENA.MIT.EDU"

I dropped the _kerberos prefix too, which was possible by starting
the TXT record with “v=krb1” — and the draft actually wildcards, just
as you say.  The one difference: *.a.m.e is only required for overrides
of the a.m.e — and there is an option to say “no realm for this one”
of course.  That’s a different default, but it’s just as expressive as
what you’re saing here.

You are not the first to suggest a separate record type, and I prefer
it too, was just a bit scared for claiming such a valuable resource.
Then again, SPF does it too, and is similar in nature.  And it started
as TXT, so we’ll see that forever...

> 	dev.athena.mit.edu.	IN KRBREALM “DEV.ATHENA.MIT.EDU"

Yes, a single DNS lookup instead of two as I propose in the draft.

> and dubious from a security perspective.

I’m glad you agree with that idea of the draft.

> And expecting DNS clients

Really?  The wording “SOA” is “Start Of Authority”, which is just
what triggers the thought of looking in the zone apex.

Thanks for thinking along,
 -Rick

---

From: Rick van Rein <[email-masked]>
Date: Wed, 29 Oct 2014 16:06:19 +0100

Viktor,

On 29 Oct 2014, at 15:57, Viktor Dukhovni <[email-masked]> wrote:

> example).

That doesn’t apply in my draft; there’s going to be two lookups max.

I’m learning that that isn’t immediately obvious from my text.

> Far cleaner to make exactly one lookup, and place the

Am thinking that option through.  Wildcards are nasty beasts that I would
prefer not to rely on very heavily, as in, for the standard case.  Especially
their combination with DNSSEC is solved, but very, very hairy.

-Rick

---

From: Rick van Rein <[email-masked]>
Date: Wed, 29 Oct 2014 16:12:29 +0100

Nico,

> implementations did that.)

It’s not hard to implement with adns.  But it won’t work in the specific case
on dnstxt-krb1, which pulls the zone apex name from the failure and then
issues the second query at that point in the DNS.

-Rick

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 29 Oct 2014 15:27:45 +0000

> their combination with DNSSEC is solved, but very, very hairy.

At this point, wildcards are well behaved with DNSSEC.  There exist
unofficial DNSSEC patch-sets for djbdns servers that get wildcards
wrong.  Operators of such servers need to avoid wildcards or switch
to an RFC-compliant server.  Otherwise, for the vast majority of
domains wildcards work just fine.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 29 Oct 2014 15:30:32 +0000

On Wed, Oct 29, 2014 at 04:12:29PM +0100, Rick van Rein wrote:

> It?s not hard to implement with adns.  But it won?t work in the specific case

This is not a good idea.  The zone apex can be too far removed from
the leaf node.  There is no mandate for a zone cut at every non-leaf
label.  You're reading too much structure into the incidental
division of DNS data into zones.  Don't do that!

-- 
	Viktor.

---

From: Rick van Rein <[email-masked]>
Date: Wed, 29 Oct 2014 16:35:08 +0100

Hi,

> The zone apex can be too far removed from
> label.

Understood, but that is not a problem.

As far as wildcards go, I’m concerned about schemes that overlap:

	*.a.b.c.com	IN TXT “v=krb1”					; no realm for anything under a.b.c.com
	*.b.c.com		IN TXT “v=krb1;r=EXAMPLE.COM”	; realm EXAMPLE.COM for anything under b.c.com
	b.c.com		IN TXT “v=krb1;r=EXAMPLE.ORG”	; realm EXAMPLE.ORG for exact match of b.c.com

> You're reading too much structure into the incidental

I don’t understand the underlying argument that must be underlying this.

-Rick

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 29 Oct 2014 15:43:59 +0000

On Wed, Oct 29, 2014 at 04:35:08PM +0100, Rick van Rein wrote:

> As far as wildcards go, I?m concerned about schemes that overlap:
> 
> 	*.a.b.c.com	IN TXT ?v=krb1?					; no realm for anything under a.b.c.com

I was assuming you're not going to continue to abuse TXT records.
Sorry, have not yet read the proposal in detail.

The DNS folks at IETF are IIRC discouraging TXT overloading.  If
we're implementing a new DNSSEC-based realm-of-host mapping, that
is in any case different from the ad-hoc MIT and Heimdal feature,
then I think this needs its own RRTYPE, which removes the ambiguity.
Otherwise, you need to employ "_kerberos." prefixes, which IIRC
still work with DNSSEC wildcards:

	_kerberos.*.example.com.  IN KRBREALM ...

but we should not need to go there.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 29 Oct 2014 16:01:28 +0000

On Wed, Oct 29, 2014 at 04:02:56PM +0100, Rick van Rein wrote:

> > cause (4035) "indeterminate?.
> 
> Sorry, I meant Kaminsky ? which is an overdose of responses, but

This still can't cause responses to appear "insecure", rather MiTM
attacks can cause "insecure" results to be altered.  That's to
be expected.

Therefore, "insecure" results are treated as absent (are ignored
whether modified or not).

> the TXT record with ?v=krb1? ? and the draft actually wildcards, just
> of the a.m.e ? and there is an option to say ?no realm for this one?
> of course.  That?s a different default, but it?s just as expressive as
> what you?re saing here.

I would avoid overloading TXT records, define an appropriate RRTYPE
carrying a realm and whatever other data you deem appropriate.
Ideally a structured RRTYPE rather than just text interpreted by
the client.

> it too, was just a bit scared for claiming such a valuable resource.

On the contrary, this is NOT a valuable resource, there 64K possible
RRtypes, we are far from exhausting any significant fraction.

> as TXT, so we?ll see that forever...

The guidance was improved since SPF.  And you don't want to fetch
and discard all that SPF bloat on every kerberos realm query.

> Really?  The wording ?SOA? is ?Start Of Authority?, which is just

SOA is not meant to imply anything other than "this is a zone cut".
This carries no application semantics.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 29 Oct 2014 17:03:01 +0000

> Ideally a structured RRTYPE rather than just text interpreted by

    http://tools.ietf.org/html/rfc7208#section-3.1

    The circumstances surrounding SPF's initial deployment a decade
    ago are unique.  If a future update to SPF were developed that
    did not reuse existing SPF records, it could use the SPF RR
    type.  SPF's use of the TXT RR type for structured data should
    in no way be taken as precedent for future protocol designers.
    Further discussion of design considerations when using new DNS
    RR types can be found in [RFC5507].

Note, the still-born "SPF" RRtype carries textual data, so that
remains an option, but if we are confident what information we want
to convey in a kerberos realm record, it would be better if that
were more strictly structured.

Should realm names carried in DNSSEC be (for example) restricted
to be well-formed DNS domains?  Otherwise how does one find the
KDCs for said realms?

What are the IDNA issues for realm names?  Should the realm be in
A-label or unicode form?

These issues need a bit more thought.

-- 
	Viktor.

---

From: Rick van Rein <[email-masked]>
Date: Wed, 29 Oct 2014 18:20:06 +0100

Hi,

As it turns out, wildcards in DNS won’t work at all, not even as the
simple variation that I defined.

RFC 4592, "The Role of Wildcards in the Domain Name System”
explains that the exitence of a name will stop the wildcard at that
name, and any subname, from functioning.  This is true even if
the existing name has a different RRtype than the one queried
and carried by the wildcard.

I also tried this out on my ods-signerd -> nsd chain:

*.wildcarddemo  3600    IN      TXT     "voorbeeldje"
a.wildcarddemo  3600    IN      TXT     "subvoorbeeldje"
b.wildcarddemo  3600    IN      A       123.45.67.89

dig a.wildcarddemo txt -> NOERROR, TXT “subvoorbeeldje”
dig b.wildcarddemo txt -> NOERROR, (no data)
dig c.wildcarddemo txt -> NOERROR, TXT “voorbeeldje”
dig d.wildcarddemo txt -> NOERROR, TXT “voorbeeldje”

The same when querying x.y.z.a…, x.y.z.b… and so on.

And, in our situation we start from a server.  Usually, that’ll mean
we have an AAAA record, and perhaps also one of those old A
records ;-)  But we cannot use the same name, or with _kerberos
prefixed, to find a wildcard for the realm.

Going up one level is not safe either, you might land in another
realm of control of security.

The primary option is to define the realm name record exactly
for the servername, without wildcard.  A lot of work, but linear in
the number of services, so doable in itself.  To optimise admin
chores, the only solution that I see is to look at the verified denial
to find a “central” place of authority.

1) Look at the RRSIG, it holds the zone apex, usually, as a
pointer to the DNSKEY records.

2) Look at the SOA that is usually sent along with NXDOMAIN,
and which is also validated; it holds the zone apex.  SOA is an
optional, but common additional bit of information.  It might be
said that an admin should either use a “neat” DNS server or
otherwise specify the Kerberos realm for each of his hosts, but
that is not very friendly.

Of the two, RRSIG is more certain, less likely to be cut off and
it mirrors trust relationships.  The one in charge of your DNSKEY
is the one who can decide where to point clients at, so it is not
such a wild thought to be using that reference to find the realm
name in a “central” place.  (Note that whatever notion of “central”
you pick, there are going to be paranoid schemes.  They can all
be circumvented by a “normal” DNS setup and/or adding explicit
realm name records for a servername.)

Now, it is a matter of taste whether we should want this to save
the work of the DNS admin, who already sets up one or more
AAAA records, one or more A record, and should now add a realm
descriptor as well.

Cheers,
 -Rick

---

From: Nico Williams <[email-masked]>
Date: Wed, 29 Oct 2014 12:33:15 -0500

> What are the IDNA issues for realm names?  Should the realm be in

Oh no, you went there :)  The Kerberos community tried to tackle the
I18N issues in 2002 and it was too soon and ETOOHARD; I18N got dropped.

I was talking to Tom about this the other day.  PKCROSS and Rick's I-Ds
will force us to reckon with I18N, finally.

My strawman:

 - Declare uses of Kerberos protocol elements to carry domainnames or
   DOMAIN-style realm names to be IDNA-unaware domainname slots: they
   may NOT carry U-labels; ToASCII() must be used.

   For example:

    - in RFC4120 Realm slots: use A-labels only for DOMAIN-style[0]
      realm-names, with all labels up-cased (to follow existing
      convention, why not?);

    - in RFC4120 PrincipalName name-string slots of host-based names
      (NT-SRV-HST[1]), use A-labels only for hostnames.

   The alternative would be to say that hey, existing implementations
   are putting UTF-8 (let's not speak much of just-send-8 non-UTF-8
   uses) in these IA5String elements and we have no choice but to
   standardize that, ugly and ASN.1 tool breaking though that might be.

 - Do something about interop with existing just-send-UTF-8 (and maybe
   some non-UTF-8, non-ASCII?) realms and principals.

   My preference would be to give some advice as to how to "alias"
   realms (e.g., make full use of ETYPE-INFO2), and let the implementors
   figure out the rest (it's doable).  How much normative and
   informative text to write about this is to be seen.

 - The GSS-API needs an update to say that the buffers used for
   import/export name are in the caller's locale (not "Latin-1"), OR add
   new variants of those functions that use the caller's locale AND/OR
   add new variants that only use UTF-8.  In first case the hostname
   slots (in host-based type name-types' generic syntax) must be
   IDNA-aware, while in the latter case then the hostname slots in the
   originals surely must be IDNA-unaware (right?).

 - Make klist, and related UIs apply ToUnicode for display purposes.

   The details here are not relevant on this list.  But there are a lot
   of API details, e.g., does krb5_sname_to_principal() apply ToASCII(), or
   its callers?  do krb5_unparse_name*() apply ToUnicode?  Surely they
   must!  But what about changing the name-type of a krb5_principle
   to/from NT-SRV-HST?  And so on.

There's probably more to it than this, but this is just idle musing
without too careful analysis (though informed by many past discussions
of the matter).

Nico

[0] Whereas when using a Realm element to carry an X.500-style realm
    name then presumably RFC5280 rules would apply, except that in
    RFC5280 RDNs can be UTF8String, but Realm is a KerberosString, which
    is an IA5String, so presumably *all* domainname label slots -by
    convention or otherwise- in a Realm, must be treated as
    IDNA-unaware.  Thankfully we don't have a lot of X.500-style realm
    use...)

[1] Ditto NT-SRV-XHST, except that thankfully that is not used.

---

From: Nico Williams <[email-masked]>
Date: Wed, 29 Oct 2014 12:35:37 -0500

Oy!  I meant to change the Subject.  Please respond to this message for
proper threading, or else change the Subject.

My strawman:

   For example:

Nico

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 29 Oct 2014 17:43:47 +0000

On Wed, Oct 29, 2014 at 06:20:06PM +0100, Rick van Rein wrote:

> As it turns out, wildcards in DNS won?t work at all, not even as the

Yes, of course you're right about that.  I lost track of that
important detail.  I still don't like imputing the zone apex from
the SOA, and skipping intermediate sub-domains.

-- 
	Viktor.

---

From: Nico Williams <[email-masked]>
Date: Wed, 29 Oct 2014 15:00:23 -0500

BTW, I'm not opposed to just using UTF-8 in the RFC4120 IA5String
slots.  It'd be hacky, but all of the existing implementations... fail
to limit themselves to printable ASCII in those slots, and it's
difficult to ignore reality.

But declaring those slots to be IDNA-unaware is the orthodox approach,
and we should first convince ourselves that the orthodox approach is
unworkable before we take the unorthodox path.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 30 Oct 2014 15:41:46 +0000

> I18N issues in 2002 and it was too soon and ETOOHARD; I18N got dropped.

The dust has settled since then, and it is now more clear what to
do.  Even email addresses are going UTF-8 with EAI (which Postfix
will support as of 2.12 or 3.0, whatever it ends up being called).

Yes, the DNS A-label form appears on the wire in DNS queries, and
is to be used to match DNS subjectAltName values in certificates.

However, the "canonical" name of an internationalized realm really
should be UTF-8.  Thus unicode realm names need to be converted to
A-labels for DNS queries (host->realm or SRV record lookup).

The realm of a principal on the wire in Kerberos should then always
be unicode.

>    may NOT carry U-labels; ToASCII() must be used.

I think this is not the right future direction.  The wire format
Kerberos protocol elemets should be unicode, as should principal
names in keytabs, the Kerberos database, ...  If some data-store
is not UTF-8 capable, then that access to that datastore needs to
perform conversions between the wire form and the storage form.

-- 
	Viktor.

---

From: Nico Williams <[email-masked]>
Date: Thu, 30 Oct 2014 11:56:09 -0500

> will support as of 2.12 or 3.0, whatever it ends up being called).

Well, even then some things were clear.

> is to be used to match DNS subjectAltName values in certificates.

That's because updating the DNS on the wire protocol was deemed either
too difficult or not worth the trouble.

> The realm of a principal on the wire in Kerberos should then always

That neither follows nor is what IDNA says.  Though most everyone will
agree that minimizing the need for ToASCII() and ToUnicode() calls would
be nice, and *that* does mean sending UTF-8 on the wire would be nice.

> perform conversions between the wire form and the storage form.

What appears in keytabs and so on is a local/implementation matter.
(Some implementations would have a legacy upgrade problem regardless of
how we address the protocol I18N problem.)

What happens on the wire is the key.  And here we run into a problem:
the protocol uses IA5String for all the relevant strings (principal
components, realm names), and we can't send UTF-8 in IA5String.

In *practice* every implementation just-sends-whatever or
just-sends-UTF-8 in IA5String, and in either case no stringprep is
applied.

The first questions is: can we get a way with saying "oh well, send
UTF-8 in these IA5String fiels"?  In theory it would break anyone using
ASN.1 tooling that won't permit that.

The second question is what to do about normalization in particular and
stringprep in general, particularly w.r.t. existing non-ASCII realms and
principals.

The problem in 2002 was that negotiation of use of UTF8String
complicated the protocol and no implementor committed to implementing
that.  The complexity of such a negotiation now would be similar to what
it was then, though perhaps we can use DNS for realm capability
discovery, thus simplifying some of the piece of the problem.

The negotiation is as follows:

 - for any non-ASCII crealm, do an AS exchange (or DNS lookup) to detect
   whether that realm's KDCs support the new protocol (with UTF8String)
   or the old one with just-send-UTF-8-in-IA5String

 - for any non-ASCII srealm, do a TGS exchange (or DNS lookup)
   to detect the srealm's support for the new protocol or the old one

 - for any sname, do a TGS exchange to detect the sname's support...

(The realm and the sname might need I18N in an AS exchange as well.)

Whereas treating those IDNA-unaware slots as such means making no
substantial changes to the protocol, just the implementations.  This
sucks because A-labels can leak into UIs, and the need to apply
ToASCII()/ToUnicode() can leak into applications -- preventing such
leaks will require a lot of work and it may not be feasible to get 100%
coverage.  If we can get to 100% or very close though, it's just a
trade-off in complexity: complexity in the protocol [and
implementations], or complexity in the implementations.

But if we can just say that our "IA5String fields are really UTF8String,
never mind the DER tag on them", then we get a big win.

(Sending UTF8String instead, as if those IA5String fields had been
extensible CHOICEs, does not work, because none of the existing
implementations interpret the UTF8String correctly.)

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Thu, 30 Oct 2014 12:24:15 -0500

Using A-lables doesn't do anything about non-domainname slots (e.g.,
user names).  Which argues for either a new protocol with UTF8String
(ETOOHARD) or just declaring our IA5Stings to carry UTF-8 (if anyone
objects, too bad: it's what happens in reality anyways; ignoring reality
has non-trivial costs).

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Thu, 30 Oct 2014 14:25:48 -0500

An evil thought occurs...

Update RFC4120 to redefine KerberosString from this:

      KerberosString  ::= GeneralString (IA5String)

to this:

      KerberosString  ::= [UNIVERSAL 27] IMPLICIT UTF8String

I.e., send UTF8String, but tag it as GeneralString.

(This is legal ASN.1.  For example, GeneralizedTime is defined as
[UNIVERSAL 24] IMPLICIT VisibleString.)

On the wire this means: no change to encodings, and admit reality.

No need to negotiate.

Just-send-8 implementations will have to do codeset conversions.

All implementations will have to do something about stringprep.  We have
several options on that front, the best of which may be to do no
normalization or stringprep of any kind, leaving end-points to do
normalization-insensitive string comparison where it matters (but for
ease of implementation continue requiring that cname/crealm in
Authenticators match cname/crealm in Tickets exactly).

Nico
--

---

From: Rick van Rein <[email-masked]>
Date: Thu, 30 Oct 2014 21:02:32 +0100

Wow,

> An evil thought occurs…

Yes, this really _is_ evil ;-)

> I.e., send UTF8String, but tag it as GeneralString.

Yep, that ought to work under BER/DER encoding :)

But I wonder what does the most damage:
 * introducing a new, negotiated, string format for i18n and let it sip in slowly
 * introducing UTF-8 and letting it loose on unsuspecting programs

> On the wire this means: no change to encodings, and admit reality.

Yeah… and shifting the basis of security assumptions that programmers
may have made based on the IA5String format assumptions.  Things
like “there are no long-winded notations for \0” for instance.  Now these
won’t show up until you decode UTF-8, but it’s just an example of the
sort of misleading that reality may now impose on those programs, but
for which you are now blaiming those programs that have hitherto been
well-coded programs.  It’s not really fair on them?

-Rick

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 30 Oct 2014 20:25:57 +0000

On Thu, Oct 30, 2014 at 09:02:32PM +0100, Rick van Rein wrote:

> Yeah? and shifting the basis of security assumptions that programmers
> like ?there are no long-winded notations for \0? for instance.  Now these
> won?t show up until you decode UTF-8, but it?s just an example of the
> well-coded programs.  It?s not really fair on them?

The programs in question should be Kerberos libraries, by the time
the principal is presented to applications it should already have
been validated by the library, including rejection of non-minimal
UTF-8 encodings and internal NUL octets (which can occur in ASN.1
strings even without UTF-8).  So strlen(data) == ASN1.length(data)
needs to be enforced regardless.

-- 
	Viktor.

---

From: Nico Williams <[email-masked]>
Date: Thu, 30 Oct 2014 15:36:09 -0500

> Yes, this really _is_ evil ;-)

Tom says that x.680 permits this only for itself.  However, I think of
the two possible abuses of ASN.1/DER that we could make here, this is
the most palatable, as it's much more likely that a) existing ASN.1
compilers will accept this (because it makes sense to for internal
purposes), or b) can be modified to accept it with minimal effort.

>  * introducing UTF-8 and letting it loose on unsuspecting programs

The latter already happened, because all existing implementations fail
to constrain GeneralString to IA5String as specified in RFC4120, both on
the encode and decode sides.

> Yeah... and shifting the basis of security assumptions that
> programmers may have made based on the IA5String format assumptions.
> Things like

In the Kerberos space no such assumptions have been made.  MIt and
Heimdal gladly send whatever you feed them, without even so much as a
codeset convertion to/from UTF-8.  Windows and Active Directory gladly
send non-ASCII UTF-8 without any normalization (or any singificant
stringprep).

> "there are no long-winded notations for \0" for instance.  Now these
> won't show up until you decode UTF-8, but it's just an example of the
> well-coded programs.  It's not really fair on them?

Existing implementations do check for embedded NULs (sadness otherwise).

Nico
--

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 30 Oct 2014 17:34:28 -0400 (EDT)

Sniping,

>       realm-names, with all labels up-cased (to follow existing

Obligatory note that there are real-world realms with lowercase realm
names; we should not gratuitously break them.

-Ben

---

From: Nico Williams <[email-masked]>
Date: Thu, 30 Oct 2014 16:51:42 -0500

> names; we should not gratuitously break them.

They wouldn't, unless they were non-ASCII UTF-8, and even case in the
Unicode form would be preserved, with the addition of A-label aliases
of the original.

Still, I'd rather do the KerberosString ::= [UNIVERSAL 27] IMPLICIT
UTF8String hack -- it will be much less work, and it will interop much
better with existing non-ASCII names in use in existing deployments.

Nico
--

---

From: Rick van Rein <[email-masked]>
Date: Fri, 31 Oct 2014 09:43:17 +0100

Hey,

> send non-ASCII UTF-8 without any normalization (or any singificant

Are you saying that the implementation practice is OCTETSTRING?
That could be another option, and then having end user apps interpret
UTF-8 or other.

Not sure that’s better, just bringing in an alternative.

-Rick

---

From: Nico Williams <[email-masked]>
Date: Fri, 31 Oct 2014 09:50:26 -0500

> Are you saying that the implementation practice is OCTETSTRING?

Yes.

> Not sure that’s better, just bringing in an alternative.

It's not.  It's not always possible to detect codeset and encoding
from the octet string itself.  The best fix is to treat it as UTF-8.

Nico
--