Subject: CAP: Definition of UPN

From: [email-masked]
Date: Tue, 13 Jul 1999 12:57:27 -0400

According to the draft-00.txt, a UPN is defined as:

User Principal Name (UPN)
     An identifier that denotes a unique CU. A UPN strongly resembles an
     RFC 822 style email address and in some cases it may be identical
     to the email address for the CU. It consists of a realm in the form
     of a DNS domain name and a username.

I have an aversion to the explicit inclusion of term "DNS domain name". 
There are some systems (like Lotus Notes and Novell Netware) that have a 
separate naming space that do not map directly onto a contiguous DNS 
domain name space.  From my notes on the Montreal mtg I note that we were 
going to adjust this description to be more like "It consists of a realm in the form of an authentication realm name and a 
username." and then have an implementors note that suggests the use of DNS domain 
names for the authentication realm name.

This would allow systems like Windows 2000, Kerberos, and others to use 
DNS if they want but mandate other systems w/other authentication schemas 
adopt this schema or change their architecture to be DNS-only based. 
Besides, if we tie the realm description explicitly to DNS we may be 
precluding non-TCP transports implementations.

Bruce
===========================================================================
Bruce Kahn                                INet: [email-masked]
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: David Madeo <[email-masked]>
Date: Tue, 13 Jul 1999 14:12:59 -0400

[email-masked] wrote:

> I have an aversion to the explicit inclusion of term "DNS domain
> name".  There are some systems (like Lotus Notes and Novell Netware)
> that have a separate naming space that do not map directly onto a
> contiguous DNS domain name space.  From my notes on the Montreal mtg I
> note that we were going to adjust this description to be more like "It
> consists of a realm in the form of an authentication realm name and a
> username." and then have an implementors note that suggests the use of
> DNS domain names for the authentication realm name.
>
> This would allow systems like Windows 2000, Kerberos, and others to
> use DNS if they want but mandate other systems w/other authentication
> schemas adopt this schema or change their architecture to be DNS-only
> based.  Besides, if we tie the realm description explicitly to DNS we
> may be precluding non-TCP transports implementations.

I believe that there are two issues.  The authentication realm does not
have to be an actual resolvable (or even pingable) hostname.  However,
in order to help create uniqueness, the last two components of the name
*should* be your base DNS domain.    Within a given DNS domain, we hope
you can guarantee uniqueness above that.

So if I as an admistrator wanted to create two authentication realms in
my firm, I could create  foo.ms.com and bar.ms.com.  Even though neither
are hostnames in my DNS table, let alone anything you could resolve.

dmadeo

---

From: Richard Shusterman <[email-masked]>
Date: Thu, 15 Jul 1999 19:02:20 -0700

Bruce,

Your notes are partially correct. My notes said we agreed on the SHOULD,
e.g., something like "A realm SHOULD incorporate a registered DNS domain
name as a suffix to guarantee uniqueness of realm names across the
Internet.". We decided not to use the MUST because of the proliferation
of non-DNS name spaces in environments that don't require their CUA's to
reference users outside a domain. We also said that a UPN:

   * MUST use the @ character as a separator between a username and
     realm
   * MUST allow for all UTF8 characters
   * MUST be case insensitive
   * MUST be unique within a realm
   * MUST be unique within connected CUA's and CS's
   * MUST be independent of an authentication mechanism
   * MUST represent the same CU, whether using the same CUA or using
     different authenticating mechanisms or connecting from different
     locations

This draft-00.txt does not reflect all the discussions we had in
Montreal. We ran out of time editing this draft before it had to be
submitted to make the deadline for the Oslo meeting. Paul, Alex, and I
are now in the process of putting in these types of corrections to the
next draft.

BTW, besides the definition section of the draft, there is another
section (currently 2.5) that has a more detailed discussion of what is a
UPN, which would include most of the points I listed above. I believe
the definition section should limit itself to short (but correct)
descriptions that are not necessarily complete and the reader should
refer to the other section for a complete description with examples.

Richard