Subject: [Ietf-krb-wg] Notes from Kerberos WG meeting at IETF77 (drafty)

From: Thomas Hardjono <[email-masked]>
Date: Tue, 30 Mar 2010 14:38:49 -0400

Folks, Jeff & Larry,

Here are my drafty notes from the Kerberos WG meeting last week at IETF77. Please check/verify that I did not miss anything or misunderstood items.

cheers,

/thomas/

------------------------------------------------------------------------
Minutes/Notes from Kerberos WG (IETF77) - DRAFT
March 24th, 2010

(I) AGENDA:
   (a) Preliminaries.
   (b) Document Status.
   (c) Last Call items.
   (d) Moving Forward.
   (e) Open Mic.

(II) DOCUMENT STATUS

(a) Cross Realm Problem statement
    - Approved, in Editor's queue.

(b) Preauth Framework
    - Will be on IESG Telechat in 2 weeks (April/8/2010).

(c) StartTLS
    - Currently in IESG Review.
    - Waiting also on outcome on discussions regarding
      validating server certs (mailing-list discussion).
    - WG Consensus: layering AS_REQ over TLS is generally
      a good idea (ie. better than nothing).

(d) IAKERB
    - Completed WG Last Call a few months ago.
    - Waiting for JHutz for proto eval.

(e) Naming/Anonymous
    - Draft has expired.
    - Anonymous draft has also expired now.
    - Sam believes all issues now resolved.
    - Larry to issue new versions of both drafts.
      + The Naming draft needs a new WG Last Call.
      + Anonymous draft just needs update in version-number.

(III) LAST CALL ITEMS

(a) Kerberos Information Model (v.07)

    - Update from Leif:
      + Leif will provide update v.08
      + Principal realms must be (will be) single-valued.
      + Will do English language clean-up.

    - Q: Should principal realms be single-valued?

      Sam: Its logical to associate multiple names to the realm.
           - PrincipalName is multivalued (even in 1 realm).
           - but Realm is multivalued.

      GregH: Consensus is that Principal Name must be multi-valued.
             But does not imply whether principal name includes
             a realm name.

      Discussion:....

      Leif: a principal can have multiple names even when it belongs
            to one realm (ie. folding name into realm).

    - Consensus: hum please...
      + Yes (majority)
      + No strong objection.
      + Slight objection from Hank Holtz.

(b) Kerberos Information Model: Open Issues

    - Slides: http://www.ietf.org/proceedings/10mar/slides/krb-wg-1.pdf

    - Two remaining open items:
      + Greg Hudson: some implementations don't need canonical principalName 
        for salting keys.
      + Greg Hudson: no need to separate keys from the rest of the model.

    - Q: Larry: We still need some semantics to be built into the name for the
                enterprise case.
      A: Leif: but this issue is not part of the model.
         Sam: agrees with Leif.

    - Consensus checks:
      (i) Update the text of the draft to clarify that implementations
          do not necessarilly require the canonical principalName 
          for salting keys ?

          Consensus call: weak hum, no rejects, 2 Yes on Jabber.
          Action Item: Leif to update the text to clarifiy this point.

      (ii) Separating keys from the rest of the model?

          Discussion:
          - GregH is not arguing for separating keys, but only that
            better text is needed to justify this. (Section 6.2.3)

          - Leif: could people please send suggested text to the mailing-list
            or to Leif. Note that WGLC is April 9th 2010.
 
          - JHutz: continue discussion on this topic on the mailing-list.

(IV) NEW DOCUMENTS

(a) Ticket extensions draft
    - Adopted as WG work item.
    - Love will modify doc name at next revision/update.

(b) Deprecating DES (des-die-die-die)
    - Adopted as WG work item.
    - Love says its ready for WGLC.
      + Sam: just publish it.
      + Hank: just publish it.
    - Conclusion: will begin WG Last Call as soon as possible.

(c) DHCPv6 Option
    - Adopted as WG work item.
    - Will begin WG Last Call as soon as possible.

(V) MOVING FORWARD

