MSEC Working Group
Ran Canetti
<canetti@watson.ibm.com>
Lakshminath Dondeti
<ldondeti@qualcomm.com>
Russell Housley
<housley@vigilsec.com>
Sam Hartman
<hartmans-ietf@mit.edu>
Charter:
http://www.ietf.org/html.charters/msec-charter.html
Supplemental:
http://www.securemulticast.org/msec-meetings.htm
02.08.2005, 18.15
Minute takers: Steffen Fries (steffen.fries@siemens.com)
Lakshminath Dondeti (ldondeti@qualcomm.com)
Please send comments and/or corrections to msec@securemulticast.org
AGENDA:
*
Blue sheets, Agenda Bashing etc.,
2 mins
*
MSEC status report
(Ran/Lakshminath)
10 mins
Revised milestones
Notes on cross-area work and
reviews
-
Agenda
-
Two
liaison activities
-
Increasing
number of drafts in MIKEY – need to work on umbrella
document
-
TESLA
is a topic to be discussed
-
IPsec
extensions
-
Published
2 RFC
o
RFC4046
o
RFC4082
-
IESG
o
draft-ietf-msec-bootstrapping-tesla
-01 2005-05-24
§
AD
Evaluation::Revised ID Needed
o
draft-ietf-msec-newtype-keyid
-01 2005-02-14
§
Waiting
for AD Go-Ahead
§
Waiting
for 3GPP SA3 coordination
§
Incremental
additions, add on document to RFC3830
§
Finished
IESG last call?
o
draft-ietf-msec-srtp-tesla
-03 2005-02-14
§
Waiting
for AD Go-Ahead::Revised ID Needed
-
RFC
Editors queue
o
draft-ietf-msec-gsakmp-sec
-10 2005-05-17
o
draft-ietf-msec-ipsec-signatures
-06 2005-06-22
o
draft-ietf-msec-mikey-dhhmac
-
Work
in Progress
o
draft-ietf-msec-ipsec-extensions
-00 2005-07-25
o
draft-ietf-msec-mikey-ecc
-00 2005-07-07
o
draft-ietf-msec-mikey-rsa-r
-00 2005-07-08
o
draft-ietf-msec-policy-token-sec
-03 2005-07-08
-
Milestones:
o
See
slides
o
Nov
05 WG Last Call on "MIKEY-RSA-R"
o
Dec
05 WG Last Call on "MIKEY-ECC"
-
If
more time is needed for review time let chairs know
-
Liaison
statements:
o
802.16e
review request
§
wanted
it before their July meeting, but were not able to use it
directly
§
Several
folks volunteered and most returned reviews
§
Comments
pending from a few
§
Outstanding
requests for the draft spec from a few
§
What
next?
·
The
plan was to compile all the comments and submit to 802.16 as a
contribution
o
-
*
draft-ietf-msec-bootstrapping-tesla
(Steffen)
5 mins
-
Made
changes after LC and chair review
-
received
comments from AD
-
will
provide revised ID
*
draft-ietf-msec-newtype-keyid
(Ran/Lakshminath)
5 mins
-
This
was a 3GPP-related contribution.
After the I-D finished last call, the authors realized that a few
additional extensions need to be added.
-
Russ
will place the document in hold, pending a revised
submission.
-
MSEC
will run a last call after the updated I-D has been
submitted
-
An
IETF last call will also be needed
*
draft-ietf-msec-srtp-tesla
(Ran/Lakshminath)
5 mins
-
(Mark
provides a summary of the IETF last call reviews on the SRTP-TESLA
I-D)
*
draft-ietf-msec-ipsec-extensions (Dragan)
10 mins
-
enumerate
point necessary to discuss in IPSec
-
RFC2401-bis
IP Security profile
o
Concurrent
coexistence with IKEv2
-
Security
Association modes
o
Transport
o
Tunnel,
must be supported by GW
-
Routing
o
Address
preservation
§
Destination
address should be maintained
§
New
flag introduced to copy the remote address
-
SPD
changes
o
Directional
attribute added (common, send only, receive only)
o
Should
support multicast destination address
-
Traffic
Processing
o
Inbound
traffic
o
Outbound
-
SAD
o
Replay
protection is needed : TBD
o
Chair
things it should (RFC2401 talks about it)
-
PAD
o
Needs
to be extended for peers with specific roles (GCKS, group speaker, member, root
certs)
-
NATs
o
SSM
adversely impacted by it
-
Discussion
o
Review
ASAP needed to define scope on this, what topics should be covered, what
not
o
Russ
notes 2401bis says multi-sender replay protection can’t be
done
o
Sandy
M. (
§
Suggests
that multisender replay protection is a topic of interest that MSEC should
pursue
§
Lakshminath
and Brian had some idea exchange regarding this point, will be
documented
o
Ran
C.: Multi-sender replay-protection may need an own draft
§
We’ll
take that discussion to the list.
o
Haitham
C.: GSAKMP has notes on multi-sender replay protection about this and says that
having a separate GSA for each sender would work
*
draft-ietf-msec-mikey-ecc
(Lakshminath/Andy)
10 mins
-
Revised,
some more work to do
-
MIKEY-ECIES
½ RT
-
MIKEY-DHSIGN
with EC : Steffen will look for more comments if necessary, text may be merged
with draft text
-
Outstanding
issue
o
ECIES
doesn’t use envelop keys
-
Need
IPR statements, if any, before forwarding I-D to the AD
-
Planned
last call in Dec 2005
o
Let
the chairs know if anyone needs more time to review etc.
*
draft-ietf-msec-mikey-rsa-r
(Dragan)
10 mins
-
status
update
-
turned
to WG item (mailing list)
-
Ran
notes: In the use cases mentioned, the sender is also the
GCKS
-
added
better support for multicast case (includes GenExtSBID)
payload
-
WGLC
some time in November 2005
o
Please
review ASAP
-
Discussion
o
Responder
chooses the key, not the sender
o
Approach
regarding multicast similar to the GCKS model
-
Changes
o
Dos
prevention caps spelled out in Security considerations
o
GenExt
included (see above)
o
If
initiator does not include policy, responder MUST
-
Open
Issue
o
Multiple
media line support within ta session level MIKEY (in the SDP
body)
§
Single
TGK, multiple media streams
§
Absolute
position of a stream in SRTP-ID map affects key derivation
§
Different
initiators offer different number of streams the responder needs to be able to
correctly map the keys to streams
§
May
need review from MMUSIC WG
*
draft-dondeti-msec-inband-key-updates (Lakshminath) 10
mins
-
send
key updates along with data encapsulation protocols
-
send
a rekey message via data packets
-
Motivation
o
GSA
updates may be lost in transmission
o
Current
approach is sending it multiple times
o
3GPP2
BCMCS specification already uses MKI field, but MKI field is not integrity
protected
-
optional
MKI field in the SRTP packet payload which is protected by the SRTP auth.
Field
-
Strawman
proposal for the WG’s consideration
-
May
be interesting for this WG, influences also other protocols (IPsec and
SRTP)
-
:
please send comments to the list
*
draft-faurite-rmt-tesla-for-alc-norm
"RMT proposal for 10
mins
MSEC review"
-
submitted
to the RMT WG
-
part
of discussion on RMT and MSEC mailing list was related to the home of this
draft
-
goal
TESLA being used for ALS/NORM/FLUTE (feedback of
receivers)
-
lot
of good TESLA work in MSEC
o
(draft-ietf-msec-tesla-spec-00
is not that dead, it will come back)
o
Bob
Briscoe: A number of changes have been made to the TESLA Informational RFC
4082
§
Be
sure to update the ESP-TESLA spec accordingly when it is
revived
-
several
features are missing in this document
o
only
MIKEY based bootstrapping is considered
§
but
ALC can use in-band signaling (NO NEED FOR EXTRA PROTOCOL)
-
INDIRECT
SYNCHRONIZATION IS MENTIONED BUT NOT DETAILED : ALC sessions have no back
channel : problem for sync
-
Key
chain switching is not addressed (ALCs may have very long sessions) :
specification needed how this can be done reliabily
-
Information
payload formats are missing
o
No
bootstrapping information formation in bootstrapping-tesla
ID
-
Requires
an initial bootstrap information message
o
Sent
in a dedicated ALC/NORM control packet containing only a bootstrap info header
extension
o
Only
sent at the beginning of a session
-
Indirect
time synchronization
o
Added
suggestion to use SNTP (server sends cert)
-
Signature
extension
o
Each
ALC/NORM packet contains a signature header extension
-
What
is next?
o
Split
ID or not
§
One
part standardized in RMT group
§
TESLA
part in MSEC WG
§
Keep
streamlined ALC/NORM instantiation document, avoiding
duplications
o
Work
on some technical aspects
-
Discussion
o
Ran:
Which information shpuld be approved here?
§
Indirect
time sync should be explained in MSEC, usage of SNTP; time
reference
§
Bootstrap
information is part of the TESLA protocol
§
Maybe
more issues to solve here
o
Requirements
come from RMT
o
Ran:
TESLA in MSEC : informational RFC
§
Describes
TELSA independent of a protocol
§
One
document almost fully specified SRTP-TESLA together with MIKEY
§
TESLA
in ESP
§
This
draft could fit in in implementing TESLA
§
Draft
has his own different featrue (key chain, sync, key establishement) : different
than in current approaches, therefore good to have it.
§
Splitting
of the document might depend on the RMT interworking, RMT depending parts should
be handled in RMT WG
o
Bob
B: Does it make sense to send control packets in between an ALC data
stream?
§
Some
discussion ensued ...
o
?:Control
packet better to fit into the data stream than in bootstrapping?
§
Control
packet contains only dedicated information (see slides)
§
MIKEY
is used anyway, why not sending this information as well
§
Needs
to be discussed : (S. Fries) MIKEY bootstrapping currently application
independent, this approach would bring in some dependencies on
ALC/NORM
o
Discussion
regarding WG handling this ID will be done on the list, maybe the transport AD
need to be consulted
o
Russ:
make last call on both MSEC and RMT mailing lists
o
Author:
Indirect time sync and key chain switching may be used for other apps as
well.
o
Lakshminath:
SRTP mentions key chains ... may add more details in ESP-TESLA
draft
o
Ran:
RFC4082 talks about indirect sync (but maybe not
elaborately)
o
Currently
two public implementations available, but only one supporting this
feature
*
draft-cruickshank-ipdvb-sec-00.txt "IPDVB proposal for 10
mins
MSEC
review"
§
ULE
security extensions
§
IP
over DVB (over MPEG2 networks)
§
Security
features shall be provided (encryption, …)
§
Should
not conflict with IPsec
§
Motivations
o
Implementation
of GSAKMP with AH
o
Better
access control for operators
o
Capability
to work with non-IP packet format
o
Protect
identity of the sender receiver within MPEG2 transmission network
(UID)
§
SNDU
format for encryption header
o
New
ULE mandatory extension header for encryption
o
ULE
sec ID is 32 bit value
o
Can
be used by a receiver to filter PDUs
§
Key
management orthogonal, GSAKMP or GDOI can be used
§
MSEC
compatibility issues
o
Encryption
algorithms, key length use of standard IPsec and MSEC
suites)
o
Key
space (re-use MSEC key database)
§
Discussion
o
Comments
needed
o
Sam
Hartman: Ethernet packets can be encapsulated, IP infrastructure used for key
management : Ran: all MSEC key management use IP (e.g., dedicated UDP port),
maybe IPsec sufficient?
o
Author
will think about it
§
(Lakshminath
asked Haitham to follow-up with Hugh Harney and other GSAKMP authors to see if GSAKMP can be run
on non-IP networks and what are the “transport”
requirements.)
§
(Lakshminath
had a discussion with the IPDVB co-chair, Gorry Fairhurst, after the MSEC meeting. The IPDVB list is to discuss the issue
of having to run key management over IP while encapsulated data will not be
using IP networks. The MSEC list
will be cc’ed.)
*
MIKEY/TESLA discussion
-
5
drafts on MIKEY
-
umbrella
document may be the best way to handle the different MIKEY
extensions
-
Ran
C: Roadmap regarding documents needed
-
Further
discussion on the list
-
IPsec
extension : draft has been sent to mailing list for review
o
Lakshminath
to send the draft to IPsec to get initial comments on the
scope
*
closing remarks
3 mins
90 mins