On Thu, 28 Feb 2013, Jeffrey Hutzelman wrote:
On Thu, 2013-02-28 at 17:05 -0500, Benjamin Kaduk wrote:
It's hard to get the logic right for when to terminate a GSS negotiation
loop
Yes; getting this right can be quite tricky. Someone should probably go
back and review the document to make sure we're correctly describing
what implementations should do and covering all the bases.
We're not; we knew this a while ago, but I haven't gotten around to
writing the new text yet.
Better yet, this logic is basically the same for all GSS-API
applications. Someone should write up an I-D describing the correct way
to handle both the initiator and acceptor sides of context
establishment, including what all the termination conditions are, and
get it published as an RFC. I wouldn't be surprised if such a thing
were well-received in the KITTEN WG.
Hmm, plausible. -00 submissions are cutoff at the moment, though.
Relatedly, there's not an obvious error code to return when such encoding
fails or we can't allocate memory for the new object. I've been using,
e.g., RXGEN_SS_MARSHAL for now, but I wonder if there are more RXGK error
codes waiting to be added, here. There's also some temptation to make
things like BADLEVEL apply to the authentication step as well as just
token negotiation; that would probably warrant changing the associated
error string.
There should be some generic rx-level error codes that are appropriate.
The rxgen-level codes are appropriate, I think, for handling data sent
and received as RPC arguments, but challenge/response ought not to
generate those, and they're probably also not appropriate for cases
where the encrypted part of a token doesn't decrypt successfully. So
yet, there may be room for another error or two here.
We have SEALED_INCON and BADCHALLENGE and BAD_TOKEN. I guess I
can make a list of some of the places that seem hard. It's tempting to
use ENOMEM in quite a few places, but that's not exactly a wire error
code...
The transport key is derived from the master key and a few pieces of
information that are sent from client to server in the clear; it therefore
seems that the utility of the transport key for avoiding key sharing
mostly comes into play when large quantities of data are being conveyed.
Also when the same token is used for multiple connections, no?
To some extent, sure.
Endianness conversion routines for 64-bit quantities (i.e., rxgkTime) do
not seem to be universally available; an incorrect hand-rolled
implementation could lead to interoperability issues.
True, but note that OpenAFS should have routines for this, and if AFS
XDR doesn't have a data type for this, we should add one.
There's an xdr_afs_int64 which is used by the rxgkTime en/decoder; I am
saying that it is a lot of overhead to invoke the XDR encoder when
preparing the seed for PRF+.
It's a bit awkward to include call number information in the authenticator
(read: feels like a layering violation), and it's not clear to me what
benefit is gained from doing so.
Integrity-protecting call number information is important because the
current call numbers are part of the connection state. Recall that
servers receiving a packet that is part of a connection they've never
seen before will "recover" the connection, copying some of that state
from the incoming packet. So, IIRC, protecting call numbers is
necessary to help defend against replays. It'll take me a bit to
reconstruct the reasoning here, but I'm pretty sure I did successfully
do so (for rxkad) back in the early stages of rxgk design.
I was wondering whether it gave some resistance to replay attacks, but had
not reasoned through it very far. Presumably the papers to which Simon
referred will help with that.
-Ben
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://lists.openafs.org/mailman/listinfo/afs3-standardization
