[AFS3-std] rxgk: The initial packet problem

[Simon Wilkinson]

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.