Subject: RE: String-to-key parameters in setpasswd?

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Wed, 3 Dec 2003 18:16:44 -0800

Nicolas Williams wrote:
>>> If that's OK with them I'm happy.

>> Yes, let's hear from MS on this :)

It sounds odd to have s2k parameters missing in the password change
protocol. Can we look into the complexity introduced by replacing the
"sequence of etype" in req-change-pw with ETYPE_INFO2?  I do agree that
the s2k parameters can be discovered via AS_REQ if the DC is reachable
within the framework of the clarifications, or simply be provided by a
ticket extension otherwise.

Larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Nicolas
Williams
Sent: Wednesday, December 03, 2003 11:32 AM
To: Sam Hartman
Cc: Simon Josefsson; [email-masked]
Subject: Re: String-to-key parameters in setpasswd?

On Wed, Dec 03, 2003 at 02:25:58PM -0500, Sam Hartman wrote:
> >>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:
> 
>     >> The Microsoft case where machines have a random password.
> 
>     Nicolas> But they can do an AS exchange (they'll have to anyways).
> 
>     Nicolas> Nico --
> 
> 
> If that's OK with them I'm happy.

Yes, let's hear from MS on this :)

But note that if they generally do an AS exchange after changing a host
password then that's enough to convince me to not put this in setpasswd.

Nico
--

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Mon, 8 Dec 2003 15:09:56 -0800

Here is the new text for the security consideration section, based on
comments in this thread. Larry

=========================================
7. Security Considerations

Channel bindings are validated by the acceptor.  The acceptor can ignore
the channel bindings restriction supplied by the initiator and carried
in the authenticator checksum, if channel bindings are not used by
GSS_Accept_sec_context [RFC-2743], and the acceptor does not prove to
the initiator that it has the same channel bindings as the initiator,
even if the client requested mutual authentication.     This limitation
should be taken into consideration by designers of applications that
would use channel bindings, whether to limit the use of GSS-API contexts
to nodes with specific network addresses, to authenticate other
established, secure channels using Kerberos V, or for any other purpose.

Session key types are selected by the KDC.  Under the current mechanism,
no negotiation of algorithm types occurs, so server-side (acceptor)
implementations cannot request that clients not use algorithm types not
understood by the server.  However, administrators can control what
enctypes can be used for session keys for this mechanism by controlling
the set of the ticket session key enctypes which the KDC is willing to
use in tickets for a given acceptor principal.  The KDC could therefore
be given the task of limiting session keys for a given service to types
actually supported by the Kerberos and GSSAPI software on the server.
This does have a drawback for cases where a service principal name is
used both for GSSAPI-based and non-GSSAPI-based communication (most
notably the "host" service key), if the GSSAPI implementation does not
understand (for example) AES [AES-KRB5] but the Kerberos implementation
does.  It means that AES session keys cannot be issued for that service
principal, which keeps the protection of non-GSSAPI services weaker than
necessary.  KDC administrators desiring to limit the session key types
to support interoperability with such GSSAPI implementations should
carefully weigh the reduction in protection offered by such mechanisms
against the benefits of interoperability.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Nicolas
Williams
Sent: Wednesday, December 03, 2003 12:10 PM
To: Ben Cox
Cc: [email-masked]
Subject: Re: String-to-key parameters in setpasswd?

On Wed, Dec 03, 2003 at 03:04:07PM -0500, Ben Cox wrote:
> Sam:
> >>>>Will the client want to know what s2kparams are chosen though?
> 
> Yes.
> 
> Nico:
> >>    Nicolas> Why?  It will find out what they are when it tries to
get
> >>    Nicolas> an initial ticket.  No need to complicate setpasswd
> >>    Nicolas> unnecessarily.
> 
> Not everyone who uses setpasswd will get initial tickets, at least 
> won't necessarily have to do so before they need to use their keys.  
> E.g.:
> 
> Sam:
> Some non-Microsoft implementations also use random passwords to set 
> service keys.

Nonetheless they use those keys to get initial tickets, not just to
accept AP exchanges (AFAIU).

> Nico:
> >But they can do an AS exchange (they'll have to anyways).
> 
> Not all implementations that do this will do AS exchanges.  Some
server 
> implementations use randomized passwords that are used only for 
> accepting client tickets.

Preferably there would be no implementations that set random passwords
and use those to generate keys for accepting AP exchanges with.

> We recently had to add a gratuitous AS exchange to our server code 
> after calling the existing setpasswd, in order to determine which of a

> few possible keys the PDC had derived from the password we set.  It 
> would be nice not to perpetuate the necessity for this sort of hack.

Does your implementation use the same principal's random password-
derived keys for, say, securing LDAP queries initiated by it?

At the moment I forget what we concluded at the last interim meeting,
where, as I recall, a similar issue came up.  In any case, if you and/or
MS insist I may not and I think we can reach a consensus that setpasswd
should tell the client what s2kparams it used.  

Nico
--