Subject: IETF65 krb-wg meeting summary

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 20 Apr 2006 12:01:59 -0400

Apparently I never posted this...

Kerberos Working Group - IETF 65 meeting summary

ACTION ITEMS:
  * chair: Get Anonymous listed as a WG item
  * chair: Update milestones
  * lzhu: Evaluate hash strength issue for PKINIT ECC
  * jhutz, lzhu, lha: Figure out milestone for PKINIT Hash Agility
  * jhutz, nico, shawn: Figure out milestone for RFC4121 Hash Agility
  * hartmans: Find out if Nov 2006 is reasonable MS for hash agility

  * New Document Authors
    - PKINIT Hash Agility - Love, Larry
    - RFC4121 Hash Agility - Shawn Emery

MILESTONES:
  Done   - Consensus on direction for Change/Set password
  Jul 06 - Review milestones
  Jul 06 - Last Call Anonymous
  TBD    - Last Call PKINIT Hash Agility
  TBD    - Last Call RFC4121 Hash Agility

+ There was a brief summary of ongoing work:
  - PKINIT - Approved
  - PKINIT OSCP - Approved
  - Enctype-Nego - Approved

+ There was a discussion of anonymity and of Larry's draft.
  The sense of the room was that this document was going in the right
  direction and should be adopted as a WG item.  There was discussion
  on the issue of what client principal name should appear in anonymous
  tickets, and of the ticket substitution attack described by Aaron.

+ There was a discussion of algorithm agility in Kerberos and related
  protocols, particularly as it relates to hashes:

  - The core Kerberos protocol has always had enctype negotiation, which
    also negotiates use of associated checksum types.  With the approval
    of the enctype-negotiation document, it is possible for applications
    to negotiate use of an enctype not supported by the KDC.
  - RFC4121 (the Kerberos GSSAPI mechanism) has an issue with channel
    bindings, which are currently protected using MD5.  A work item has
    been added to correct this; Shawn Emery will act as editor.
  - PKINIT has several algorithm negotiation issues and currently uses
    SHA-1 as the only checksum algorithm in the paChecksum slot.  A work
    item was added to add the required negotiation ability to PKINIT and
    specify stronger hashes.  Larry Zhu and Love Hörnquist-Åstrand have
    agreed to edit this document.

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 20 Apr 2006 18:16:46 +0200

>  Done   - Consensus on direction for Change/Set password

Is there more information on what that means?  In general, are there
any minutes from the last meeting?  I like the change/set password
protocol in general, and plan to have it implemented.

Thanks,
Simon

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 20 Apr 2006 12:22:08 -0400

On Thursday, April 20, 2006 06:16:46 PM +0200 Simon Josefsson 
<[email-masked]> wrote:

> Is there more information on what that means?

It means the milestone has been accomplished.  That didn't happen at the 
meeting; it was just recorded here as a state change since the last meeting.

> In general, are there
> any minutes from the last meeting?

They're in progress, and will be posted soon.

-- Jeff

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 20 Apr 2006 18:26:01 +0200

Jeffrey Hutzelman <[email-masked]> writes:

> It means the milestone has been accomplished.  That didn't happen at
> the meeting; it was just recorded here as a state change since the
> last meeting.

Ok.  What direction was chosen?  I haven't seen any substantial
discussions about the change/set password protocol on this list in a
long time.

Thanks,
Simon

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 20 Apr 2006 12:55:50 -0400

> discussions about the change/set password protocol on this list in a

There hasn't been a lot of discussion, but there's been some off and on. 
The longstanding milestone was to get consensus on whether we were going 
the right direction with Nico's draft; I think we came to the conclusion by 
Vancouver that we were, and the milestone just had never been updated.

-- Jeff

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 20 Apr 2006 18:57:34 +0200

Jeffrey Hutzelman <[email-masked]> writes:

> There hasn't been a lot of discussion, but there's been some off and
> on. The longstanding milestone was to get consensus on whether we were
> going the right direction with Nico's draft; I think we came to the
> conclusion by Vancouver that we were, and the milestone just had never
> been updated.

Ah, then I understand.  FWIW, I agree that the draft is going in the
right direction.

Thanks,
Simon

---

From: Chaskiel M Grundman <[email-masked]>
Date: Thu, 20 Apr 2006 17:15:16 -0400

--On Thursday, April 20, 2006 12:01:59 -0400 Jeffrey Hutzelman 
<[email-masked]> wrote:

> [...], and of the ticket substitution attack described by Aaron.
That reminds me....

Was there any consensus on how real/significant this issue is? I have (just 
now) examined the relevant slides from the proceedings archive. 
<http://www3.ietf.org/proceedings/06mar/slides/krb-wg-1.pdf>

Scenario 1 on page 3 looks like the thing we already discusses in early 
march, and, IIRC concluded that since there was no cryptographic binding 
between the request and the identity, that the attack was meaningless.

It appears that in Scenario 2, if all the pre-requisites were met, an 
attacker could make a "should be anonymous" request non-anonymous, but only 
at the expense of making a "should be non-anonymous" request fail. In 
addition, the "outed" request would fail mutual authentication, if mutual 
is attempted, since the reply would be encrypted with SKc, and the client 
will be expecting SKanon. As there is no SKanon reply for the attacker to 
substitute, the client cannot be prevented from knowing that the 
authentication did not succeed.
I will argue that any correctly written application (even those that are 
only marginally correct) either a) depends upon a pre-existing 
integrity-protected channel (which prevents scenario, or b) provides its 
own integrity protection, either poorly, based on SKanon, or correctly, 
using authenticator-asserted subkeys. The attacker cannot compensate for 
either of these mechanisms, and so the only thing that S learns is that C 
wanted to be a client of S, which it would have learned anyway if the 
attacker did not interfere with the non-anonymous request.

I don't mean to suggest that we don't try to strengthen kerberos against 
such attacks (say, by enhancing the TGS in extensions by adding checksums 
of the KDC-REQ-BODY and/or returned Ticket in the EncKDCRepPart as part of 
the "no unsigned plaintext" initiative.), but I don't think this attack is 
meaningful as-is.