(a) IANA Considerations (draft-lha-krb-wg-some-numbers-to-iana-00)

    - JHutz: would anyone object to this document?

      + Sam: Agree that we need to turn over numbers to IANA but
             uncomfortable in the current registration process.
             This should not imply level of consensus in the work.

      + JHutz: "Registration process will be based on WG consensus".
            - We need to discuss registration procedure on the mailing-list
              until the next IETF meeting.  However, WG will adopt this doc
              as WG work-item.

(b) KDC Schema (ie. Kadmin-by-LDAP)

    - No documents yet.

    - JHutz: Anyone interested in this work? Who wants to deploy?

        Hank: may be Howard Chu (OpenLDAP) would be interested.
        Leif: lets ask Howard.
        Love: Howard has already started work (backend store).
        JHutz: But backend store is not in WG charter.
        Leif: Ask Simo & Howard to submit their work as draft.
              - Update the draft-chu-ldap-kdc-schema-00 and resubmit.

(c) Camellia Enctype (draft-krb-wg-kanno-camellia-00)

    - Thomas: Japanese Gov will soon (around 2013) mandate
           two ciphers to be supported for Japanese government use
           (namely AES and Camellia).  Thus makes sense to address
           Cammelia now. IPsec WG and TLS WG already have WG work items
           on Camellia.

    - JHutz: Should we adopt this as WG work item?

    - Sam: we should adopt Camellia generally but prefer 
           one Standards Track mode only. Need input from our
           Standards Track expert (Ken Raeburn).

    - Shawn: CTS mode is known to have issues.

    - JHutz: Need to read IANA policy.  It needs expert review
             and registration process.

    - Consensus check: Should WG adopt Camellia work?

         +  Hank: Yes in favor.
         +  Shawn: What about quality of cipher?
            - Thomas: same level of quality as AES.

         + Sam: should just choose one mode of Camellia
                for Standards Track based on quality.

         + Tim: Correcting Thomas, Camellia was not one of 
                the 15 candidates for AES competition.

         + JHutz: Consensus call based on the assumption that 
              there will be one Standards Track. 
              Shall the WG adopt work on Cammelia enctype for 
              standards track?:

              - In favor: medium hum.
              - Against: low hum
              - Who objects: 1 person (Mike Boyle) objects on the basis of 
                too many enctypes in Kerberos. Fewer algorithms is better. 
                Objection has nothing to do with quality of Camellia.

         + JHutz: IPR Disclosure from NTT has been received by WG chairs
                and Security ADs.

(VI) OPEN MIC

(a) Hank Holtz on KX509
    - Has a drafty doc on KX509
    - Work is based on UMich previous work, thus may have some IP issues.
    - KX509 is a cert acquisition protocol for a client to get a client-cert.

    - Questions/comments:
      (i) GregH:  Are these short-term certs ("junk certs")?
          Hank: Not neccesarilly. Can be used for long life certs.

      (ii) Hank to all: which WG should this work go into?
           Tim: Get clearance for the work. And then bring to 
                both PKIX WG and Kerberos WG.

      (iii) Love: Does not oppose this work, but notes that current KX509 
                  only supports RSA cryptosystem.
            Hank: Shall update the doc to include other ciphers.

      (iv) Scott Cantor: Is this an application layer protocol?
           Hank: - KX509 does not modify Kerberos or PKI.
                 - Provides symmetric opposite of PKINIT. 
                   It's a "bridge" protocol.

      (v) JHutz: It is still within scope of the Kerberos WG.
                 Its not the first time the WG taken-up similar work.

    - Action Item: Chairs will get together with Hank and Tim to discuss further.

(b) Comment from GregH on Jabber about GCM-based enc type.

------------------------------------------------------------------------

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

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 30 Mar 2010 15:04:14 -0400

>       a good idea (ie. better than nothing).

No, there's no ongoing mailing list discussion here.  The author, chairs, 
and AD are working on resolving a DISCUSS, after which the document will 
move forward.

>       + Anonymous draft just needs update in version-number.

