Skip Menu |
 

Subject: subkeys fubar
subkeys are probably fubared. Detailed description will be added later,
once I have figured out which way is up.
To: rt-comment@krbdev.mit.edu
Subject: [krbdev.mit.edu #1415] subkey fubar description
From: Tom Yu <tlyu@mit.edu>
Date: Wed, 16 Apr 2003 19:40:54 -0400
RT-Send-Cc:
Download (untitled) / with headers
text/plain 1.3KiB
mk_safe, mk_priv key selection priority

1. local_subkey
2. remote_subkey
3. session key from ticket

rd_safe, rd_priv key selection priority

1. remote_subkey
2. local_subkey
3. session key from ticket

NOTE: (1) and (2) were reversed in krb5-1.0.x.

mk_req_ext -- generates local_subkey if requested, sends inside
AP-REQ msg.

rd_req_dec -- records subkey from authenticator as remote_subkey.
AP-REP is encrypted with the auth_context keyblock.

mk_rep -- subkey sent in AP-REP message is always the subkey from the
authenticator.

rd_rep -- subkey sent in AP-REP stored as remote_subkey.

krb-clarifications says that the AP-REP is always encrypted with the
ticket's session key.

The current state of affairs prevents server-side generation of subkey.

Even if server sends a subkey, the client won't encrypt using the
server subkey if there is a client-generated subkey. This prevents
the use of server-side subkey for replay prevention. Effectively,
this forces a choice of unidirectional subkeys if server-side subkey
generation is ever implemented. The layout of the auth_context
structure implies that there was at least at some point an effort to
implememnt unidirectional subkeys.

Do we want an option to allow for "server subkey wins"?

Are there any applications currently depending on the functionality of
unidirectional subsession keys?
[tlyu - Wed Apr 16 19:40:57 2003]:

Show quoted text
> Do we want an option to allow for "server subkey wins"?

RFC1510 and clarifications pretty much leave subkey negotiation to the
applications.
To stay true to this the APIs could allow an application-provided
callback function
to produce the local and remote sub-keys given the proposed sub-keys
from the
AP exchange as input.

Show quoted text
> Are there any applications currently depending on the functionality of
> unidirectional subsession keys?

Er, well, I suspect not, but if the default mkr_req/mk_rep behaviour
changes apps
would break, no? What about older kcmd? Is there a reflection attack
there if
unidirectional keys are not used?

Nico
To: rt-comment@krbdev.mit.edu
Cc: krb5-prs@mit.edu
Subject: Re: [krbdev.mit.edu #1415] subkey fubar description
From: Sam Hartman <hartmans@mit.edu>
Date: Thu, 17 Apr 2003 15:54:18 -0400
RT-Send-Cc:
I think that for 1.3 we want to change the code such that server
subkey wins by default as I don't think that will break anything if
the server subkey is the same as the client subkey. I'm not sure how
we get to a point where we generate server subkeys though.
To: rt-comment@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #1415] subkeys fubar
From: Tom Yu <tlyu@mit.edu>
Date: Thu, 17 Apr 2003 19:51:36 -0400
RT-Send-Cc:
Download (untitled) / with headers
text/plain 1.4KiB
Show quoted text
>>>>> "Nico" == Public Submitter via RT <rt-comment@krbdev.mit.edu> writes:

Show quoted text
Nico> [tlyu - Wed Apr 16 19:40:57 2003]:

Show quoted text
>> Are there any applications currently depending on the functionality of
>> unidirectional subsession keys?

Show quoted text
Nico> Er, well, I suspect not, but if the default mkr_req/mk_rep
Nico> behaviour changes apps would break, no? What about older kcmd?

Changing the default subkey negotiation doesn't break the
AP-REQ/AP-REP exchange, since those messages only contain ciphertext
encrypted using the ticket session key. They may break the state of
what applications are expecting in terms of local and remote subkeys,
though.

kcmd applications use the local subkey on the client side and the
remote subkey on the server side. This is just one key for
bidirectional use.

It seems that telnet does something similar to kcmd, but I haven't
traced the code thoroughly.

The GSS library also uses only one key -- the local subkey in the
initiator and the remote subkey in the acceptor.

To achieve "server subkey wins", we sould have to stomp on
local_subkey in the client and on remote_subkey in the server. This
might cause pointer aliasing nastiness, but is very probably
manageable, given that the structure involved is supposed to be
opaque.

Show quoted text
Nico> Is there a reflection attack there if unidirectional keys are
Nico> not used?

There is a reflection attack if you use a bidirectional subkey _if_
you don't utilize some other mechanism for identifying reflections,
e.g. directional "addresses".

---Tom
[tlyu - Thu Apr 17 19:51:38 2003]:
Show quoted text
> Changing the default subkey negotiation doesn't break the
> AP-REQ/AP-REP exchange, since those messages only contain ciphertext
> encrypted using the ticket session key. They may break the state of
> what applications are expecting in terms of local and remote subkeys,
> though.

Right. I think the existing behaviour has to remain the default.

Show quoted text
> To achieve "server subkey wins", we sould have to stomp on
> local_subkey in the client and on remote_subkey in the server. This
> might cause pointer aliasing nastiness, but is very probably
> manageable, given that the structure involved is supposed to be
> opaque.

Er, why can't server subkey wins (or any other variation) be a
per-auth-context
option that can be set by the application, with the current
ignore-the-server's-
offered-subkey behaviour as the default?

Nico
To: rt-comment@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #1415] subkeys fubar
From: Tom Yu <tlyu@mit.edu>
Date: Fri, 18 Apr 2003 20:04:03 -0400
RT-Send-Cc:
Download (untitled) / with headers
text/plain 1.8KiB
Show quoted text
>>>>> "Nico" == Public Submitter via RT <rt-comment@krbdev.mit.edu> writes:

Show quoted text
Nico> Er, why can't server subkey wins (or any other variation) be a
Nico> per-auth-context option that can be set by the application, with
Nico> the current ignore-the-server's- offered-subkey behaviour as the
Nico> default?

The current behavior isn't "ignore-the-server's-offered-subkey". The
current behavior is to accept the server's subkey and use it to
decrypt/verify the KRB-PRIV/KRB-SAFE messages from the server. If
clients running current code attempt to talk to a server where the
server actually generates a new subkey, the client won't use the
server-generated subkey to transmit messages to the server.

If we change client code to additionally smash the local subkey if it
receives a subkey from the server, then the semantic of "server subkey
wins" will be accomplished. This change to the client code won't
break against servers with the old behavior of merely sending back in
the AP-REP the client subkey as received in the AP-REQ.

The question does arise as to what the default behavior should be.
Changing the default client behavior to "server subkey wins" doesn't
change the behavior of any application code code currently in our
source tree, provided that the server implementation continues to send
the client subkey as its subkey. Clearly, changing the default
behavior of the server library will require changes in applications
that assume that the local and remote subkeys are identical. I think
that changing the server to actually generate a new subkey would
constitute a change in the application protocol.

I propose that we maintain the current default behavior in the server
library, but consider the possibility of altering the client library
code to default to "server subkey wins". Either behavior should
probably be modifiable by a flag in the auth_context.

---Tom
To: rt-comment@krbdev.mit.edu
Cc: krb5-prs@mit.edu
Subject: Re: [krbdev.mit.edu #1415] subkeys fubar
From: Sam Hartman <hartmans@mit.edu>
Date: Sun, 20 Apr 2003 00:59:07 -0400
RT-Send-Cc:
Show quoted text
>>>>> "Tom" == Tom Yu via RT <rt-comment@krbdev.mit.edu> writes:


Show quoted text
Tom> If we change client code to additionally smash the local
Tom> subkey if it receives a subkey from the server, then the
Tom> semantic of "server subkey wins" will be accomplished. This
Tom> change to the client code won't break against servers with
Tom> the old behavior of merely sending back in the AP-REP the
Tom> client subkey as received in the AP-REQ.

I think this is probably wrong to do though. I think this discussion
is best handled in person than through the bug system.
To: rt-comment@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #1415] subkey fubar description
From: Tom Yu <tlyu@mit.edu>
Date: Fri, 25 Apr 2003 18:38:02 -0400
RT-Send-Cc:
Download (untitled) / with headers
text/plain 1.2KiB
First, clarification on my message of 20030416 -- (1) and (2) are
swapped in 1.0.x only for rd_safe/rd_priv, not mk_safe/mk_priv.

Conclusions from discussion yesterday with Sam and Ken:

There will be three subkeys stored in the auth_context: "subkey",
"send_subkey", and "recv_subkey" (or similarly named things).

"send_subkey" will be what "local_subkey" is now, and "recv_subkey"
will be what "remote_subkey" is now, except that they won't be set
anymore. New APIs may be written to allow the application to set
"send_subkey" and "recv_subkey".

On the client side, mk_req and rd_rep will set "subkey" only.
mk_safe/mk_priv will prefer "send_subkey", followed by "subkey".
rd_safe/rd_priv will prefer "recv_subkey", followed by "subkey".

In the future, new APIs will allow a client application to extract the
different subkeys by querying the subkey either after mk_req or after
rd_rep. mk_req will set "subkey" if requested, and send it in the
AP-REQ message. rd_rep will read the subkey from the AP-REP message,
and store it in "subkey", possibly overwriting one stored there by
mk_req.

On the server side, rd_req will set "subkey", and mk_rep may
eventually allow an application to set a new "subkey", which will also
be transmitted by mk_rep.
To: rt-comment@krbdev.mit.edu
Cc: krb5-prs@mit.edu
Subject: Re: [krbdev.mit.edu #1415] subkey fubar description
From: Sam Hartman <hartmans@mit.edu>
Date: Fri, 25 Apr 2003 19:51:32 -0400
RT-Send-Cc:
I thought you convinced Ken and I that you only needed two subkeys and
that all four functions would set both subkeys.
To: rt-comment@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #1415] subkey fubar description
From: Tom Yu <tlyu@mit.edu>
Date: Fri, 25 Apr 2003 20:51:43 -0400
RT-Send-Cc:
Show quoted text
>>>>> "Sam" == Sam Hartman via RT <rt-comment@krbdev.mit.edu> writes:

Show quoted text
Sam> I thought you convinced Ken and I that you only needed two
Sam> subkeys and that all four functions would set both subkeys.

Hm. Yeah, I could be misremembering. Having all four functions set
both subkeys would work. The getlocalsubkey and getremotesubkey
functions won't need changing in that case, though the
{mk,rd}_{priv,safe} functions still probably want to have their key
preferences changed somewhat.
From: tlyu@mit.edu
Subject: CVS Commit
Download (untitled) / with headers
text/plain 2.2KiB
Rename the local_subkey and remote_subkey fields in the auth_context
to send_subkey and recv_subkey, respectively. Add new APIs to query
and set these fields. Change the behavior of mk_req_ext, rd_req_dec,
and rd_rep to set both subkeys. Applications wanting to set
unidirectional subkeys may still do so by saving the values of subkeys
and doing overrides. Cause mk_cred, mk_priv, and mk_safe to never use
the recv_subkey. Cause rd_cred, rd_priv, and rd_safe to never use the
send_subkey.


To generate a diff of this commit:



cvs diff -r5.377 -r5.378 krb5/src/appl/bsd/ChangeLog
cvs diff -r5.71 -r5.72 krb5/src/appl/bsd/krcp.c
cvs diff -r5.78 -r5.79 krb5/src/appl/bsd/krlogin.c
cvs diff -r5.119 -r5.120 krb5/src/appl/bsd/krlogind.c
cvs diff -r5.43 -r5.44 krb5/src/appl/bsd/krsh.c
cvs diff -r5.99 -r5.100 krb5/src/appl/bsd/krshd.c
cvs diff -r5.97 -r5.98 krb5/src/appl/telnet/libtelnet/ChangeLog
cvs diff -r5.60 -r5.61 krb5/src/appl/telnet/libtelnet/kerberos5.c
cvs diff -r1.356 -r1.357 krb5/src/include/ChangeLog
cvs diff -r1.155 -r1.156 krb5/src/include/krb5.hin
cvs diff -r5.256 -r5.257 krb5/src/kdc/ChangeLog
cvs diff -r5.107 -r5.108 krb5/src/kdc/kdc_util.c
cvs diff -r1.120 -r1.121 krb5/src/lib/ChangeLog
cvs diff -r1.33 -r1.34 krb5/src/lib/krb5_32.def
cvs diff -r1.219 -r1.220 krb5/src/lib/gssapi/krb5/ChangeLog
cvs diff -r1.78 -r1.79
krb5/src/lib/gssapi/krb5/accept_sec_context.c
cvs diff -r1.67 -r1.68 krb5/src/lib/gssapi/krb5/init_sec_context.c
cvs diff -r5.388 -r5.389 krb5/src/lib/krb5/krb/ChangeLog
cvs diff -r5.23 -r5.24 krb5/src/lib/krb5/krb/auth_con.c
cvs diff -r5.7 -r5.8 krb5/src/lib/krb5/krb/auth_con.h
cvs diff -r5.8 -r5.9 krb5/src/lib/krb5/krb/chpw.c
cvs diff -r5.30 -r5.31 krb5/src/lib/krb5/krb/mk_cred.c
cvs diff -r5.47 -r5.48 krb5/src/lib/krb5/krb/mk_priv.c
cvs diff -r5.73 -r5.74 krb5/src/lib/krb5/krb/mk_req_ext.c
cvs diff -r5.44 -r5.45 krb5/src/lib/krb5/krb/mk_safe.c
cvs diff -r5.41 -r5.42 krb5/src/lib/krb5/krb/rd_cred.c
cvs diff -r5.55 -r5.56 krb5/src/lib/krb5/krb/rd_priv.c
cvs diff -r5.33 -r5.34 krb5/src/lib/krb5/krb/rd_rep.c
cvs diff -r5.70 -r5.71 krb5/src/lib/krb5/krb/rd_req_dec.c
cvs diff -r5.52 -r5.53 krb5/src/lib/krb5/krb/rd_safe.c
cvs diff -r5.13 -r5.14 krb5/src/lib/krb5/krb/ser_actx.c
cvs diff -r1.4 -r1.5 krb5/src/mac/MacOSX/Projects/Kerberos5.pbexp
From: tlyu@mit.edu
Subject: CVS Commit
* krb5.tex: Update subkey-related information to match code.


To generate a diff of this commit:



cvs diff -r5.26 -r5.27 krb5/doc/api/ChangeLog
cvs diff -r5.36 -r5.37 krb5/doc/api/krb5.tex
From: tlyu@mit.edu
Subject: CVS Commit
Download (untitled) / with headers
text/plain 2.1KiB
pullup from trunk


To generate a diff of this commit:



cvs diff -r5.26 -r5.26.2.1 krb5/doc/api/ChangeLog
cvs diff -r5.36 -r5.36.2.1 krb5/doc/api/krb5.tex
cvs diff -r5.375.2.1 -r5.375.2.2 krb5/src/appl/bsd/ChangeLog
cvs diff -r5.71 -r5.71.2.1 krb5/src/appl/bsd/krcp.c
cvs diff -r5.78 -r5.78.2.1 krb5/src/appl/bsd/krlogin.c
cvs diff -r5.119 -r5.119.2.1 krb5/src/appl/bsd/krlogind.c
cvs diff -r5.43 -r5.43.2.1 krb5/src/appl/bsd/krsh.c
cvs diff -r5.98.2.1 -r5.98.2.2 krb5/src/appl/bsd/krshd.c
cvs diff -r5.94.2.3 -r5.94.2.4
krb5/src/appl/telnet/libtelnet/ChangeLog
cvs diff -r5.58.2.2 -r5.58.2.3
krb5/src/appl/telnet/libtelnet/kerberos5.c
cvs diff -r1.348.2.4 -r1.348.2.5 krb5/src/include/ChangeLog
cvs diff -r1.154.2.1 -r1.154.2.2 krb5/src/include/krb5.hin
cvs diff -r5.251.2.4 -r5.251.2.5 krb5/src/kdc/ChangeLog
cvs diff -r5.106.2.1 -r5.106.2.2 krb5/src/kdc/kdc_util.c
cvs diff -r1.119.2.1 -r1.119.2.2 krb5/src/lib/ChangeLog
cvs diff -r1.32.2.1 -r1.32.2.2 krb5/src/lib/krb5_32.def
cvs diff -r1.218.2.1 -r1.218.2.2 krb5/src/lib/gssapi/krb5/ChangeLog
cvs diff -r1.77.2.1 -r1.77.2.2
krb5/src/lib/gssapi/krb5/accept_sec_context.c
cvs diff -r1.66.2.1 -r1.66.2.2
krb5/src/lib/gssapi/krb5/init_sec_context.c
cvs diff -r5.378.2.4 -r5.378.2.5 krb5/src/lib/krb5/krb/ChangeLog
cvs diff -r5.23 -r5.23.2.1 krb5/src/lib/krb5/krb/auth_con.c
cvs diff -r5.7 -r5.7.2.1 krb5/src/lib/krb5/krb/auth_con.h
cvs diff -r5.6.2.1 -r5.6.2.2 krb5/src/lib/krb5/krb/chpw.c
cvs diff -r5.30 -r5.30.2.1 krb5/src/lib/krb5/krb/mk_cred.c
cvs diff -r5.47 -r5.47.2.1 krb5/src/lib/krb5/krb/mk_priv.c
cvs diff -r5.73 -r5.73.2.1 krb5/src/lib/krb5/krb/mk_req_ext.c
cvs diff -r5.44 -r5.44.2.1 krb5/src/lib/krb5/krb/mk_safe.c
cvs diff -r5.41 -r5.41.2.1 krb5/src/lib/krb5/krb/rd_cred.c
cvs diff -r5.55 -r5.55.2.1 krb5/src/lib/krb5/krb/rd_priv.c
cvs diff -r5.33 -r5.33.2.1 krb5/src/lib/krb5/krb/rd_rep.c
cvs diff -r5.70 -r5.70.2.1 krb5/src/lib/krb5/krb/rd_req_dec.c
cvs diff -r5.52 -r5.52.2.1 krb5/src/lib/krb5/krb/rd_safe.c
cvs diff -r5.13 -r5.13.2.1 krb5/src/lib/krb5/krb/ser_actx.c
cvs diff -r1.3.2.1 -r1.3.2.2
krb5/src/mac/MacOSX/Projects/Kerberos5.pbexp