Subject: KRB-WG IETF64 Session Summary

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 10 Nov 2005 15:33:44 -0500 (EST)

Kerberos Working Group - IETF 64 meeting summary

DECISIONS (also see PKINIT issues below)
  * Sam's compromise on AS-REQ signing in PKINIT

ACTION ITEMS:
  * chair: Get ECC listed as a WG item
  * chair: Send enctype-nego to IESG
  * chair: Update milestones
  * jaltman: Review PKINIT, find ASN.1 comments
  * lzhu, lha: check that the PKINIT ASN.1 module compiles
  * tlyu: check on TD-DH-PARAMETERS underspecification
  * lzhu: add text on empty sequences
  * lzhu: add text on signed attribute
  * jaltman: introduction proposal

MILESTONES:
  Done   - Consensus on direction for Change/Set password
  Nov 05 - PKINIT to IESG
  Nov 05 - Enctype Negotiation to IESG
  Dec 05 - Last Call on PKINIT ECC
  Mar 06 - Issues identified for Anonymous
  Mar 06 - Review milestones
  Jun 06 - Major issues resolved on Extensions
  Aug 06 - Last Call on Extensions
  Aug 06 - Last Call on Referrals
  Sep 06 - Last Call on Change/Set password

- Jeff Altman gave a special presentation to thank Cliff Neuman for
  his efforts on Kerberos development and specifically on completing
  RFC4120.  Cliff was unable to be present in person, but was present
  in the Jabber room.  In appreciation of his efforts, Cliff will
  receive a bound copy of RFC4120, signed by others who worked on the
  document, and an iPod Nano.

- There was a brief summary of ongoing work:
  + PKINIT - Last Call expired Sunday; issues to be discussed today
  + PKINIT OSCP - Sent to IESG; waiting to be ballotted with PKINIT
  + PKINIT ECC - Adopted as WG Item
  + RFC1510ter - Updated with changes from interim meeting
  + Enctype-Nego - WGLC issues dealt with; ready to go to IESG
  + Referrals -
  + RC4 enctype - Individual submission for pub as informational

- Sam Hartman gave a presentation describing some assumptions currently
  made in Kerberos that we might want to reconsider as we work on
  extensions.

- Larry's anonymity draft was discussed.  Aaron described a ticket
  substitution attack which could result in a client's identity being
  revealed to a server which the client intended to contact anonymously.
  Work on this draft is still ongoing.

- We discussed issues raised during the last call on PKINIT
  + The ASN.1 module is over-tagged -- the WG is aware of this issue and
    has discussed it previously; we will not be reopening it.
  + Use of OCTET STRING wrappers -- the WG discussed this in great detail
    and weighed the issues before deciding to use OCTET STRING wrappers;
    see ticket #527 in RT.  This issue will not be reopened.
  + Constraint style -- the issue of use of formal constriants versus
    textual requirements has been discussed extensively, and the current
    document reflects the consensus of the working group on this issue.
  + Normative text in ASN.1 comments -- it was the previous consensus of
    the group that normative text should not appear _only_ in comments.
    Jeff Altman volunteered to look for places where this occurs as part
    of his review.
  + TD-DH-PARAMETERS not signed -- Love withdrew this objection
  + AS-REQ not signed in DH case -- Sam Hartman proposed a compromise,
    to fix the problem when we deal with upgrading hash functions.
    The sense of the room supported the proposal; to be validated on-list.
  + TD-DH-PARAMETERS reference -- Love thinks this is underspecified,
    but doesn't have the IEEE document to check.  Tom Yu volunteered to
    look into it, provided the document is in MIT's subscription.
  + Empty vs missing sequences -- Larry will add text indicating they
    are equivalent.
  + signed attribute - Larry will add text referencing RFC3369.
  + Introduction - jaltman doesn't like the introduction; will propose
    new text on the list
  + Hash Upgrade Strategy

- Milestones were updated (see above)

---

From: "Aaron D. Jaggard" <[email-masked]>
Date: Sat, 12 Nov 2005 01:03:26 -0800

>     The sense of the room supported the proposal; to be validated on-list.

If we do this, would it be appropriate to add something like the
following to the security considerations?

"While there are no attacks currently known against DH mode, this mode
does not currently bind the  AS-REQ and AS-REP messages (as is done
using asChecksum in RSA mode).  We anticipate addressing this issue
when we address hash function upgrades."

