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

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 07 Feb 2008 18:31:02 -0500

This note announces the start of a two-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-01.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 Feb 21, 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-01.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: "Henry B. Hotz" <[email-masked]>
Date: Thu, 7 Feb 2008 18:54:56 -0800

>    describes the services exposed by an administrative interface to a

I would say that the document describes information that is a  
necessary prerequisite for defining interoperability of a Kerberos  
administration interface.  I'm less certain what it defines is  
sufficient, but I do not see any problems with the information  
model.  I hope other people are thinking about this.

Section 2, paragraph 1 says this document "... describes the services  
required to ...".  I only see an information model, and nothing about  
the operations on that information that should be supported.   
Probably should just restate the scope to match the actual content,  
since I assume specifying the operations is to be done elsewhere.

Section 7.3 generically mentions SOAP.  That's OK, but I would think  
anyone serious about going that route would want an SPML profile.

Section 2 needs to be fixed, I think.  Other comments are just my  
nattering.
------------------------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: Leif Johansson <[email-masked]>
Date: Wed, 27 Feb 2008 21:47:42 +0100

> model.  I hope other people are thinking about this.

I do too. Can you think of anything I've missed?

> since I assume specifying the operations is to be done elsewhere.

Agreed. I have been thinking about adding operations but I think that could be 
a separate I-D. I'll fix this.

> anyone serious about going that route would want an SPML profile.

The idea is that you write one starting from this model just as you would
write an LDAP schema starting from this model, etc. etc.

> Section 2 needs to be fixed, I think.  Other comments are just my

	Cheers Leif

---

From: Leif Johansson <[email-masked]>
Date: Wed, 27 Feb 2008 21:47:42 +0100

Cheers Leif

---

From: Tom Yu <[email-masked]>
Date: Wed, 27 Feb 2008 18:42:03 -0500

> model.  I hope other people are thinking about this.

I also think this model is a good starting point, but may not be
sufficient.  It seems like some additional parameters used by the KDC
for ticket issuance might be needed, such as flags for whether a
principal is permitted to act as a service, and possibly policy
information on lifetimes (though experience has shown that storing
ticket lifetime policies on a per-principal basis can lead to
confusion).
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: "Henry B. Hotz" <[email-masked]>
Date: Wed, 27 Feb 2008 16:13:48 -0800

> ticket lifetime policies on a per-principal basis can lead to

Actually I was wondering about the whole policy information issue.   
The doc calls for an undefined policy item, but Heimdal would seem to  
be an existence proof that it isn't needed.  If this doc is supposed  
to describe MIT then policy is underspecified because there isn't  
enough information to do anything useful.  If it describes Heimdal  
then it's overspecified because there's nothing in reality to  
correspond to the required item.

I confess myself flummoxed as to what the document *should* say on  
the subject.