On Mon, Feb 11, 2008 at 07:01:07PM +1300, Peter Gutmann wrote: > Daniel Carosone <[EMAIL PROTECTED]> writes: > >[...] > >Particularly for the first point, early validation for packet integrity in > >general can be a useful defensive tool against unknown potential > >implementation vulnerabilities. > > This is an example of what psychologists call own-side bias ("everyone thinks > like us"), in this case the assumption that after a peer has authenticated > itself it'd never dream of sending a malformed packet and so we don't need to > do any checking after the handshake has completed. Why would you trust data > coming from a remote system just because they've jumped through a few hoops > before sending it? I can steal the remote system's credentials or hijack the > session and then send you anything I want, it's no safer to blindly accept the > data if there's a MAC attached or not.
Point taken, but I respectfully disagree with the relevance in the present context, though of course I agree entirely in the wider philosophical sense. Remember that we're also talking about practical deployment decisions: - if someone steals credentials, they can do all sorts of mischief and damage; the incremental risk in the present discussion is that doing 'lossy'/partial validation may allow additional injection and MITM attacks beyond those. - especially for the other cases I gave (SNMP and NTP), the alternative mitigating controls are such strong things as IP address based ACLs (on UDP packets). I'll take the stronger tool if it's on offer. The fact this kind of authentication is applied before the packet gets to more complex and potentially vulnerable parsing and processing code gives me a valuable opportunity to be defensive, especially as an end customer deploying some random vendor's kit. In those cases, I don't have visibility of the implementation, but I do have some assurance about the order of operations and can put that structural knowledge to good use. Much the same is true in this discussion about protocol design; we're making no specifications about processing of the data once the transport hands it off, but we're starting to make assumptions about the risks therein, and the reliance those layers may be placing on the transport, for better or worse. Your criticism would be fair if I was advocating blindly accepting the data or not doing any checking after the initial handshake. It would be fair criticism of a codec vendor who took such a stance, relying overly on transport authentication (or forcing me to). I am most certainly not advocating that, merely recognising that sometimes such checking may be deficient or vulnerable, or just simply uncertain. Good defensive protocol design lets me validate the blob before inspecting the fields; poor defensive programming conflates frame validation with more detailed syntactic and semantic validation later. If there are authentication-hijacking vulnerabilities in the endpoints (like your SIP gateway), sure, I'm screwed in a number of ways. That's sad, but a given regardless of whatever variant and detail of keying and MACing mechanism this discussion comes up with. > Hostile data inside a secure tunnel or wrapper is still hostile data. If cryptography can come up with some way to ensure robustness against hostile data all the way down an implementation stack, regardless of layering, we'll all be surprised. Some of us might even be very rich. Otherwise, it's a risk mitigation tool, subject to constraints we need to understand. If the constraints are ones of key management and endpoint security, I can use the mechanism in my toolkit. If the constrains mean that every fourth SNMP request or routing update will be unauthenticated, it's much less use to me as a structural security layer; the bar isn't raised in any practical sense. > As the OP said, as long as you can deterministically detect attacks > (which a 1-of-n packet MAC will do) you're not giving up much > security by not MAC'ing all packets. I attempted to illustrate, with some counterexamples, threat models where even one unauthenticated packet could lose you more than "not much" security. Threats where detection of the attack wasn't enough, or was too late, or was itself the point. Robust implementation behind that MAC is essential, and helps realise and provide assurance around "not much", as well as addressing broader threats that are more likely in the overall economic argument we acknowledged at the outset, but is outside what I saw as the OP's scope, and not part of the incremental risk I was highlighting. -- Dan.
Description: PGP signature