Security and RMT Protocols: TESLA I-D simple-auth I-D rmt-sec I-D

1. IETF 69th – Chicago meeting, July 2007 Vincent Roca (INRIA) Security and RMT Protocols: TESLA I-Dsimple-auth I-Drmt-sec I-D

2. Situation • TESLA source authentication for ALC/NORM draft-ietf-msec-tesla-for-alc-norm-02.txt updated • 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.txt updated

3. Part 1: TESLA for ALC and NORM

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. 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. 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. Authentication tag without key disclosure • example (using HMAC-SHA-1): • size divided by 2.25… with key disclosure (36 bytes) without key disclosure (16 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 | 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

8. no key discl. no key discl. 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 Ki-d again and again… • no robustness problem, since any key Kj can be used to compute all the previously disclosed keys, Kk, k<j time interval i (0.5s) time interval i+1 time interval i+2 Ki-d Ki-d+1 Ki-d+2

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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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. 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. sporadic traffic (eg. keepalive packets) busy period (high data rate) digital signature + group MAC for sender→recv TESLA for sender→recv group MAC for recv→sender 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:

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. 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. Part 2: Simple authentication schemes for ALC and NORM

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. 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. 128 bytes 12 bytes 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) . . . | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Digital Signature EXT_AUTH header extension using 1024 bit signatures 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Group MAC EXT_AUTH header extension using HMAC-SHA-1.

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. Part 3: Security and RMT protocols: discussion and guidelines

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.