headers
Douglas E. Engert | 3 Sep 2002 21:39
Favicon

IETF - krb-wg Interim Meeting, Oct 1-2, at MIT

The Kerberos WG of the IETF will be holding a two day meeting to work on 
the Kerberos Clarifications and Extensions drafts. This is intended to be a 
working meeting where the attendees will work on editing the "Clarifications"
as the primary activity with additional discussions on the "Extensions". 

(This announcement is being made per RFC 2026 Section 8. The meeting was 
also discussed at IETF-54 in Yokahama at the krb-wg and I think at the saag.) 

When:   October 1-2, 2002 9:00AM-5:00PM 

Where:  Building W92 2nd floor South Station conference room (Tenitive room) 
        MIT
        304 Vassar St
        Cambridge, MA

The Hyatt Regency at 575 Memorial Drive 617-492-1234, has rooms available
at a reduced rate if you tell them you're coming for a conference at MIT.
(The rate was $189 last year, it may have changed.) 
The hotel is right across the street from building W92.  (Despite
the street addresses, both have their entrances on Amesbury St. that
runs between them.  Walk out the hotel entrance, and W92 is across the
street and to the left.)

If you will be attending, please let me know. Watch the mailinig list
<ietf-krb-wg <at> anl.gov> for last minute updates. To join, send:  
subscribe ietf-krb-wg as body of message to <majordomo <at> anl.gov>

--

-- 

 Douglas E. Engert  <DEEngert <at> anl.gov>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Simon Josefsson | 5 Sep 2002 00:22

name-type significance for principal name equality

Quoting draft-ietf-krb-wg-kerberos-clarifications-00.txt:

