headers
Ron Hoffman | 3 Apr 2002 16:23
Picon

Re: DES key derivation

It is taken directly from the MIT Kerberos V5 1.2.2 code.  Look at
k5_des_make_key() in src/lib/crypto/enc_provider/des.c.  This is the
situation where the key is derived from 56 bits of key material.  The
algorithm is different when the key is derived from a password string
(mit_des_string_to_key()).  I'll take a look at the DES FIPS since I
think that would be the correct way to generate the key for DES-MAC and
DES-CBC.

Ron

----- Original Message -----
From: "Ted Anderson" <ota <at> transarc.com>
To: "nfsv4-wg" <nfsv4-wg <at> sunroof.eng.sun.com>; "Ron Hoffman"
<rhoffman <at> stny.rr.com>
Sent: Wednesday, April 03, 2002 7:38 AM
Subject: Re: DES key derivation

> This description doesn't match my recollection of how Kerberos 4
works.
> In the AFS implementation of the Kerberos server, which interoperates
> with the MIT version, the keys are derived by hashing the password
then
> forcing odd parity.  This latter function[1] computes the parity of
each
> byte and stores it in the least significant bit.  I recall that this
> mapping from 56 to 64 bits is specified in the original DES FIPS[2].
> While it is possible that this changed in K5, I doubt it.
>
> On Tue, 26 Mar 2002 16:42:29 -0500 "Ron Hoffman"
<rhoffman <at> stny.rr.com> wrote:
(Continue reading)

Permalink | Reply | 4 comments |
headers
Ron Hoffman | 3 Apr 2002 16:56
Picon

Re: DES key derivation

I don't see anything pertinent in the DES FIPS.  It describes the format
of the 8-byte key (7 key bits and 1 parity bit per byte).  But unless I
missed it, it doesn't say how those key bits are set from a raw 56-bit
value (and it really doesn't matter as far as DES itself is concerned).
So the question really relates to RFC 2025.  The RFC tells how to
generate 56 bits of key material but doesn't specify how those bits are
mapped into the 8-byte DES key.  The RFC also doesn't say what happens
if the generated key is a weak DES key.

The OpenSSL code has a DES key generation routine.  However, this
routine generates 64 bits of key material and then sets the correct
parity on each byte (essentially throwing away 8 of the key material
bits)

So, I've come up with 3 choices so far:

1) Generate 56 bits using the RFC 2025 generation algorithm and then map
these bits in order to the key bits in the 8-byte DES key (skipping the
parity bit in each byte).  There are two sub-variations here where the
mapping is done from MSBit to LSBit or from LSBit to MSBit in each tye.
I think this is the correct interpretation with the mapping done from
MSBit to LSBit.

2) Generate 56 bits using the RFC 2025 generation algorithm and use the
7-byte value as the first 7 bytes of the DES key.  Generate the eighth
byte from the LSBit of each of the key material bytes.  There are again
two sub-variations (Kerberos generates the last byte from LSBit to
MSBit).

3) Generate 64 bits using the RFC 2025 generation algorithm and then
(Continue reading)

Permalink | Reply | 3 comments |
headers
RJ Atkinson | 3 Apr 2002 17:03
Favicon

Re: DES key derivation

On Wednesday, April 3, 2002, at 09:56 , Ron Hoffman wrote:
> 1) Generate 56 bits using the RFC 2025 generation algorithm and then map
> these bits in order to the key bits in the 8-byte DES key (skipping the
> parity bit in each byte).  There are two sub-variations here where the
> mapping is done from MSBit to LSBit or from LSBit to MSBit in each tye.
> I think this is the correct interpretation with the mapping done from
> MSBit to LSBit.

	This sounds right to me, where "skipping the parity bit
in each byte" means don't waste any of the 56 bits of entropy
on a parity bit position -- instead set the parity bit correctly
based on the 7-bits of entropy in that byte (where the 7
bits are part of the 56 bits previously generated).

