Subject: Withdrawing concern about s2kparams and salt in encrypteddata

From: [email-masked] (Sam Hartman)
Date: Wed, 11 Feb 2004 14:17:59 -0500 (EST)

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.

I'm been thinking about that since and have come to the conclusion
that the only reason I felt uncomfortable was that the proposal was
different than how we do things now.

If people believe this change would be useful, I have no objections to
making it.

---

From: Ken Hornstein <[email-masked]>
Date: Wed, 11 Feb 2004 15:30:08 -0500

>uncomfortable with the proposal.

Just to be clear ... these were optional, right?  If so, no objections
here.

--Ken

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 11 Feb 2004 14:45:16 -0600

> Just to be clear ... these were optional, right?  If so, no objections

As I recall, they were proposed to be optional.

They'd have to be since they could only be useful where a receipient
could be expected to derive the decryption key from a longterm shared
secret -- obviously that can't be the case when dealing with session
keys!  (Well they could be ignored in such cases, but better make them
optional.)

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Wed, 11 Feb 2004 20:05:05 -0500

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

    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.

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 11 Feb 2004 21:41:09 -0600

> optional.  I.E. they would need to be included when the KDC knew the

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: Ken Hornstein <[email-masked]>
Date: Thu, 12 Feb 2004 10:57:19 -0500

>optional.  I.E. they would need to be included when the KDC knew the

I was thinking more in terms of "optional from an ASN.1 perspective".
Some KDCs may not know the information, because it simply doesn't exist,
right?  (e.g., a typical service key in a MIT KDC).

--Ken

---

From: Sam Hartman <[email-masked]>
Date: Thu, 12 Feb 2004 14:58:18 -0500

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

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

I think we shouldn't include them unless we consider this expectation
acceptable.

I don't trust any of us to successfully implement a fallback strategy
that does AS requests when the information is not available.

    Nicolas> Can these fields be placed in the clear part of the
    Nicolas> Ticket?  Or are we better off having them as optional in
    Nicolas> EncryptedData?
They can, but Larry's point is that kvno is already in encrypteddata.

Yes they clearly need to be optional at the ASN.1 layer.  However they
sort of need to be there if implementations will depend on them.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 12 Feb 2004 14:09:11 -0600

> They can, but Larry's point is that kvno is already in encrypteddata.

Good point.

> sort of need to be there if implementations will depend on them.

Yeah, ok.  So let's just say then that extensions KDCs must put these in
the ticket encpart encrypted data [for all target principals whose keys
have been created or changed after the realm upgraded to extensions?].

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Thu, 12 Feb 2004 15:18:56 -0500

Well only if the KDC knows the password for the key.  I think
extensions should gain some strong language about supporting keys for
services not just passwords.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 12 Feb 2004 14:17:40 -0600

> services not just passwords.

Does the KDC really need to know the password for the key?  I don't see
why.

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Thu, 12 Feb 2004 15:28:12 -0500

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> On Thu, Feb 12, 2004 at 03:18:56PM -0500, Sam Hartman
    Nicolas> wrote:
    >> extensions should gain some strong language about supporting
    >> keys for services not just passwords.

    Nicolas> Does the KDC really need to know the password for the
    Nicolas> key?  I don't see why.
The key needs to have been generated from a password.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 12 Feb 2004 14:33:45 -0600

> The key needs to have been generated from a password.

That doesn't mean that the KDC must continue to know the password.

---

From: Ken Hornstein <[email-masked]>
Date: Thu, 12 Feb 2004 15:51:22 -0500

>That doesn't mean that the KDC must continue to know the password.

As I understand it, _somebody_ needs to know the s2k params so the key
can be generated from the password, right?  Clearly the KDC will know
the s2kparams at some point, so it's the obvious person to keep track
of them.  So the KDC doesn't need to know the password, but it's
the obvious choice for supplying the s2kparams.

--Ken

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 12 Feb 2004 14:54:03 -0600

> the obvious choice for supplying the s2kparams.

Correct.

At worst we'll have to grandfather longterm keys generated prior to a
realm's upgrading to extensions.

With text like:

   "
   KDCs MUST include the kvno, s2params and salt optional fields of
   EncryptedData for the TicketEncPart for all service principals except
   where the service principals' longterm secret keys were generated
   prior to upgrading the realm's KDCs to support Kerberos V.2.
   "

