Received: from konishi-polis.mit.edu (HOTASS-5.MIT.EDU [18.101.1.47]) by krbdev.mit.edu (8.9.3) with ESMTP id AAA17977; Sun, 20 Apr 2003 00:59:08 -0400 (EDT)
Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id E555415226A; Sun, 20 Apr 2003 00:59:07 -0400 (EDT)
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
In-Reply-To: <rt-1415-5776.7.83886159285387@krbdev.mit.edu> (Tom Yu via's message of "Fri, 18 Apr 2003 20:04:06 -0400 (EDT)")
Message-Id: <tslr87x3gtg.fsf@konishi-polis.mit.edu>
User-Agent: Gnus/5.090017 (Oort Gnus v0.17) Emacs/21.2 (gnu/linux)
References: <rt-1415-5776.7.83886159285387@krbdev.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
RT-Send-Cc: 
X-RT-Original-Encoding: us-ascii
Content-Length: 581

>>>>> "Tom" == Tom Yu via RT <rt-comment@krbdev.mit.edu> writes:


    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.