security and rmt protocols: tesla i-d simple-auth i-d rmt-sec i-d
DESCRIPTION
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 - PowerPoint PPT PresentationTRANSCRIPT
INRIA Rhône-Alpes - Planète research group 1
Security and RMT Protocols: TESLA I-D
simple-auth I-Drmt-sec I-D
IETF 69th – Chicago meeting, July 2007
Vincent Roca (INRIA)
INRIA Rhône-Alpes - V. Roca - 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
INRIA Rhône-Alpes - V. Roca - 3
Part 1:
TESLA for ALC and NORM
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
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…
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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)
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 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+2no key discl. no key discl.
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
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 ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
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
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 ☺
INRIA Rhône-Alpes - V. Roca - 15
Part 2:
Simple authentication schemes
for ALC and NORM
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
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 | ++ | -- | ++ | ++ |
+----------------+-------------+--------------+-------------+-------+
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
byt
es12
byt
es
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?
INRIA Rhône-Alpes - V. Roca - 20
Part 3:
Security and RMT protocols:
discussion and guidelines
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.