Subject: RE: Withdrawing concern about s2kparams and salt in encrypteddata

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Thu, 12 Feb 2004 00:58:24 -0800

I expected these fields to be optional too. Perhaps encryptedata should
either have all or none of the s2kparameter/salt/kvno fields.  

The KDC should be allowed to either omit or emit all of these fields
based on its local policy, when the key being used was reduced from a
pass phrase.

Do you see any significant risk if we have the s2kparameter and salt,
which are likely left as un-authenticated, carried along with the
encrypteddata?

Larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Nicolas
Williams
Sent: Wednesday, February 11, 2004 7:41 PM
To: Sam Hartman
Cc: Ken Hornstein; [email-masked]
Subject: Re: Withdrawing concern about s2kparams and salt in
encrypteddata

On Wed, Feb 11, 2004 at 08:05:05PM -0500, Sam Hartman wrote:
> >>>>> "Ken" == Ken Hornstein <[email-masked]> writes:
> 
>     >> At the Boulder meeting, Larry proposed adding s2kparams and
>     >> salt strings to encrypteddata.  At that time I said that I felt
>     >> uncomfortable with the proposal.
> 
>     Ken> Just to be clear ... these were optional, right?  If so, no
>     Ken> objections here.
> 
> For them to be useful for what Larry wants, they couldn't be all that
> optional.  I.E. they would need to be included when the KDC knew the
> information.

But they couldn't be useful for, say, the Authenticator, so they'd have
to be optional.

Are we expecting that some implementations will _require_ that the
Ticket enc part will include these optional fields?

Can these fields be placed in the clear part of the Ticket?  Or are we
better off having them as optional in EncryptedData?

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 12 Feb 2004 10:31:31 -0600

> based on its local policy, when the key being used was reduced from a

This means that the KDC must know if the principal expects those fields
or not.  Something for the change-pw/set-keys v2 protocol.

> which are likely left as un-authenticated, carried along with the

Well, there's a DoS attack, but the same mitigation that applies for the
PA-ENC-TIMESTAMP situation applies here too, so that's nothing new.

My concern is that some acceptor implementations will insist that these
optional fields be present while some KDC implementations may not
support them at all, which would lead to an interop problem.  Please
convince me that we can prevent this.

I see three ways to "prevent" the interop problem:

 - declare that extensions acceptors MUST be able to deal with the
   absence of those fields

 - require support for this in all extensions KDCs

 - tie this to the change-pw/set-keys protocol and require support for
   this in all KDCs

And please remind me why acceptors that remember their "passwords"
(instead of their keys) can't also remember the s2k params/salts.

Nico
--