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

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

Nicolas Williams wrote:
> And please remind me why acceptors that remember their "passwords"
> (instead of their keys) can't also remember the s2k params/salts.
 
our existing APIs do not allow applications to supply the additonal and new s2kparameters.
 
another reason is that we support muitiple keys for the same enctype derived from different string2key parameters. but this is hardly a reason.
 
for interop issues, I would prefer your option #1.

Larry 

________________________________

From: Nicolas Williams [mailto:[email-masked]]
Sent: Thu 2/12/2004 8:31 AM
To: Liqiang(Larry) Zhu
Cc: Sam Hartman; Ken Hornstein; [email-masked]
Subject: Re: Withdrawing concern about s2kparams and salt in encrypteddata

On Thu, Feb 12, 2004 at 12:58:24AM -0800, Liqiang(Larry) Zhu wrote:
> 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.

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

> 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?

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
--

---

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

> for interop issues, I would prefer your option #1.

Which means your platform has to cope with the absence of those fields,
which, as we've discussed, it can do by discovering [and caching] the
params with AS exchanges -- as annoying as that might be it's better
than not interoperating.

In any case, I also don't think it should be so hard to ensure that
extensions KDCs always support those fields for new keys.

So I drop the objection to those fields also.

Cheers,

Nico
--