MSEC minutes, Steffen Fries, edited by Lakshminath Dondeti
ldondeti@qualcomm.com
**Update on milestones & Recent progress in MSEC (Lakshminath)
o Bootstrapping TESLA to IETF last call
o Policy token in review
o Newtype key id waiting for 3GPP feedback ' until then stalled
o SRTP TESLA now in RFC Editors queue
**Action items from Paris:
o IPsec extensions work for scoping review from IPSEC list,
>> Revision 1 will be made and send to IPsec list,
o Discussion on MIKEY, roadmaps
o MIKEY RSA-R to be sent to MMUSIC group
o Milestone have been updated
**Update on Bootstrapping TESLA (Steffen Fries)
o Comments received from AD review
o Mostly editorial changes
o Clarified and described relations to other existing RFCs and IDs
(MIKEY, SRTP, SRTP-TESLA)
o Clarified description of TESLA parameter
o Reworked some attacks in the security consideration section
o Current document in state: In Last Call
** Update on GDKP (Lakshminath)
o Next version will be posted in January
o [After the meeting] we have a new volunteer to work on this:
srowles@cisco.com (Sheela Rowles)
** Discussion on MIKEY modes
o MIKEY-ECC (Lakshminath provided a brief update)
No progress made, one comment from Steffen, which needs to
be incorporated
Russ asked for IPR statement on MQV
Russ thought it is already in place. But Brian Minard from Certicom
noted that the IPR statements have not yet been submitted.
o MIKEY-RSA-R (Dragan)
Current version 1
Concept of multiple TGKs introduced (section 4)
Motivation: media lines for Multicast and Unicast in the same
payload, to have single MIKEY line in SDP)
Two TGKs used
*Outstanding issue: mapping of TGKs to media streams
<>
<>
o MIKEY-DH based mode (New proposal)
SAML assistend Diffie Hellman Mikey (R.Moskowitz)
Based from discussion in VoiP SA consortium's list
** Requirements:
o Mutual authentication
o Both parties involved in key generation
o PFS
o Support distribution of group keys
Observations
o Diffie Hellman solves some requirements (2+3)
o 1 can be done with SAML
o second roundtrip can be used for item 4,5 und 6
Scenarios
o Peer-to-peer
o Simple one to many
o Small sized groups
Trusted UA credentials
Notes:
o Parties should have trusted credentials containing UA Identity, DH
Public key, proof of trust, time range of trusting the credential
o Low latency and computational overhead
o MIKEY before talking, but after pickup
o Credential validation as hidden latency
o If UA receives SAML certificate from its domains SIP server
o It trusts the cert implicitly
o Removes hidden latency
o Common use of DH key in keyed hash over nonce and other data
o Consider DH key size
o Recommendation to use 4096 bit DH to equal to 128 bit AES
o Too expensive
o Use ECC DH?
** What next
o Generate interest
o Finish first draft
o Legal intercept
o If both parties are registered to the same SIP domain, SIP server
can lie and generate 2 SAML certs to place himself in MiTM
o Different domains: SIP server can collude, both generating
2 SAML certs
** Discussion
o SIP currently does not handle SAML certs, main load is on the
server, not on the client (d/ Brian Weis)
Rich Graveman: Question about long vs. short DH keys
o different p and q for short key vs. long key
o phones could get new prime periodically
o second roundtrip optional, if clocks are totally out of sync, will
be determined during first roundtrip
Steffen Fries: How does the 4 message version fit with the SIP
offer/answer model?
RM: It is optional; and remember that this offers an answer to the
problem of clock sync requirements
David McGrew: Optional round-trip: Does it precede or follow the mandatory
exchange?
RM: It follows.
DM: FYI: Pre-conditions work in the MMUSIC WG has issues with
an exchange preceding the key establishment exchange.
DM: o problem with early media
Media gets back before the key exchange is finished.
SF: This is the same problem with the other DH exchanges in MIKEY
RM: If MIKEY lags behind media, there is no solution.
** asking for support to produce a draft
<>
** Update on the IPsec Extensions work (Brian Weis)
o draft-ietf-msec-ipsec-extensions-00.txt
o anti replay protection for multi-sender SAs is NOT in scope
o single sender can use RFC2401 anti reply counter
o multi-sender IPsec SAs are problematic
o for a small number of senders, it might be ok to just have
as many IPsec SAs as there are senders.
o issue 1: goal of this document
o option 1 defines a group wide GSA architecture resulting in complete
interoperability between heterogeneous devices
o IPsec SA
o GKM
o option 2 defines a group wide IPsec SA architecture, resulting in
IPsec interoperability between heterogeneous devices
o IPsec SA
Russ: 2401bis gets through the entire architecture without touching
IKE. Why do you think you can't do the same thing.
o Guidance: As far as rfc2401bis goes
o Issue 2: GCKS Deployments
o Should the document mandate multiple GCKS device be defined in this
architecture?
Russ: That sounds like interesting work, but not for this document.
o Issue 3: Composite cryptographic groups
o Motivation: can not easily upgrade a large scale group
o Packet replication (one sends only a packet to one receiver, who
promotes the packet to the composite group ..)
o Composite transport mode
o Option 1: Replication happens at the host
o E2e security
o Option 2: Replication in network
o Question? Necessary for this document to support all modes
o Comes down to replication, requires an RFC2401bis compliant
implementation to provide replication
Lakshminath: Can we not define the simple case and extensions will
just reuse that building block?
<>
<>
o Issue 4: GKMS/IPsec interface
o Question: should all GKMPs use the same namespace as a common
interface to IPsec?
o Would simplify the interface, but what is the interface?
o Policy Token
o IPsec SA Attributes
o API
PF_KEY was mentioned as a potential here. (Editor's note: PF_KEY has had
its ups and downs in the IETF. We want to tread that carefully to
make sure we don't get into a rathole).
o Next steps
o Resolve scope issues
o Issue 01 before IETF65
o Discussion on the list
o Discussion
o Multi senders - sender ID in multicast ESP not considered so far '
not backwards compatible
Some general discussion:
What are the implications of using CTR mode and combined modes
like GCM in this document?
Q: Are we talking about IV space management between sender?
Russ: It would be in scope in so far as deciding where these fit
in the IPsec databases.
*** We ran out of time to start a discussion on the MIKEY mode
explosion. Will start a discussion on the list.
|