Ran
Permalink | Reply | 1 comment |
headers
RJ Atkinson | 3 Apr 2002 17:08
Favicon

Re: DES key derivation

On Wednesday, April 3, 2002, at 09:56 , Ron Hoffman wrote:
> So, I've come up with 3 choices so far:

	Whenever the documents get edited, the selected choice
ought to be made crystal clear in the next document version.
That we have more than 1 choice means the current documents
are not adequately clear.

IMHO,

Ran
Permalink | Reply | 0 comments |
headers
Ron Hoffman | 3 Apr 2002 18:20
Picon

Re: DES key derivation

Sounds good to me.  I'll map the bits using option 1 then (going from
MSBit to LSBit in each byte).  I'll still check for a weak key after
constructing the 8-byte key and exclusive-or the last byte with x'f0' so
that Kerberos will be happy with the key (we shouldn't use a weak key
anyways to encrypt application data)

Ron

----- Original Message -----
From: "RJ Atkinson" <rja <at> extremenetworks.com>
To: "Ron Hoffman" <rhoffman <at> stny.rr.com>
Cc: "nfsv4-wg" <nfsv4-wg <at> sunroof.eng.sun.com>; "Ted Anderson"
<ota <at> transarc.com>
Sent: Wednesday, April 03, 2002 10:03 AM
Subject: Re: DES key derivation

>
> On Wednesday, April 3, 2002, at 09:56 , Ron Hoffman wrote:
> > 1) Generate 56 bits using the RFC 2025 generation algorithm and then
map
> > these bits in order to the key bits in the 8-byte DES key (skipping
the
> > parity bit in each byte).  There are two sub-variations here where
the
> > mapping is done from MSBit to LSBit or from LSBit to MSBit in each
tye.
> > I think this is the correct interpretation with the mapping done
from
> > MSBit to LSBit.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ron Hoffman | 6 Apr 2002 16:44
Picon

K-ALG negotiation

LIPKEY has a problem if the underlying SPKM-3 mechanism performs K-ALG
negotiation.  LIPKEY assumes that the SPKM-3 context will be established
after 2 messages (REQUEST and REPLY-TI).  However, if K-ALG negotiation
occurs, there will be a REPLY-IT message from the initiator.  There will
be no message returned from the acceptor in response since the SPKM-3
context will now be established.

The problem is how to continue with the LIPKEY context establishment in
this situation.  I think there are 4 options:

1) Ignore this scenario and mandate that K-ALG negotiation cannot occur.
This raises a future interoperability issue if a new K-ALG is
introduced.

2) Have the LIPKEY gss_accept_sec_context() return GSS_S_CONTINUE_NEEDED
and a zero-length output token after processing the REPLY-IT message to
complete the SPKM-3 context establishment.  This means
gss_init_sec_context() would need to be called with a zero-length input
token.  I'm not sure this is legal.  RFC 2743 seems to imply that
GSS_S_CONTINUE_NEEDED indicates the output token is to be sent to the
partner and yet a zero-length token means no token is to be sent.

3) Combine the final output token from gss_init_sec_context() with the
gss_wrap() token for the LIPKEY signon.  This would be for the case
where the SPKM-3 gss_init_sec_context() returned an output token with
GSS_S_COMPLETE status.

4) Define a new LIPKEY token to be sent from the acceptor to the
initiator to handle the case where the SPKM-3 gss_accept_sec_context()
returned GSS_S_COMPLETE and no output token.  This token would trigger
(Continue reading)

Permalink | Reply | 0 comments |
headers
Khan, Saadia | 10 Apr 2002 00:47
Picon

Interaction between mode bits and acls

Hi,

