1. INRIA Rhône-Alpes - Planète research group 1 Security and RMT Protocols: TESLA I-D simple-auth I-D rmt-sec I-D IETF 69 th – Chicago meeting, July 2007 Vincent Roca (INRIA)

2. INRIA Rhône-Alpes - V. Roca - 2 Situation TESLA source authentication for ALC/NORM draft-ietf-msec-tesla-for-alc-norm-02.txtupdated Simple auth. schemes for ALC/NORM draft-roca-rmt-simple-auth-for-alc-norm-00.txt new Security and RMT protocols: discussions and guidelines draft-ietf-rmt-sec-discussion-00.txtupdated

3. INRIA Rhône-Alpes - V. Roca - 3 Part 1: TESLA for ALC and NORM

4. INRIA Rhône-Alpes - V. Roca - 4 What’s new in version 02? … many, many things… new features:  authentication tags: compact versions, tag without key disclosure  optional weak group MAC filled in TBD parts:  NORM pkt types specified for some TESLA messages

5. INRIA Rhône-Alpes - V. Roca - 5 What’s new in version 02… (cont’) clarifications, additions:  bootstrap messages: when to use them, format  receiver operations: updated list of actions  EXT_AUTH: format, clarified the use of the ASID  added a security section  IANA section: updated let’s focus on some of these points…

