Subject: Re: IDNA encoding for Kerberos host names

From: Ienup Sung <[email-masked]>
Date: Thu, 09 Oct 2003 12:44:11 -0700 (PDT)

The previous email from me was of the concern on the SASLprep being
used in the domain style host/domain name components and realms. Obviously
there are host and domain names that Kerberos applications might use to
get into Kerberos principal names and realms (as described in the section 2.1
of the clarification draft for instance) and differences between 
the two profiles and additional Kerberos rules defined in the RFC 1510
and the clarification draft don't appear to me that the RFC1510 and 
the clarification draft are completely covering the ground in my opinion.

Yes, case folding issue is one of the sub-issues that I hope to mention in
the memo. Another issues are non-ASCII space character mapping (and allowing
of space " " at the realm) and prohibition of ASCII control characters that
are differ between the two profiles. And, afterward, if the NFKC is applied,
the results will be even more different. (Also, the recommendation of
conversion to uppercase letters for the domain name style realm names has to
have some more paragraphs, esp., when the conversion should take place and
so on.)

There are also various period characters allowed in the IDNA that needs to be
also mentioned and some steps on how to deal with such characters in
the IDN names at the extension.

Another issue is various and different codesets/code pages being used in
the applications out there. There also should be some form of
sentence on that particular issue as well. ACE, whether to allow it or not
and if not allowed, then, how to deal with it is another thing that
need to be mentioned in the extension. I also think there are additional
issues before and the after the application of Stringprep profile(s) that also
need to be mentinoed.

A bit of side track and a very minor issue, there is also another issue of
using UTF-8 messages in error messages and so on considering there are
applications that will run in non-UTF-8 locales/codesets/code pages.

I think I have a few more issues and as pledged I'll try to come up
with some coherent memo that can be used in the discussion as, hopefully,
problem statements. It might take a couple of days from me.

With regards,

Ienup

---

From: Ienup Sung <[email-masked]>
Date: Thu, 09 Oct 2003 15:24:32 -0700 (PDT)

Okay, for instance, if I give SASLprep'd host name to rlogin it may
be able to derive the realm but it won't be able to connect to the
destination host since the SASLprep'd name's not matching to the Nameprep'd
name.

With regards,

Ienup

] Date: Thu, 09 Oct 2003 16:22:30 -0400
] From: Sam Hartman <[email-masked]>
] Subject: Re: IDNA encoding for Kerberos host names
] To: Ienup Sung <[email-masked]>
] Cc: [email-masked]
] MIME-version: 1.0
] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
frigga.ctd.anl.gov
] 
] >>>>> "Ienup" == Ienup Sung <[email-masked]> writes:
] 
]     Ienup> Sure. One of the examples below.  The SASLprep does not use
]     Ienup> B.2 or B.3 of the Stringprep. The B.2 and the B.3 are case
]     Ienup> folding mappings, the former to be used with Normalization
]     Ienup> and the latter to be used with no normalization. And yet
]     Ienup> the SASLprep does Normalization KC (a.k.a. into NFKC).
] 
] Again, I repeat my question.  Please provide an an example where
] things will break with saslprep and they do not break today.  We do
] not have case folding today and DNS does.  Thus the example involving
] case folding is not appropriate because Kerberos with only ASCII
] already has the problem you describe.
] 
] 
] Still waiting to see what you believe is wrong with saslprep.
] 
] 
]

---

From: Ienup Sung <[email-masked]>
Date: Thu, 09 Oct 2003 18:05:51 -0700 (PDT)

Thanks for your agreement.

I'll be happy to volunteer and participate. I'm not sure if this
will be an expected answer for you but I believe I have limited
exposure to the extension draft at the moment; the only understanding
and guessings that I have on the proposal are coming from and
based on the email archives and glimpse from the
draft-ietf-krb-wg-kerberos-set-passwd-00.txt that I *think* it shares
many thoughts with the extension draft.

Based on that limited info, I would say the proposal on UTF-8 + SASLprep
would require at least one page amount of explanations and clarifications
to make it work in my opinion. (Then again, the opinion would need to be
changed if I can have a chance to see the early draft.)

With regards,

Ienup

] Date: Thu, 09 Oct 2003 20:14:29 -0400
] From: Sam Hartman <[email-masked]>
] Subject: Re: IDNA encoding for Kerberos host names
] To: Ienup Sung <[email-masked]>
] Cc: [email-masked]
] MIME-version: 1.0
] 
] >>>>> "Ienup" == Ienup Sung <[email-masked]> writes:
] 
]     Ienup> Actually, what you wrote is something that we need to spell
]     Ienup> out at the extension and more in my opinion since it's not
]     Ienup> just Stringprep as you know and in the reality, principal
]     Ienup> names and realms like the following that coincides and as
]     Ienup> synonyms to the current domain of the net are frequent:
] 
] I agree it needs to be spelled out.  Before we do that I'd appreciate
] your help in making sure that what is being proposed here will
] actually work.
] 
] Do you understand what is being proposed well enough to have an
] informed opinion about whether it will work?  If not what questions
] would you need answered to understand the proposal?
] 
] If you understand things well enough to have an informed opinion , do
] you believe that our proposal will work?  If not, what will fail?  If
] so, then we should move onto spelling things out so people implement
] correctly.
] 
] --Sam
]