Subject: [MSEC] MSEC Review of 802.16eD7 specification

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 09 Sep 2005 17:00:47 -0700

Hi all,

Attached is the draft text that I plan to submit to the 802.16e group as
the response to their request for MSEC review of the version 7 of the
802.16e draft specification.  The review is a summary of all the
reviews that were received just before the Paris meeting.  I would
like to take the opportunity to thank the reviewers for their time.
Please feel free to suggest any revisions to the review text.
(Note: I am explicitly noting that this review does NOT reflect MSEC WG
consensus).

Jeff,

Please let us know if we can clarify anything.  Also, please feel
free to use any text from the review towards contributions to the 16e
group.  Once Ran and you give the go ahead, I will submit the
review as the official MSEC response to the review request.

thanks and regards,

Lakshminath

                                                   September 09, 2005

Roger B. Marks, Chair, IEEE 802.16 

cc:
Jeff Mandin, IEEE 802.16 Liaison to IETF
Brian Kiernan, Chair, IEEE 802.16 Task Group e
Ran Canetti, co-chair, IETF MSEC Working Group
Bernard Aboba, IETF Liaison to IEEE 802
Russ Housley, Security Area Director, IETF
Sam Hartman, Security Area Director, IETF
MSEC WG, [email-masked]

Subject: MSEC Working Group review of the 802.16eD7 specification
(MBS and Multicast security mechanisms)

Editor:

Lakshminath Dondeti

Reviewers:

Ran Canetti
Lakshminath Dondeti
Dragan Ignjatic
Men Long
QinKe
Brian Weis

Review process:

The MSEC chairs sent an open request to the MSEC mailing list to
review the 802.16eD7 specification.  The chairs also personally
recruited MSEC contributors (authors and editors) to review the
specification.  IETF participation is on an individual basis and to
the best of the Editor's knowledge the comments are individuals'
opinions.  The 802.16 liaison has been copied on the full reviews.

Note: This review is based on voluntary contributions and does not
reflect the consensus of the MSEC WG.

Summary:  

The MBS and Multicast security portions of the 802.16eD7 specification
are in a good shape.  The reviewers identified group rekeying, group
authentication, counter mode usage, and notes on security properties
as areas of potential improvement.  In most cases, the reviews request
clarification, but in a few instances, suggest improvements to the
specification.

Review:

The following topics have been identified by the MSEC reviewers as
areas of concern.

1.0 One-to-many authentication:

>From section 7.8.3: The current specification does not seem to cover
one-to-many authentication for the transmitted contents. This is in
contrast to the unicast case where the contents is authenticated. I
can see the rationale for this decision (since one-to-many
authentication is indeed more complext than unicast authentication);
but it might be a good idea to say it explicitly in the
document. (otherwise, implementors and users might get a "false
feeling of security".)

2.0 Group rekeying:

Another issue that seems to be left uncovered is dealing with key
management for dynamically changing groups. Again, I can understand this
decision on basis of efficiency (although some not-that-complex solutions
do exist). But I would recommend saying so explicitly and providing some
rationale.

2.1 In the current specification, Group key update messages are
integrity protected with a group key.  The specification correctly
notes that using a group key for intergrity protection of data allows
any member of the group to impersonate the BS.  With group
authentication of group key update messages, the attacker can modify
the GTEK or GKEK itself to efficiently carry out the impersonation
attack.

In MSEC protocols, rekey messages are signed by the sender. That
allows security encapsulated data packets to be either group
authenticated (with the threat of impersonation) or source
authenticated (using the TESLA protocol -- which has low overhead, but
requires loose time synchronization).  Perhaps the 802.16e
specification might consider signing group key update messages (in
frequent, so should not be too much of a performance burden).

3.0 Cipher mode usage:

Section 7.8.4.1 Data encryption with AES in CTR mode

Using a counter mode algorithm to protect a GTEK is only safe if the
multicast or broadcast traffic originates with one sender (e.g., the
BS). This is due to the (already stated) issue that a counter can only
be used once per key. However, since the document does not describe
any means of avoiding multiple senders to use the counter space (e.g.,
by allocating each sender a subset of the counter space), the single
sender rule must apply. 

Note that even if the GTEK only authorizes one sender to use the key,
the GTEK is a shared key. There is still a risk of an unauthorized BS
sending packets encrypted with the counter mode GTEK key (either
unintentionally, or in collusion with an eavesdropper). 

In summary, CTR mode isn't a very good mode to use with GTEKs. 

4.0 Notes on security considerations:

MBS security encapsulation does not include integrity protection.
Encryption without integrity protection might undermine
confidentiality property itself.  Thus, while group keys only provide
group authentication of data, it is still beneficial to use it.  We
understand that the design decision was made to reduce per-packet
overhead and with the consideration that the data sent via MBS might
not need "strong" protection.  We suggest to add a note in the MBS
section along these lines to indicate potential threats even after the
MBS security encapsulation.

We also note that there is not sufficient detail in the 802.16e
specification about the protections provided or not provided 
by the protocols employed.  For example, lack of integrity protection
in MBS PDUs might be pointed out so the users and implementers are
aware of the implications.

5.0 Additional comments

Section 7.2.2.3.3: Please explain the role of a MGTEK if a MAK is 
already present.

Section 7.2.2.4.2 Last sentence - How does the receiver know whether
GKEK or KEK is used to encrypt?  Please clarify. 

Section 7.2.2.3.2: Please fill in all the contents of a GSA: 
GTEK & GKEK (two sets, grace time)?

_______________________________________________
msec mailing list
[email-masked]
http://six.pairlist.net/mailman/listinfo/msec