Cheers,

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Thu, 12 Feb 2004 22:36:08 +0100 (MET)

> That doesn't mean that the KDC must continue to know the password.

I haven't closely followed the discussion, but some motivations
for the KDC to know the password were:

 - the KDC wants to check the password against some plaintext rules

 - the KDC is more than a KDC (e.g. like Microsoft's AD) and supports
   not only Kerberos, but also other authentication schemes with
   Kerberos-incompatible string2key algorithms.
   This may not apply to "pure" Kerberos environments, but I don't
   think that we should preclude synchronized passwords for differing
   authentication systems (aka gssapi mechanisms).

Remember that with the exception of the machine account, all services
on Microsoft W2K+ machines must have keys derived from printable
passwords because of how processes are started under service-accounts--
all the APIs on Win32 require plaintext passwords as the parameter,
none of them accepts a pure key.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 12 Feb 2004 15:34:00 -0600

>  - the KDC wants to check the password against some plaintext rules

Password quality checking is not related to the topic of this thread.

> none of them accepts a pure key.

This is what's underlying the proposal in question.

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 12 Feb 2004 16:37:38 -0500

>    prior to upgrading the realm's KDCs to support Kerberos V.2.

Uh, no?
First of all, let's not conflate the kvno and the other parameters.  All 
long-term keys have a kvno.  A salt and s2k parameters make sense only if 
the key was generated from a password.  This is not and will not be the 
case for all service principals, nor is it always the case for client 
principals.

Include the salt and s2k parameters if and only if the key in question was 
generated from a password.  Require extensions KDC's to store this 
information for service principals which have passwords.  Don't require 
those of us who presently generate random keys for our services to 
subscribe to Microsoft's (IMHO broken) model.

---

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

On Thu, Feb 12, 2004 at 04:37:38PM -0500, Jeffrey Hutzelman wrote:
> long-term keys have a kvno.

You're right about the kvno.

>                              A salt and s2k parameters make sense only if 

Client principals are not the issue.  We're talking about ensuring the
presence of the s2kparams/salt in the EncryptedData TicketEncPart.

As for service principals -- it's certainly possible to have the KDC
generate keys by generating "passwords" then applying string2key.  It
may well be simpler to just always generate keys that way, even when the
service principal will only store a key anyways.

> information for service principals which have passwords.

This is ok too.

>                                                           Don't require 

The text I posted wouldn't do that since as long as the key is generated
on the KDC, whether it is generated directly or by first applying s2k to
a random passphrase (not necessarily memorable) is irrelevant.

Nico
--

---

From: Ken Raeburn <[email-masked]>
Date: Thu, 12 Feb 2004 17:08:53 -0500

Catching up... I think it's a reasonable idea, but I'm concerned about
the ideas being kicked around about when the fields should be used.

"Liqiang(Larry) Zhu" <[email-masked]> writes:
> I expected these fields to be optional too. Perhaps encryptedata should
> either have all or none of the s2kparameter/salt/kvno fields.  

No, kvno should be separate, if only for the obvious case of a server
with two kvno values (if the key was just changed, and the old one
kept for compatibility with already-issued tickets), but no password
corresponding to the key and thus no useful s2kparam/salt values.

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

I believe it's not terribly uncommon when using the MIT implementation
to establish cross-realm keys by using passwords chosen by the
administrators and entered at both sites.  They passwords themselves
are not retained, and I don't think we want all cross-realm tickets to
carry along salt data in that case.

(Of course, this situation is already somewhat weak, and we really
should make it easy to type in an agreed-upon password into two
systems, and wind up with new, random long-term keys for each
direction, with the password effectively used to protect only the
negotiation of the "better" key.  And obviously neither administrator
should have to type his password into the other's system.)

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

In the case above, it specifically indicates to an observer that a
password was used, and supplies the auxiliary data needed to begin a
dictionary attack against the long-term key used to encrypt the
included data.  Depending on preauth requirements or other KDC flags,
it might not be otherwise possible to get that information for a
server principal.

> 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.
> another reason is that we support muitiple keys for the same enctype
> derived from different string2key parameters. but this is hardly a
> reason.

Actually this sounds like a pretty good reason to me, if we want to
support that mode.

Ken

---

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

I'm starting to find this ugly again.

What alternatives does MS have?  Larry, have you explorer other
solutions?

Nico
--