Jerome Etienne's IETF homepage

Jerome Etienne's IETF page:
rough consensus and running code !

My current interest is mainly the network security. I enjoy designing and breaking protocol's security. In a moment of madness, i wrote "designing security is playing chess alone, sure to outperform the opponent". The moment is no more but i still like the sentence. I contribute in:

Transport
IPsec
Routing area (currently OSPF and RIP)
Itrace

Transport:

Secure Path MTU discovery: framework (ROUGH DRAFT): This document presents a framework for a secure path MTU discovery which intend to improve the security compared to the current method. The rfc1191 method relies on unauthenticated packets sent by routers on the path. The lack of authentication allows an attacker to send fake packets and forces the host to instensively fragment all packets. It is an effective DoS because it significantly increases the packet loss, dramatically reduces the effective bandwidth and can be done from anywhere in the internet. The secure path mtu discovery requires a cookie exchange between the router and the host before accepting the suggested MTU. Thus, it limits the scope of this attack to the adversaries on the path. We think it is acceptable as attacker on the path can perform more efficient attacks. [txt] [html]

IPsec:

I specified the use of the counter mode in the context of ESP. I believe this mode of operation is largely overlooked. Among other advantages, it saves an average of 24 bytes per packet with AES and 12 bytes with DES/3DES compared to the standard CBC with explicit IV.

The counter mode and its use with ESP (ROUGH DRAFT): This memo presents the use of the counter mode in the context of ESP and specifies its application to DES, 3DES and AES. The counter mode significantly reduces the ESP space overhead compared to the standard CBC with explicit IV (Section 5.2.1). Moreover, it allows to parallelize and precompute most of the processing (Section 5.1). [txt] [html]

I specified a system of secret iv for ESP. It reduces the bandwidth usage and fixes a small security weakness in the current MUST for ESP (RFC2405.3). It offers a tradeoff which may be attractive: better bandwidth usage and better security versus slightly more CPU processing.

Secret IV and its use with ESP (ROUGH DRAFT): This memo presents a system of secret IV for ESP, based on the encryption of the sequence number. It doesn't add any space overhead in the packet and its generation can be parallelized and precomputed. Compared to the common explicit random IV (current MUST for ESP RFC2405.3 [5], or AES-CBC.3 [7]), it is more secure, saves bandwidth (e.g. 8 bytes with DES/3DES and 16 bytes with AES) but requires slightly more computation. [txt] [html]

OSPFv2/RIPv2: Security flaws and fixes

I have broken the security of OSPFv2 (4 years old) and RIPv2 (4.5 years old). Based on the same concepts, both are flawed in the same ways. I have designed a solution to fix them: the anti-replay authentication.

IETF-49 slides: I have been invited to IETF-49 to talk about it. [ps]
Flaws in packet's authentication of OSPFv2: OSPF is the Interior Gateway Protocol currently supported by the IETF and is widely deployed across the internet. The current strongest authentication method for OSPFv2 is the cryptographic authentication (RFC2328.D [4]) which uses shared secret key to authenticate the packets. This memo explains the different security flaws we found in the anti-replay and the MACs calculation. The second part presents practical exploitations of these weaknesses: an attacker directly connected to a link, can (i) replay LSAs, (ii) break neighborhood and (iii) flap routes. [txt] [html].
Flaws in RIPv2 packet's authentication: The current strongest authentication method for RIPv2 (RFC2453 [6]) is the MD5 authentication (RFC2082 [5]) which uses shared secret key to authenticate the packets. This memo explains its different security flaws we found in the anti-replay and the MACs calculation. The second part presents practical exploitations of these weaknesses: an attacker directly connected to a link, can (i) break neighborhood, (ii) flap routes and (iii) inject obsolete routes. [txt] [html].
Anti Replay Authentication (VERY ROUGH DRAFT): The anti-replay authentication is a new method which intends to solve the weaknesses we exposed. It offers a safer MAC function, an authentication of the IP header, a strict anti-replay across reset, and automatic re-keying. In this section, we describe the elements of the authentication field, the MAC calculation and the anti-replay mechanism. [txt]

RFC2154 security extension of OSPF: found insecure against insiders

OSPF with digital signature against an insider: This text comments the security offered by RFC2154[1] "OSPF with Digital Signatures" and shows it is insecure against insiders attacks. It is describes an experimental extension of OSPF to digitaly sign the LSAs. [txt] [html]

ITrace: