This is the first of a couple of emails to raise issues that were
identified and discussed with rxgk at the Edinburgh Hackathon. I am,
of course, going to produce a revised document which addresses them,
but I'm sending this separately in the hope of getting further
feedback before that document appears.
The initial packet problem is caused by the current behaviour of rx's
challenge/response system, where the client sends a packet to the
server using its desired security level. The server then responds with
a challenge, the client sends a response, and providing the security
level permitted by the server matches that requested by the client,
the connection is established. The issue here is if the client is
trying to do clear but the server requires encryption - the client has
already sent a cleartext data packet before the server tells it isn't
permitted to. For RPCs such as StoreData, this can obviously result in
undesired information disclosure.
The proposal at the meeting was that rxgk should have a 'security
header', which it prefixes to its payload (whether that payload be a
cleartext copy, an encrypted block, or a MIC followed by cleartext).
This header would contain a field indicating the security level of the
packet, allowing the server to know what security level incoming
packets have.
A client which has not been challenged by a server would then be
required to always transmit its packets encrypted until the challenge
is complete. The server must always accept encrypted packets, even if
the connection's negotiated security level is lower.
Comments?
Simon.
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