6. INRIA Rhône-Alpes - V. Roca - 6 Compact authentication tag remove the “i” interval id field  instead we only send the lowest byte in “i_LSB” field …plus two additional bytes (“i_NSB” field) when the MAC field needs padding (e.g. with HMAC-SHA-1)  saves 32 bits/packet maybe it’s safe to define only compact auth. tags? 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HET (=1) | HEL (=9) | ASID | 5 | i_LSB | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + | + Disclosed Key K_{i-d} + | (20 bytes) | + | + | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + MAC(K'_i, M) + | (10 bytes) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | i_NSB | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

7. INRIA Rhône-Alpes - V. Roca - 7 Authentication tag without key disclosure example (using HMAC-SHA-1):  size divided by 2.25… 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HET (=1) | HEL (=4) | ASID | 6 | i_LSB | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + MAC(K'_i, M) + | (10 bytes) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | i_NSB | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HET (=1) | HEL (=9) | ASID | 5 | i_LSB | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + | + Disclosed Key K_{i-d} + | (20 bytes) | + | + | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + MAC(K'_i, M) + | (10 bytes) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | i_NSB | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ with key disclosure (36 bytes) without key disclosure (16 bytes)

8. INRIA Rhône-Alpes - V. Roca - 8 Auth. tag without key disclosure… (cont’) when can we use them?  when a high number of packets are generated per time interval (i.e. high data rate) since it’s not required to disclose the same K i-d again and again… no robustness problem, since any key K j can be used to compute all the previously disclosed keys, K k, k<j time interval i (0.5s)time interval i+1time interval i+2 K i-d K i-d+1 K i-d+2 no key discl.

9. INRIA Rhône-Alpes - V. Roca - 9 Weak group MAC motivations  add a short (32bit) group MAC to all packets, calculated with a group key, to mitigate attacks coming from outside of the group 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HET (=1) | HEL (=5) | ASID | 6 | i_LSB | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + MAC(K'_i, M) + | (10 bytes) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | i_NSB | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Weak Group MAC (4 bytes) | | Weak Group MAC (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

10. INRIA Rhône-Alpes - V. Roca - 10 Weak group MAC… (cont’) benefits (the attacker is not a group member)  receivers immediately drop packets that fail the Weak Group MAC check  avoid costly digital signature computations in case of faked “bootstrap”/”direct sync req”/”response” packets limitations  no benefit if the attacker knows the group key  the EXT_AUTH size is increased (32bits)  more computation overhead  we recommend to check the group MAC only when an attack is detected

11. INRIA Rhône-Alpes - V. Roca - 11 Use of the ASID field Authentication Scheme ID  a 4 bit field common to all EXT_AUTH header ext. TESLA, group MAC, and digital signatures  session description (e.g. SDP) defines the mapping ASID value↔authentication scheme 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HET (=1) | HEL | ASID | Type | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ~ Content ~ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

12. INRIA Rhône-Alpes - V. Roca - 12 Use of the ASID… (cont’)  benefits  no IANA registration needed, mapping is per-session  several schemes can be used jointly works also if several AS are used for the same direction  several AS can be used jointly (e.g. DS + group MAC)  for instance: busy period (high data rate) sporadic traffic (eg. keepalive packets) digital signature + group MAC for sender→recv TESLA for sender→recv group MAC for recv → sender

13. INRIA Rhône-Alpes - V. Roca - 13 Use of the ASID… (cont’) questions to the group  does it make sense?  IMHO (1) it’s better than using the LCT codepoint field and (2) it also works with NORM  4 bits for the ASID is clearly too much, 2 or 3 bits are enough

14. INRIA Rhône-Alpes - V. Roca - 14 To conclude with TESLA for ALC/NORM we are aligned with the existing TESLA RFC  e.g. RFC4082 (intro), RFC4383 (TESLA in SRTP), RFC4442 (bootstrapping TESLA)  …but we define additional mechanisms (e.g. several key chains, auth tags w/o key disclosure, group MAC) work almost finished  our plan is to finish the specifications for IETF70 in parallel we are implementing it from scratch  we take advantage of it to check our specifications…  but another pair of eyes is welcome ☺

15. INRIA Rhône-Alpes - V. Roca - 15 Part 2: Simple authentication schemes for ALC and NORM

16. INRIA Rhône-Alpes - V. Roca - 16 Simple auth schemes for ALC/NORM a new I-D…  …that defines two basic authentication schemes for group communications  shares the EXT_AUTH format  ASID field is used goal is to have an appropriate set of authentication schemes  for ALC/NORM level security  it’s complementary to IPsec level security

17. INRIA Rhône-Alpes - V. Roca - 17 Simple auth schemes for ALC/NORM… (cont’) pros/cons in short +----------------+-------------+--------------+-------------+-------+ | | RSA Digital | ECC Digital | Group MAC | TESLA | | | Signature | Signature | | | +----------------+-------------+--------------+-------------+-------+ | True auth and | Yes | Yes | No (group | Yes | | integrity | | | security) | | | Immediate auth | Yes | Yes | Yes | No | | Processing | -- | + | ++ | + | | load | | | | | | Transmission | -- | + | ++ | + | | overhead | | | | | | Complexity | ++ | ++ | ++ | -- | | IPR/patents | ++ | -- | ++ | ++ | +----------------+-------------+--------------+-------------+-------+

18. INRIA Rhône-Alpes - V. Roca - 18 Simple auth schemes for ALC/NORM… (cont’) example: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HET (=1) | HEL (=33) | ASID | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + |.. Signature (128 bytes).. | + | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HET (=1) | HEL (=4) | ASID | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + | Group MAC (10 bytes) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Digital Signature EXT_AUTH header extension using 1024 bit signatures Group MAC EXT_AUTH header extension using HMAC-SHA-1. 128 bytes 12 bytes

19. INRIA Rhône-Alpes - V. Roca - 19 To conclude with simple auth schemes it’s the logical follow-up to TESLA I-D  provides a comprehensive set of techniques for the most basic security feature: source authentication and packet integrity a WG Item?  RMT or MSEC?

20. INRIA Rhône-Alpes - V. Roca - 20 Part 3: Security and RMT protocols: discussion and guidelines

21. INRIA Rhône-Alpes - V. Roca - 21 What’s new in version 00? now a WG Item doc  as decided during IETF67 updated the “technological building block” section  takes into account the “simple authentication schemes” I-D but it’s not finished…  lacks some text on keying protocols, need to update the IPsec section, etc.