,----
| 7.2. Principal Names
|
| As was the case for realm names, conventions are needed to ensure that all
| agree on what information is implied by a principal name. The name-type
| field that is part of the principal name indicates the kind of information
| implied by the name. The name-type should be treated only as a hint to
| interpreting the meaning of a name. It is not significant when checking for
| equivalence. Principal names that differ only in the name-type identify the
| same principal. The name type does not partition the name space. Ignoring
| the name type, no two names can be the same (i.e. at least one of the
| components, or the realm, must be different). The following name types are
| defined:
...
| A name type of UNKNOWN should be used when the form of the name is not
| known. When comparing names, a name of type UNKNOWN will match principals
| authenticated with names of any type. A principal authenticated with a name
| of type UNKNOWN, however, will only match other names of type UNKNOWN.
`----

Is the name-type significant when comparing principal names or not?

Has a text representation format for principal names been considered
for standardization?  E.g. a'la text representation of DNS domains;
concatenate all elements of the name and stick '.' between each pair,
and escape any existing '.' into '\.' and any existing '\' into '\\'.

Nits:
(Continue reading)

Permalink | Reply | 3 comments |
headers
Martin Rex | 5 Sep 2002 22:50
Picon
Favicon

Re: name-type significance for principal name equality

Simon Josefsson wrote:
> 
> Is the name-type significant when comparing principal names or not?
> 
> Has a text representation format for principal names been considered
> for standardization?  E.g. a'la text representation of DNS domains;
> concatenate all elements of the name and stick '.' between each pair,
> and escape any existing '.' into '\.' and any existing '\' into '\\'.

Now I'm confused.

Kerberos has nametypes that are seperate from the actual principal name?

I got to know Kerberos as an implementation of a GSS-API mechanism
and I have never had any contact with anything besides the principal
name itselft.  Not when setting up my own MIT KDC for test purposes or
creating principals with kadmin.local.

GSS-API has its own notion of name-types, and all I see in rfc-1964
(the Kerberos 5 gssapi mechanism) refers to the GSS-API nametypes.

With rfc-1964 all Kerberos principal names can be transformed into a
"Kerberos principal name" representation with one single GSS-API-level
nametype GSS_KRB5_NT_PRINCIPAL_NAME.  Therefore GSS-API based apps
would not be able to distinguish two principal names if they had been
internally tagged with some extra level of Kerberos-nametype.

Are there really nametypes related to Kerberos principals that
do not get encoded into the "Kerberos principal name" format?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nicolas.Williams | 6 Sep 2002 00:21

RE: name-type significance for principal name equality


Kerberos principal names have a name type *hint* which is NOT encoded
into the print form of any principal name.

Thus "joebob <at> FOO.COM" may be tagged as a host-based principal or a
user-based principal, or even an x.500 principal, or as a principal of
unknown type; whatever the type tag is, it is meaningless in the end.
Existing implementations may set it, but no two principal names may
exist whose components are the same, in the same realm but with
different name types (as the RFC puts it, the name type does not
partition the namespace).

So, for example, there is no option to MIT krb5's kadmin's add_principal
sub-command to set the principal name type.

This is what makes the GSS name types so obnoxious to us Kerberos types.
But see the last paragrapgh of this post.

Name type, schname types. All Kerberos names should be unique with
respect to each other, and all x.509 names should be unique with respect
to each other, and so on - ultimately one could encode the name type
into the name to distinguish between otherwise equal names, but that
just makes the names uglier. Fortunately usernames and *fully qualified*
hostnames tend to never conflict, thus there is no confusion in the
following Kerberos princ name examples:

 - foo <at> BAR.COM
 - foo.bar.com <at> BAR.COM

Yes, there is redundancy, but that just happens to be a result of
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sam Hartman | 7 Sep 2002 00:35
Picon
Favicon

Re: name-type significance for principal name equality

>>>>> "Simon" == Simon Josefsson <jas <at> extundo.com> writes:

    Simon> Is the name-type significant when comparing principal names
    Simon> or not?

The two paragraphs you quoted are not inconsistent.  The name type is
significant when comparing principals, but it does not partition the
name space.

Think of it this way.  It is correct for an implementation to discard
the name type when storing principal names in its database, but if it
does store the name type then the implementation can fail to match the
name if the incoming name type is not either unknown or the same as
the one stored in the database.

AS a practical matter, name types are a good way to give your users a
loaded gun pointed at their feet or heads; they are confusing and
really not that useful.  It's probably best if implementations always
use an unknown name type.
Permalink | Reply | 1 comment |
headers
Matt Crawford | 10 Sep 2002 17:00
Favicon

OID for a Kerberos principal name in an X509 subject DN?


Is there a correct OID to use for including a Kerberos principal name
in a DN?  Is it one of

	1.2.840.113554.1.2.2.1 - gss-krb5-nt-principal-name
		(...mit infosys gssapi krb5 krb5_name)
or
	1.3.6.1.5.6.4 - gss-api-exported-name

or something completely different?
Permalink | Reply | 2 comments |
headers
Douglas E. Engert | 10 Sep 2002 20:19
Favicon

IETF - krb-wg Interim Meeting, Oct 1-2, at MIT

There has been some concern over the cost of the Hyatt Regency 
being $245 a night. 

Marshall Vale has provided some other alternatives:

Here are other offerings for hotels in the area (walking or shuttle 
distance). I have no information about availability or what not. 
Folks may want to consult their own travel offices to find any 
specific hotel chains that they have deals with.

Hotel at MIT - 20 Sidney St
$199.00
1-800-222-8733
617 577-0200

Cambridge Center Marriott
$229.00
1-800 228-9290

The Kendall Hotel in Kendall Sq (formerly the fire station)
$129.00
617 577-1300

Hyatt Regency 
575 Memorial Drive 
$245.00
617-492-1234
Permalink | Reply | 0 comments |
headers
Clifford Neuman | 10 Sep 2002 20:49
Picon
Favicon

Update to Kerberos clarifications available

Members of the Kerberos working group:

An update to the Kerberos clarifications document is available from
http://www.kerberos.us.  I am in the process of packaging the text
version to submit to internet-drafts, and that draft will emerge when
they are done processing the submission.

Changes since the last version include updates to section 5 and
appendix A submitted by Tom Yu (which you have seen separately on the
list), updates from Ken Raeburn, text in many sections provide by Sam
Hartman, and updates to section 8 by Jeffrey Altman.  Other minor
edits in response to list discussions were made throughout.

I will be continuing to update the HTML versions on the site leading
into the interim meeting based on comments and discussion on the list.
Please post comments to the mailing list.

Clifford Neuman
Permalink | Reply | 4 comments |
headers
Matt Crawford | 11 Sep 2002 15:47

OID for a Kerberos principal name in an X509 subject DN?

Is there a correct OID to use for including a Kerberos principal name
in a DN?  Is it one of

	1.2.840.113554.1.2.2.1 - gss-krb5-nt-principal-name
		(...mit infosys gssapi krb5 krb5_name)
or
	1.3.6.1.5.6.4 - gss-api-exported-name

or something completely different?
Permalink | Reply | 1 comment |
headers
Martin Rex | 11 Sep 2002 20:37
Picon
Favicon

Re: OID for a Kerberos principal name in an X509 subject DN?

Matt Crawford wrote:
> 
> Is there a correct OID to use for including a Kerberos principal name
> in a DN?  Is it one of
> 
> 	1.2.840.113554.1.2.2.1 - gss-krb5-nt-principal-name
> 		(...mit infosys gssapi krb5 krb5_name)

Maybe but not quite.

This OID is primarily for use with GSS-API and it indicates that
the accompanying (printable) octet string represents a Kerberos principal
name according to the rules of rfc-1964.

However, the definition in rfc-1964 is not very precise, so there are
two things you should beware of:
- the accompanying printable is encoded in whatever is the local
  character set (usually ASCII, but EBCDIC still exists on some machines...)
- there is the same just-send-8 (bit) confusion as in the Kerberos ticket
  protocols (only that the Kerberos protocol requires the ASCII 7-bit subset).

> or
> 	1.3.6.1.5.6.4 - gss-api-exported-name
>

No, _this_ particular OID is strictly tied to the output of
the GSS-API call gss_export_name() and must be used for *ALL*
gssapi mechanisms that support this GSS-API v2 functionality.
To be exact, this OID indicates that the accompanying binary blob
uses an outer generic framing as described in RFC2743, Section 3.2.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane