Subject: Re: [Ietf-krb-wg] DISCUSS and COMMENT: draft-ietf-krb-wg-preauth-framework

From: Sam Hartman <[email-masked]>
Date: Sat, 15 May 2010 13:10:26 -0400

>>>>> "Russ" == Russ Housley <[email-masked]> writes:

    Russ> Discuss: Section 5.1 says:
    >> 
    >> New mechanisms MUST NOT be hard-wired to use a specific
    >> algorithm.
    >> 
    Russ>   While I am a strong supported of algorithm agility, I can
    Russ> imagine a pre-authentication mechanism that is not algorithm
    Russ> agile.  Given the type fields in the protocol, many of the
    Russ> reasons for a MUST NOT statement are already addressed.  Would
    Russ> it be appropriate for two pre-auth mechanism to be defined
    Russ> that use ZKPP techniques, one that makes use for discrete log
    Russ> and another that makes use of elliptic curve?

Russ, thanks for drawing my attention back to this section; it's amazing
how things can bit-rot in a document you've been working on since 2004.

I agree with your point.  However, there is a more serious problem in
the previous paragraph: <t> If there is more than one round trip for an
authentication exchange, mechanism designers need to allow either the
client or the KDC to provide a checksum of all the messages exchan\ ged
on the wire in the conversation, and the checksum is then verified by
the receiver.</t> That's a fine strategy, and it's what we started out
with, but by the time we were done, FAST (a mechanism described in this
draft) uses a different strategy.  All the content is covered by a MAC
and is verified by the receiver as it is received.
So,  I propose to replace both paragraphs with the following which I
believe is much closer to the actual security requirement:

	<t>Mechanisms MUST guarantee that by the end of a successful
 authentication exchange, both the client and the KDC have verified
 all the plaintext sent by the other party. Strategies for
 accomplishing this include using message authentication codes (MACs) to
 protect the plaintext as it is sent or exchanging a MAC of the entire
 conversation after a key is established. Mechanism designers need to
 provide a strategy for updating cryptographic algorithms, such as
 providing negotiation of the algorithm within the mechanism or
 defining a new pre-authentication type for the new algorithm.</t>

Pending your review and WG approval I'll make this change.  I'm also
going to make changes I hope will address your comments although I don't
think those involve a round trip with the WG.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg