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:
- Routing area (currently OSPF and RIP)
- 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.
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.
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.
- 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).
- 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 , or AES-CBC.3 ), it is more secure, saves bandwidth
(e.g. 8 bytes with DES/3DES and 16 bytes with AES) but requires
slightly more computation.
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.
- 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 ) 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.
- Flaws in RIPv2 packet's authentication:
The current strongest authentication method for RIPv2 (RFC2453 )
is the MD5 authentication (RFC2082 ) 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.
- 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
RFC2154 security extension of OSPF: found insecure against insiders
- OSPF with digital signature against an insider:
This text comments the security offered by RFC2154 "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.
- IETF-49 slides:
I talked about it at IETF-49. It is mainly about authentication
and backward itrace.