Best,  Aaron

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Sat, 12 Nov 2005 02:23:49 -0800

Aaron wrote:
> this mode
> does not currently bind the  AS-REQ and AS-REP messages 
 
In the DH case, the AS_REQ and AS_REP are bound via the paChecksum and the nonces. 

________________________________

From: [email-masked] on behalf of Aaron D. Jaggard
Sent: Sat 11/12/2005 1:03 AM
To: Jeffrey Hutzelman; [email-masked]
Cc: [email-masked]
Subject: Re: KRB-WG IETF64 Session Summary

Best,  Aaron

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Sat, 12 Nov 2005 18:20:07 -0800

Larry,

The KDC-REQ-BODY is bound to the pk-init pa-data using paChecksum and the
nounces. This leaves out all other pa-data sent in the request. For
example, an attacker can inserts KRB5-PADATA-PA-PAC-REQUEST without the
client nor server detecting it.

Love

"Liqiang(Larry) Zhu" <[email-masked]> writes:

> -------------------------------------------------------------------------------

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Sat, 12 Nov 2005 21:01:25 -0800

> an attacker can inserts KRB5-PADATA-PA-PAC-REQUEST without 
 
> the
 
this is a DOS, and MS servers will detect it and reject the authentication.

From: [email-masked] on behalf of Love Hörnquist Åstrand
Sent: Sat 11/12/2005 6:20 PM
To: Liqiang(Larry) Zhu
Cc: Aaron D. Jaggard; Jeffrey Hutzelman; [email-masked]
Subject: Re: KRB-WG IETF64 Session Summary

Larry,

Love

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Sun, 13 Nov 2005 16:03:03 +0100

> this is a DOS, and MS servers will detect it and reject the authentication.

I'm pointing out in the mail to Aaron that you said something incorrect.
Today, binding is between KDC-REQ-BODY and pk-init request data, not the
KDC-REQ and pk-init request data as you claimed.

It doesn't matter is microsoft detects the problem or not, its still a
problem that the requsted is unprotected. You have prompised to fix it at
the same time as we fix the SHA1 checksum problem.

Love

> From: [email-masked] on behalf of Love H?rnquist ?strand

---

From: "Aaron D. Jaggard" <[email-masked]>
Date: Sun, 13 Nov 2005 12:17:24 -0800

However they're best described, should the concerns that were
discussed at the meeting and the anticipated response (Sam's proposal)
be noted in the security considerations section? (Assuming consensus)

Best,  Aaron

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Sun, 13 Nov 2005 12:37:41 -0800

I would propose to write a separate I-D to describe the generic issue, that is not specific to PKINIT.
 
do you want to volunteer for such I-D?

From: Aaron D. Jaggard [mailto:[email-masked]]
Sent: Sun 11/13/2005 12:17 PM
To: Love Hörnquist Åstrand
Cc: Liqiang(Larry) Zhu; Jeffrey Hutzelman; [email-masked]; [email-masked]
Subject: Re: KRB-WG IETF64 Session Summary

Best,  Aaron

---

From: "Aaron D. Jaggard" <[email-masked]>
Date: Sun, 13 Nov 2005 17:04:10 -0800

If this would be helpful, I'd be happy to.

Best,  Aaron

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Sun, 13 Nov 2005 19:01:16 -0800

It is definitely going to be helpful for folks designing new padata types within the framework of RFC4120. 
 
may I assume this is resolved as far as you are concerned then.
 
-- Larry

From: Aaron D. Jaggard [mailto:[email-masked]]
Sent: Sun 11/13/2005 5:04 PM
To: Liqiang(Larry) Zhu
Cc: Love Hörnquist Åstrand; Jeffrey Hutzelman; [email-masked]; [email-masked]
Subject: Re: KRB-WG IETF64 Session Summary

Best,  Aaron

---

From: Sam Hartman <[email-masked]>
Date: Mon, 14 Nov 2005 14:50:01 -0500

>>>>> "Aaron" == Aaron D Jaggard <[email-masked]> writes:

    Aaron> However they're best described, should the concerns that
    Aaron> were discussed at the meeting and the anticipated response
    Aaron> (Sam's proposal) be noted in the security considerations
    Aaron> section? (Assuming consensus)

IMHO, as an individual, yes.