This is backwards:  anonymous has some pending changes, followed by a new 
WGLC; naming will just need a version refresh.

>             to one realm (ie. folding name into realm).

This seems somewhat garbled.  The conclusion we came to, I think, is that 
principals may have multiple names, each of which has an associated realm. 
In particular, this means that principals may have names in multiple 
realms, but not the same set of names in every realm.

>       + Slight objection from Hank Holtz.

Note that we don't determine consensus based on hums in meeting rooms - 
that's really just a poll.  Any conclusions we came to during the meeting 
will be validated by discussion and/or a formal consensus call on this list.

Hank's last name is "Hotz".  I recall that he had an objection, but no 
longer remember what it was.  It would be good to document that.

>           - Leif: could people please send suggested text to the
> mailing-list             or to Leif. Note that WGLC is April 9th 2010.

But, and I tried to make this point clear in the meeting, the fact that 
WGLC times out on April 9 does _not_ mean that this issue must be resolved 
by then, or that we ignore the issue if someone doesn't provide text by 
then.  Issues raised during last call will be discussed and resolved, one 
way or another, before the document moves forward.  That could mean 
deciding the person who raised the issue is in the rough, but that doesn't 
happen automatically.

>              and registration process.

This is a bit garbled.  I reviewed the registration policy defined in 
RFC3961 for enctypes in real time during the meeting.  The policy is 
Standards Action or Expert Review.

>               Shall the WG adopt work on Cammelia enctype for

I stated no such assumption.  The assumption was that if the WG adopts the 
work, it will decide which modes etc to include, and at what level of 
recommendation.

>          + JHutz: IPR Disclosure from NTT has been received by WG chairs

Which is important, because it means that the previous hum was based on 
incomplete information.  Since the IPR issues are likely to affect the 
opinions of several WG members, and the disclosure was not immediately 
available for people to review, that hum is mostly meaningless (but should 
still be included in the minutes, for completeness; after all, it happened).

> (a) Hank Holtz on KX509

Technically this was under "Moving Forward", not open mic.  It was added to 
the agenda during agenda bashing at the start of the meeting.  And in fact, 
Henry had asked for time for this, and I simply forgot to include it on the 
original agenda.

Thanks for your excellent work in preparing these minutes.  Once the first 
round of comments has been resolved, we'll upload a draft to the IETF web 
site.

-- Jeff

---

From: "Henry B. Hotz" <[email-masked]>
Date: Tue, 30 Mar 2010 13:06:25 -0700

On Mar 30, 2010, at 12:04 PM, Jeffrey Hutzelman wrote:

> Hank's last name is "Hotz".  

No offense taken.  ;-)

> I recall that he had an objection, but no 

My "objection" is that I'm not sure I understand the implications of allowing multiple principal names which are not all the same realm.  Some other people in the room seemed to feel strongly that this should be allowed to support Enterprise infrastructures where a person might legitimately exist in multiple realms, IIUC.

Drifting off-topic toward review of the Info Model. . .

The reason I'm not sure I understand is that it appears to conflate authentication and authorization.  I would expect the cryptographic identity, as used in the Kerberos protocol, to be closely tied to a specific principal name for authentication purposes.  Defining multiple principal names to be equivalent, *especially* if they span multiple realms (and presumably multiple KDC's), is something I expect to do at an authorization level.  That happens *after* the Kerberos authentication is complete.

Since I know everyone is going to think of AD, let me point out that it has a multi-valued LDAP attribute, altSecurityIdentities, which simply lists all the principal names which refer to its entry.  While they have optimized some wire exchanges out of existence, basically they do Kerberos normally.  Then at the last minute they do an internal LDAP/authorization lookup against that attribute, and put the results into the authorization data field of the ticket.  This is architecturally equivalent to using Kerberos for authentication and LDAP for authorization, so it does not confuse me at all.  (I trust Larry will correct me if I've simplified things too much.)

This is all a long-winded way of saying that I haven't studied the latest draft or thought about it enough to have an opinion, so I don't want to block the RFC from going forward.

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]