I dont see anything in the spec that talks about how the mode bits and acls should interact with each other if
both 
are present. I would say once an acl has been created on an object, all perm checks should be done relative to
that and a best effort mapping should be done for the mode bits only to be used as display permissions such as
when someone does an 'ls -l'. However there can be issues with accessing files if a user sets the permissions 
using acls and another user on a different client (without acl support, can be v2/v3 client) tries to access
the file 
based on what he sees from 'ls -l'.

The other option of keeping them both consistent with each other at all times and doing permission checks using
both doesn;t seem very appealing and also involves extra work on the part of the server.

Any suggestions or feedback on this issue would be appreciated. What are other implementations doing?

thanks.
Saadia
Permalink | Reply | 2 comments |
headers
Peter Staubach | 10 Apr 2002 01:58
Picon

Re: Interaction between mode bits and acls

> 
> I dont see anything in the spec that talks about how the mode bits and acls 
should interact with each other if both 
> are present. I would say once an acl has been created on an object, all perm 
checks should be done relative to
> that and a best effort mapping should be done for the mode bits only to be 
used as display permissions such as
> when someone does an 'ls -l'. However there can be issues with accessing files 
if a user sets the permissions 
> using acls and another user on a different client (without acl support, can be 
v2/v3 client) tries to access the file 
> based on what he sees from 'ls -l'.
> 
> The other option of keeping them both consistent with each other at all times 
and doing permission checks using
> both doesn;t seem very appealing and also involves extra work on the part of 
the server.
> 
> Any suggestions or feedback on this issue would be appreciated. What are other 
implementations doing?
> 

As of NFS Version 3, clients don't make access decisions based on
either ACL entries or mode bits.  They ask the server for pertinent
access rights.  It is up to the server to resolve `conflicts' between
the mode bits and any ACL entries.

The client should not be trying to determine access rights on its own.
It can't correctly determine them.  Root mapping on a UNIX based server
is a good example of why clients can not correctly determine access
(Continue reading)

Permalink | Reply | 0 comments |
headers
Khan, Saadia | 10 Apr 2002 02:31
Picon

RE: Interaction between mode bits and acls

yes, this is all in relation to what the server would do in these
situations.

Saadia

> -----Original Message-----
> From: Peter Staubach [mailto:Peter.Staubach <at> Sun.COM]
> Sent: Tuesday, April 09, 2002 4:59 PM
> To: nfsv4-wg <at> sunroof.eng.sun.com; Saadia.Khan <at> netapp.com
> Subject: Re: Interaction between mode bits and acls
> 
> 
> 
> > 
> > I dont see anything in the spec that talks about how the 
> mode bits and acls 
> should interact with each other if both 
> > are present. I would say once an acl has been created on an 
> object, all perm 
> checks should be done relative to
> > that and a best effort mapping should be done for the mode 
> bits only to be 
> used as display permissions such as
> > when someone does an 'ls -l'. However there can be issues 
> with accessing files 
> if a user sets the permissions 
> > using acls and another user on a different client (without 
> acl support, can be 
> v2/v3 client) tries to access the file 
> > based on what he sees from 'ls -l'.
(Continue reading)

Permalink | Reply | 1 comment |
headers
John Howard | 10 Apr 2002 02:52
Picon

Re: Interaction between mode bits and acls

In my experience (with AFS), mode bits and ACLS operated independently; either could deny access to a given
object.  The thinking went something like this:

a) they are useful for different things.  ACLs are best for security/authorization, by virtue of their
flexibility in specifying authorized individuals and groups.  On the other hand, mode bits are useful for
protection against blunders, for example denying write access to backup copies, or execute access to
non-executable files.

b) even minor changes to the way mode bits work will break some applications, which have had 30 years to
discover peculiar ways to use them.  Translating back and forth is almost certain to introduce deviations
from the expected behavior.

c) it was relatively simple to state the combination rule.  Simplicity is almost always better.

AFS servers enforced ACL access.  I don't remember who enforced mode bits, but by this argument it might as
well be clients.

John Howard
Permalink | Reply | 0 comments |

Gmane