1 / 21

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). Security and RMT Protocols: TESLA I-D simple-auth I-D rmt-sec I-D. Situation. TESLA source authentication for ALC/NORM draft-ietf-msec-tesla-for-alc-norm-02.txt updated Simple auth. schemes for ALC/NORM

jason
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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.

More Related