Subject: [Ietf-krb-wg] WG Last Call: draft-ietf-krb-wg-kdc-model-03.txt

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 14 Nov 2008 18:27:42 -0500

As Leif noted, sometimes people seem not to bother reviewing things unless 
there is a last call.  Therefore, I'm starting a new one on the data model 
document.  Due to the IETF meeting week and the upcoming Thanksgiving 
holiday in the US, I'm extending the last call period to three weeks.  If 
anyone thinks that is not enough, please let me know.

This note announces the start of a three-week last call within the Kerberos
Working Group on whether to send the following document to the IESG:

Title:           An information model for Kerberos version 5
Filename:        draft-ietf-krb-wg-kdc-model-03.txt
Intended Status: Proposed Standard

   This document describes an information model for Kerberos version 5
   from the point of view of an administrative service.  There is no
   standard for administrating a kerberos 5 KDC.  This document
   describes the services exposed by an administrative interface to a
   KDC.

This last call will expire at 23:59 EDT on Dec 5, 2008

Please review this document and send any comments to the Kerberos Working
Group mailing list, <[email-masked]>, by that date.  The file can be
obtained via

http://www.ietf.org/internet-drafts/draft-ietf-krb-wg-kdc-model-03.txt

-- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
   Chair, IETF Kerberos Working Group
   Carnegie Mellon University - Pittsburgh, PA

_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Sat, 15 Nov 2008 21:49:19 -0800

Hello,

> there is a last call.  T

This is subset of the values that is needed support features of
Kerberos, this should be pointed out.

Personally I think the train have already left the station, just
publish this as is since it a important ground how do adopt your
directory to support kerberos, but is not complete and can not be
complete in this stage.

 > 6.  Information model specification
 >
 > 6.1.  Principal
 >
 >    The fundamental entity stored in a KDC is the principal.  The
 >    principal is associated to keys and generalizes the "user"  
concept.
 >    The principal MUST be implemented in full and MUST NOT be  
optional in
 >    an implementation
 >
 > 6.1.1.  Principal: Attributes
 >
 > 6.1.1.1.  principalName
 >
 >    The principalName MUST uniquely identify the principal within the
 >    administrative context of the KDC.  The type of the  
principalName is
 >    not described in this document.  It is a unique identifier and  
can be
 >    viewed as an opaque byte string which can be compared for  
equality.
 >    The attribute SHOULD be single valued.  If an implementation  
supports
 >    multiple values it MUST treat one of the values as special and  
allow
 >    it to be fetched as if it was a single value.

The concept of Principal and PrincipalAliases are starnge given there
is no such concept in Kerberos. Kerberos only have clients and
servers.

I don't think there need to be a unique principal as long there is a
unique identifier that takes it place.

Name (aliases?) then are split into name that can be used for clients,
names that can be used as services and name that can be used for both.

Since it a three-state I don't think it can be expressed with a flag
that is global to the entry.

 > 6.1.1.9.  principalLastCredentialChange
 >
 >    This single valued attribute contains the time and date for the  
last
 >    successful change of credential (eg password) this principal.

If entry that changes a names a public key that is assosited with the  
princpal is changed, does this change this value.

I think this should be more explicit.

 > 6.1.1.10.  principalCreateTime
 >
 >    This single valued attribute contains the time and date when this
 >    principal was created
 >
 > 6.1.1.11.  principalModdifyTime

Spelling, Modify

 > 6.1.2.  Principal: Associations
 >
 >    Each principal MAY be associated with 1 or more KeySet and MAY be
 >    associated with 1 or more Policies.  The KeySet is represented  
as an
 >    object in this model since it has attributes associated with it  
(the
 >    key version number).  In typical situations the principal is
 >    associated with exactly 1 KeySet but implementations MUST NOT  
assume
 >    this case, i.e an implemenation of this standard (e.g an LDAP  
schema)
 >    MUST be able to handle the general case of multiple KeySet  
associated
 >    with each principal.

It should be 0 or more keyset, esp true for key-less pre-auth  
mechanisms.

There needs to be a way modify acceptable key types though.

Love

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Sat, 15 Nov 2008 21:51:19 -0800

Hello,

concept.
optional in
principalName is
can be
equality.
supports
allow

last

Spelling, Modify

as an
(the
assume
schema)
associated

Love

---

From: Leif Johansson <[email-masked]>
Date: Sun, 16 Nov 2008 23:47:51 +0100

> directory to support kerberos, but is not complete and can not be

<snip>

Great comments! I'll address these presently.

	Cheers Leif