Subject: RE: Testing the concensus of the krb-wg on IDN

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Tue, 21 Oct 2003 11:57:30 -0700

Martin Rex wrote:

>> I know that Microsoft has serious problems dealing with accepting >> 
>>credentials in a consistent fashion since there may be arbitrary
aliases 
>>pointing to a particular account which the acceptor will hardly know 
>>about.  So instead of knowing it's own name the acceptor will use the 
>>target name of an incoming TGS_REQ just to derive the key from his 

>>memorized long term secret and blindly try to decrypt the ticket.  If
that 

>>succeeds the request is considered a legitimate request, although a 
>>service may just accidentally be sharing the password with the
original 
>>target...

This was proposed internally, I do not why you knew this, but it has NOT
been implemented, and we do not have a plan to do so.

Larry

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Tuesday, October 21, 2003 3:14 AM
To: Liqiang(Larry) Zhu
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: Testing the concensus of the krb-wg on IDN

Liqiang\ wrote:
> 
> Martin Rex wrote:
> 
> >> I was surprized a few days ago when I realized that Microsoft's
SSPI
> >> does an automatic uppercasing of an explicitly supplied REALM name.
> 
> MS clients do NOT automatically uppercase the realm names. Have you
seen
> a case where MS clients return an upper-cased MIT realm name when the
> realm name is really in lower cases? If so, please let me know.
> 
> What happens here is that a MS client is not required to know the
exact
> case of the domain name, instead, the client can choose to ask the KDC
> and it does so by requesting the kdc option name_canonicalize (covered
> in the JBrezak drafts).  This is apparently necessary due to the fact
> that pre-w2k domain names are case-insensitive.
> 
> >> However if the initiator does a QueryCredentialsAttributes() on
these
> >> initiating credentials, then it will receive the Realm name in
> >> exactly the fashion that it was passed to
AcquireCredentialsHandle()
> >> -- OUCH!
> 
> When you supply explicit credentials and the client won't be able to
> have the names normalized till it contacts the KDCs (mostly during the
> InitializeSecurityContext call), this is why the realm name is not
> upper-cased on the initiator side but might get upper-cased on the
> acceptor side if the acceptor is in an MS domain.
> 
> The client might optimistically upper-case the realm name during the
> initial pre-auth, but such decision is not authoritative and is for
> optimization only.
> 
> Does this explain what you have observed? In the future, please feel
> free to drop me a line when you are un-certain about some aspects of
the
> MS Kerberos implementation.

Its an explanation, but NO excuse.  Initiating credentials
in Kerberos consist of a TGT, and a TGT has already been processed
by the KDC.  So in order to make the Kerberos SSP useful, there
should be spent some more thought on processing the information
passed to AcquireCredentialsHandle() via an AUTH_IDENTITY structure,
at least for initiating credentials.

The correct thing to do would be to look at the name on the TGT
when QueryCredentialsAttributes(NAMES) is called, and if there
is no TGT available (or if the name passed in via the AUTH_IDENTITY
structure differs from the name of the TGT in the ticket cache),
the acquisition of a new TGT matching the name should be performed.
The name of the resulting TGT should then be returned.

In order to verify whether a credential is available my gsskrb5.dll
as part of gss_acquire_cred() currently tries to establish a security
context with itself, because that seems to be the only way in W2K
Kerberos
to have it verify the (initiator) credentials.  I never liked this
and I complained to Mike Swift in 1999 already about this.

Why is it a bad idea to verify client credentials only during
security context establishment?  Because gss_init_sec_context()
will be usually be called after the network connection has been
established, and if the initiator gets an error at that point,
almost every application will abort the communication with
an error and just close the network connection -- the peer
doesn't have the slightest idea what happened.

I know that Microsoft has serious problems dealing with accepting
credentials in a consistent fashion since there may be arbitrary
aliases pointing to a particular account which the acceptor will
hardly know about.  So instead of knowing it's own name the acceptor
will use the target name of an incoming TGS_REQ just to derive
the key from his memorized long term secret and blindly try to
decrypt the ticket.  If that succeeds the request is considered
a legitimate request, although a service may just accidentally be
sharing the password with the original target...

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Tue, 21 Oct 2003 14:25:44 -0700

Martin Rex wrote:
>> Now that
>> really surprized me...

To clarify, the rest of your comments is correct, I just pointed out
that we currently do not use the target name in the TGS_REQ or the
server name in the incoming service ticket.

Larry
-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Tuesday, October 21, 2003 2:04 PM
To: Liqiang(Larry) Zhu
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: Testing the concensus of the krb-wg on IDN

> >>the key from his memorized long term secret and blindly try to
decrypt
> >>the ticket.  If that succeeds the request is considered a legitimate
> >>request, although a service may just accidentally be sharing the
> >>password with the original target...
> 

?

When I tested with W2K Beta3 in 1999 I had created two user accounts
test and test2 and used the same password on both.  Now when running
gss-sample server and client both under test then it still succeeded
authentication even when I used test2 as the target name.  Now that
really surprized me...

I just checked with W2K3 and the gss-sample included in my gsskrb5.dll
-- this still works.

Basically I was complaining to Mike Swift that I would like to see an
error message "wrong target in request" when an acceptor received an
request that didn't match its credentials, just like every other
MIT Kerberos 5 variant does (we test that specific scenario in
the interoperability certification with our application), however
Mike told me that it wasn't possible to create that error because
an acceptor on Windows wouldn't know it's own name...

So right now gsskrb5.dll guesses whenever AcceptSecurityContext()
returns SEC_I_CONTINUE_NEEDED instead of COMPLETE or FAILURE that
it may be because of a wrong target name.

-Martin

---

From: Ienup Sung <[email-masked]>
Date: Thu, 23 Oct 2003 16:41:53 -0700 (PDT)

I think the extension should describe more on the case conversions than
the clarification has now.

The main reason for that is non-ASCII Unicode names' case conversions
require several special cases and treatments and also has sometimes
per-locale specifics as you probably already know. This case conversion is
also out of existing Stringprep profiles where you can only either choose to
do a case folding (Nameprepp) or no case folding (SASLprep).

Hence to have a consistent result and matching, additional details on
how to do the case conversions should accompany or some other way should be
defined at the extension.

This case conversions (along with SALSprep) introduce another possible issue
such as should people see the following domain-style component (in UTF-8) the
same/equivalent or not in terms of German user expectations:

        strasse.de
        straße.de

Or, for Japanese users':

	test.jp
	
] Date: Mon, 20 Oct 2003 12:40:45 -0400
] From: Jeffrey Hutzelman <[email-masked]>
] Subject: Re: Testing the concensus of the krb-wg on IDN
] To: Nicolas Williams <[email-masked]>, Kerberos WG 
<[email-masked]>
] MIME-version: 1.0
] Content-transfer-encoding: 7bit
] 
] 
] 
] On Monday, October 20, 2003 07:43:08 -0700 Nicolas Williams 
] <[email-masked]> wrote:
] 
] > On Sun, Oct 19, 2003 at 03:21:54PM -0700, Nicolas Williams wrote:
] >> I disagree.  The case recommendation for realm names is relevant to
] >> interoperability.
] >
] > To clarifiy this statement: the case recommendations of rfc1510/
] > clarifications are implemented, for the most part, by humans rather than
] > software - so the case recommendations in rfc1510/clarifications aren't
] > that relevant to interop, no.
] >
] > But will users be generally able to manage case in non-ASCII names?
] >
] > What if users cut-n-paste text that uses characters they're not familiar
] > with?  (Perhaps users shouldn't do that, but won't they?)
] 
] 
] I really think we need to be talking about realm and principal names 
] separately here.
] 
] Applications rarely just make up realm names from domain names.  Realm 
] names are either provided by the user (via cut-and-paste or manual entry of 
] something he knows) or obtained from the Kerberos library based on local 
] configuration or cross-realm referral from a KDC (which presumably also has 
] local configuration).  The realm names in local configuration were provided 
] by some administrator, either by cut-and-paste or by manual entry.
] 
] The point is, virually all realm names are obtained either by literal 
] copying of something that is already a realm name, or by manual entry of 
] something known to the user -- not by deriving them from DNS domain names. 
] The only time a realm name should be obtained by derivation from a DNS 
] domain name is when a Kerberos administrator is choosing the name of his 
] realm.  Our document defines a convention for that case (upcase the name of 
] a DNS domain you control), but only for that case.  With regards to 
] determining what realm to use in a Kerberos request, we say:
] 
]    ...and a
]    mapping to a Kerberos realm derived syntactically from the domain
]    part of the specified hostname and information from the local
]    Kerberos realms database. [1.2]
] 
]    Before sending a request to the ticket-granting service, the client
]    MUST determine in which realm the application server is believed to
]    be registered [3.3.1]
] 
]    When establishing a new realm name based on an internet domain
]    name it is recommended by convention that the characters be converted
]    to upper case. [6.1]
] 
] In other words, when creating a realm, you end up deriving the name from 
] DNS without any other information.  But an application looking up the realm 
] name for a service will have access to local configuration information 
] telling it at a minimum what realms exist, and most likely containing a 
] mapping from patterns to match against domain names to realm names.
] 
] I don't think we need to say any more about realm names than clarifications 
] already does.  Does someone disagree?  If so, can we split the discussion 
] as it pertains to realms into a separate thread?
] 
] 
] Principal names, however, are another story.  While principal names are not 
] domain names and should not normally be treated as such, there are many 
] cases in which application protocols specify that the principal name for a 
] service is to be constructed from the name of the server on which the 
] service resides.  We even provide a name type for this, and guidance to the 
] effect that
] 
]    If the first component of a name identifies a service and there is a
]    single component following the service name identifying the instance
]    as the host on which the server is running, then the name type SRV-
]    HST SHOULD be used. [6.2]
] 
] and
] 
]    Where the name of the host is not
]    case sensitive (for example, with Internet domain names) the name of
]    the host MUST be lower case. [6.2.1]
] 
] Clearly this is enough guidance for a pre-IDN, clarifications world, in 
] which both hostnames and Kerberos principal names are restricted to 
] US-ASCII.  But just as clearly, IMHO, it's _not_ enough guidance for an 
] IDN+extensions world, in which both names admit richer character sets. 
] So...
] 
] - What guidance should kerberos-extensions provide to application protocols 
] constructing service principal names from Internet domain names?
] 
] 
] -- Jeff
] 
]

---

From: Ienup Sung <[email-masked]>
Date: Fri, 24 Oct 2003 12:17:15 -0700 (PDT)

I just hope to point out two things... If you're already aware of this,
please forgive me wasting bandwidth.

The Nameprep does case-folding mappings prior to the NFKC. The case-folding,
unlike upper casing or lower casing, actually erase the caseness.

The SASLprep does not do any case mappings at the mapping step of
the Stringprep protocol to preserve cases.

With regards,

Ienup

---

From: Ienup Sung <[email-masked]>
Date: Fri, 24 Oct 2003 13:11:20 -0700 (PDT)

The canonicalization in my definition that I used and so far assumed is
like the following quoted from the RFC3454 plus profile(s):

   ... a framework for preparing Unicode text
   strings in order to increase the likelihood that string input and
   string comparison work in ways that make sense for typical users
   throughout the world.

It also include some additional preperation that I mentioned as issues and
it doesn't include Punycode/ACE conversions of the IDNA.
   
With regards,

Ienup

] Date: Fri, 24 Oct 2003 12:56:58 -0700
] From: Nicolas Williams <[email-masked]>
] Subject: Re: Testing the concensus of the krb-wg on IDN
] To: Ienup Sung <[email-masked]>
] Cc: [email-masked]
] Mail-followup-to: Ienup Sung <[email-masked]>, [email-masked]
] MIME-version: 1.0
] 
] On Fri, Oct 24, 2003 at 12:51:41PM -0700, Ienup Sung wrote:
] > I also agree that it will be beneficial for pretty much everyone if
] > the canonicalization is supported in general.
] > 
] > Re your second remark, I see it as it's not really streingprep(nameprep(x))
] > issue or IDN WG actually but of this WG issue iff the WG choose to do upper
] > casing as a mean of canonicalization on the Realm name with Internet
] > domain-style names; in that case, the WG will need to come up with a profile 
of
] > its own (since we don't have any that do just that).
] 
] Right, and I think now that it would be best if we stuck to
] stringprep(nameprep(x)) for non-ASCII realm names also (though not for
] X.500 realm names).  This even though I've found the upper casing of
] ASCII realm names useful.
] 
] > As I already mentioned in my previous emails, for the IDN names, Nameprep
] > can be used as an option of the IDN names' canonicalization. (But as you
] > know, the case-folding employeed in the Nameprep will yield a side effect of
] > lower casing for many of Unicode characters.)
] 
] I'm happy with that.
] 
] Just so you know, "canonicalization" is a bit of a loaded words in these
] here parts.  So one must be careful to indicate what sort of
] canonicalization one means.
] 
] Types of canonicalization often referred to in this WG:
] 
]  - stringprepping
] 
]  - use of getXbyY() to canonicalize domain names (insecure when DNSSEC
]    is not used)
] 
]  - KDC "canonicalization" of client or service principal names in
]    KDC-REP messages  (which we've decided against - but see another post
]    from me today about this)
] 
]  - gss_canonicalize_name() (about which there has been a lot of
]    controversy)
] 
] 
] Cheers,
] 
] Nico
] --