MIKEY: Multimedia Internet KEYing
draft-ietf-msec-mikey-08
The information below is for an old version of the document that is already published as an RFC.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 3830.
|
|
|---|---|---|---|
| Authors | Karl Norrman , Fredrik Lindholm , Elisabetta Carrara , Jari Arkko , Mats Naslund | ||
| Last updated | 2020-01-21 (Latest revision 2003-12-16) | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | Proposed Standard | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | (None) | |
| Document shepherd | (None) | ||
| IESG | IESG state | Became RFC 3830 (Proposed Standard) | |
| Action Holders |
(None)
|
||
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | Russ Housley | ||
| Send notices to | <canetti@watson.ibm.com>, <thardjono@verisign.com> |
draft-ietf-msec-mikey-08
LISP Working Group S. Barkai
Internet-Draft B. Fernandez-Ruiz
Intended status: Experimental S. ZionB
Expires: February 17, 2020 Nexar Inc.
A. Rodriguez-Natal
F. Maino
Cisco Systems
A. Cabellos-Aparicio
J. Paillissé Vilanova
Technical University of Catalonia
D. Farinacci
lispers.net
September 17, 2019
Network-Hexagons: H3-LISP Based Mobility Network
draft-barkai-lisp-nexagon-10
Abstract
This document specifies combined use of H3 and LISP for mobility-networks:
- Enabling real-time tile by tile indexed annotation of public roads
- For sharing: hazards, blockages, conditions, maintenance, furniture..
- Between MobilityClients producing-consuming road geo-state information
- Using addressable grid of channels of physical world state representation
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 4, 2019.
Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3
4. Deployment Assumptions . . . . . . . . . . . . . . . . . . . 4
5. Mobility Clients-Network-Services . . . . . . . . . . . . . . 4
6. Mobility Unicast-Multicast . . . . . . . . . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . . 6
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
10. Normative References . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
(1) The Locator/ID Separation Protocol (LISP) [RFC6830] splits current IP
addresses in two different namespaces, Endpoint Identifiers (EIDs) and
Routing Locators (RLOCs). LISP uses a map-and-encap approach that relies on
(1) a Mapping System (distributed database) that stores and disseminates
EID-RLOC mappings and on (2) LISP tunnel routers (xTRs) that encapsulate
and decapsulate data packets based on the content of those mappings.
(2) H3 is a geospatial indexing system using a hexagonal grid that can be
(approximately) subdivided into finer and finer hexagonal grids,
combining the benefits of a hexagonal grid with hierarchical subdivisions.
H3 supports sixteen resolutions. Each finer resolution has cells with one
seventh the area of the coarser resolution. Hexagons cannot be perfectly
subdivided into seven hexagons, so the finer cells are only approximately
contained within a parent cell. Each cell is identified by a 64bit HID.
(3) The Berkeley Deep Drive (BDD) Industry Consortium investigates state-of-
the-art technologies in computer vision and machine learning for automotive
applications, and, for taxonomy of published automotive scene classification.
These standards are combined to create in-network-state which reflects the
condition of each hexagon tile (~1sqm) in every road. The lisp network maps &
encapsulates traffic between MobilityClients endpoint-identifiers (EID), and,
addressable (HID=
by cautious users as it is the only one that supports so called
perfect forward secrecy (PFS). This is in contrast to a compromise of
the pre-shared key (or the secret key of the public key mode), where
future sessions and recorded session from the past are then also
compromised.
The use of random nonces (RANDs) in the key derivation is of utmost
importance to counter off-line pre-computation attacks. Note however
that update messages re-use the old RAND. This means that the total
effective key entropy (relative to pre-computation attacks) for k
consecutive key updates, assuming the TGKs and RAND are each n bits
long, is about L = n*(k+1)/2 bits, compared to the theoretical
maximum of n*k bits. In other words, a 2^L work effort MAY enable an
attacker to get all k n-bit keys, which is better than brute force
(except when k = 1). While this might seem as a defect, first note
that for proper choice of n, the 2^L complexity of the attack is way
out of reach. Moreover, the fact that more than one key can be
compromised in a single attack is inherent to the key exchange
problematic. Consider for instance a user who, using say a fixed
1024-bit RSA key, exchanges keys and communicates during one or two
years lifetime of the public key. Breaking this single RSA key will
enable access to all exchanged keys and consequently the entire
communication of that user over the whole period.
All the pre-defined transforms in MIKEY use state-of-the-art
algorithms that have undergone large amounts of public evaluation.
One of the reasons to use AES-CM from SRTP [SRTP] is to have the
possibility to limit the overall number of different encryption modes
and algorithms, at the same time that it offers a high level of
security.
9.2. Key lifetime
Even if the lifetime of a TGK (or TEK) is not specified, it MUST be
taken into account that the encryption transform in the underlying
security protocol can in some way degenerate after a certain amount
of encrypted data. It is not possible to here state general key
lifetime bounds, universally applicable; each security protocol
should define such maximum amount and trigger a re-keying procedure
before the "exhaustion" of the key. E.g., according to SRTP [SRTP]
the TEK, together with the corresponding TGK, MUST be changed at
least every 2^48 SRTP packet.
Still, the following can be said as a rule of thumb. If the security
protocol uses an "ideal" b-bit block cipher (in CBC mode, counter
mode, or a feedback mode, e.g. OFB, with full b-bit feedback),
degenerate behavior in the crypto stream, possibly useful for an
attacker, is (with constant probability) expected to occur after a
total of roughly 2^(b/2) encrypted b-bit blocks (using random IVs).
For security margin, re-keying MUST be triggered well in advance
compared to the above bound. See [BDJR] for more details.
Arkko, et al. [Page 51]
INTERNET-DRAFT msec-mikey-08 December, 2003
For use of a dedicated stream cipher, we refer to the analysis and
documentation of said cipher in each specific case.
9.3. Timestamps
The use of timestamps instead of challenge-response requires the
systems to have synchronized clocks. Of course, if two clients are
not synchronized, they will have difficulties with setting up the
security. The current timestamp based solution has been selected to
allow a maximum of one roundtrip (i.e., two messages), but still
provide a reasonable replay protection. A (secure) challenge-response
based version would require at least three messages. For a detailed
description of the timestamp and replay handling in MIKEY, see
Section 5.4.
Practical experiences of Kerberos and other timestamp-based systems
indicate that it is not always necessary to synchronize the terminals
over the network. Manual configuration could be a feasible
alternative in many cases (especially in scenarios where the degree
of looseness is high). However, the choice must be carefully based
with respect to the usage scenario.
9.4. Identity protection
User privacy is a complex matter that to some extent can be enforced
by cryptographic mechanisms, but also requires policy enforcement and
various other functionalities. One particular facet of privacy is
user identity protection. However, identity protection was not a main
design goal for MIKEY. Such feature will add more complexity to the
protocol and was therefore chosen not to be included. As MIKEY is
anyway proposed to be transported over e.g. SIP, the identity may be
exposed by this. However, if the transporting protocol is secured and
also provides identity protection, MIKEY might inherit the same
feature. How this should be done is for future study.
9.5. Denial of Service
This protocol is resistant to Denial of Service attacks in the sense
that a Responder does not construct any state (at the key management
protocol level) before it has authenticated the Initiator. However,
this protocol, like many others, is open to attacks that use spoofed
IP addresses to create a large number of fake requests. This may
e.g., be solved by letting the protocol transporting MIKEY do an IP
address validity test. For example, the SIP protocol can provide this
using the anonymous authentication challenge mechanism (specified in
Section 22.1 of [SIP]).
As also discussed in Section 5.4, the tradeoff between time
synchronization and the size of the replay cache, may be affected in
case of e.g., a flooding type of DoS attack. However, if the
Arkko, et al. [Page 52]
INTERNET-DRAFT msec-mikey-08 December, 2003
recommendations of using a dynamic size of the replay cache are
followed, it is believed that the client will in most cases be able
to handle the replay cache. Of course, as the replay cache decreases
in size, the required time synchronization is more restricted.
However, a bigger problem during such attack would probably be to
process the messages (e.g., verify signatures/MACs), due to the
computational workload this implies.
9.6. Session establishment
It should be noted that if the session establishment protocol is
insecure there may be attacks on this that will have indirect
security implications on the secured media streams. This however only
applies to groups (and is not specific to MIKEY). The threat is that
one group member may re-direct a stream from one group member to
another. This will have the same implication as when a member tries
to impersonate another member, e.g. by changing its IP address. If
this is seen as a problem, it is RECOMMENDED that a Source Origin
Authentication (SOA) scheme (e.g., digital signatures) is applied to
the security protocol.
Re-direction of streams can of course be done even if it is not a
group. However, the effect will not be the same compared to a group
where impersonation can be done if SOA is not used. Instead, re-
direction will only deny the receiver the possibility to receive (or
just delay) the data.
10. IANA considerations
This document defines several new name spaces associated with the
MIKEY payloads. This section summarizes the name spaces for which
IANA is requested to manage the allocation of values.
IANA is requested to record the pre-defined values defined in the
given sections for each name space. IANA is also requested to manage
the definition of additional values in the future. Unless explicitly
stated otherwise, values in the range 0-240 for each name space
SHOULD be approved by the process of IETF consensus and values in the
range 241-255 are reserved for Private Use, according to [RFC2434].
The name spaces for the following fields in the Common header payload
(from Section 6.1) are requested to be managed by IANA (in bracket is
the reference to the table with initial registered values):
* version
* data type (Table 6.1.a)
* Next payload (Table 6.1.b)
Arkko, et al. [Page 53]
INTERNET-DRAFT msec-mikey-08 December, 2003
* PRF func (Table 6.1.c). This name space is between 0-127 where
values between 0-111 should be approved by the process of IETF
consensus and values between 112-127 are reserved for Private Use.
* CS ID map type (Table 6.1.d)
The name spaces for the following fields in the Key data transport
payload (from Section 6.2) are requested to be managed by IANA:
* Encr alg (Table 6.2.a)
* MAC alg (Table 6.2.b)
The name spaces for the following fields in the Envelope data payload
(from Section 6.3) are requested to be managed by IANA:
* C (Table 6.3)
The name spaces for the following fields in the DH data payload (from
Section 6.4) are requested to be managed by IANA:
* DH-Group (Table 6.4)
The name spaces for the following fields in the Signature payload
(from Section 6.5) are requested to be managed by IANA:
* S type (Table 6.5)
The name spaces for the following fields in the Timestamp payload
(from Section 6.6) are requested to be managed by IANA:
* TS type (Table 6.6)
The name spaces for the following fields in the ID payload and the
Certificate payload (from Section 6.7) are requested to be managed by
IANA:
* ID type (Table 6.7.a)
* Cert type (Table 6.7.b)
The name spaces for the following fields in the Cert hash payload
(from Section 6.8) are requested to be managed by IANA:
* Hash func (Table 6.8)
The name spaces for the following fields in the Security policy
payload (from Section 6.10) are requested to be managed by IANA:
* Prot type (Table 6.10)
Arkko, et al. [Page 54]
INTERNET-DRAFT msec-mikey-08 December, 2003
For each security protocol that uses MIKEY, a set of unique
parameters MAY be registered.
From Section 6.10.1.
* SRTP Type (Table 6.10.1.a)
* SRTP encr alg (Table 6.10.1.b)
* SRTP auth alg (Table 6.10.1.c)
* SRTP PRF (Table 6.10.1.d)
* FEC order (Table 6.10.1.e)
The name spaces for the following fields in the Error payload (from
Section 6.12) are requested to be managed by IANA:
* Error no (Table 6.12)
The name spaces for the following fields in the Key data payload
(from Section 6.13) are requested to be managed by IANA:
* Type (Table 6.13.a). This name space is between 0-16 which should
be approved by the process of IETF consensus.
* KV (Table 6.13.b). This name space is between 0-16 which should be
approved by the process of IETF consensus.
The name spaces for the following fields in the General Extensions
payload (from Section 6.15) are requested to be managed by IANA:
* Type (Table 6.15).
10.1 MIME Registration
This section gives instructions to IANA to register the
application/mikey MIME media type. This registration is as follows:
MIME media type name : application
MIME subtype name : mikey
Required parameters : none
Optional parameters : version
version: The MIKEY version number of the enclosed message
(e.g., 1). If not present, the version defaults to 1.
Encoding Considerations : binary, base64 encoded
Security Considerations : see section 9 in this memo
Interoperability considerations : none
Published specification : this memo
Arkko, et al. [Page 55]
INTERNET-DRAFT msec-mikey-08 December, 2003
>EID) tile-states. States are aggregated byH3Service EIDs.
The H3-LISP mobility network bridges timing-location gaps between the
production and consumption of information by MobilityClients:
o vision, sensory, LIADR, AI applications - information producers
o driving-apps, smart-infrastructure, command & control - who consume it
This is achieved by putting the physical world on a shared addressable
geo-state grid at the edge, a low-latency production-consumption indirection.
Tile by tile based geo-state mobility-network solves key issues in todays'
vehicle to vehicle networking, where observed hazards are expected to be
relayed or "hot-potato-tossed" (v2v without clear-reliable convergence i.e.
given a situation observable by some of traffic, it is unclear if the rest of
the relevant traffic will receive consistent, conflicting, multiple, or no
indication what so ever - using peer-to-peer propagation.
For example, when a vehicle experiences a sudden highway slow-down,"sees" many
brake-lights or "feels" accelerometer, there is no clear way for it to share
this annotation with vehicles 20-30sec away for preventing potential pile-up.
Or, when a vehicle crosses an intersection, observing opposite-lane
obstruction - construction, double-park, commercial-loading / un-loading,
garbage truck, or stopped school-bus - there is no clear way for it to alert
vehicles turning in to that situation as it drives away.
Geo-state indirection also helps solve communicating advanced machine-vision
and radar annotations. These are constantly evolving technologies, however,
communicating the road enumerations they produce using peer-to-peer protocols
poses a significant interoperability challenge - testing each new annotation
by any sensor / OEM vendor and any other OEM and driving application vendor.
These peer-to-peer limitations are inherit yet unnecessary, as in most road
situations vehicles are not really proper peers. They just happen to be in the
same place at the same time. The H3-LISP mobility network solves limitations
of direct vehicle to vehicle communication because it anchors per each geo-
location: timing, security, privacy, interoperability. Anchoring is by
MobilityClients communicating through in-network geo-states. Addressable tiles
are aggregated and maintained by LISP H3ServiceEIDs.
An important set of use-cases for state propagation of information to
MobilityClients is to provide drivers heads-up alerts on hazards and obstacles
beyond line of sight of both the drivers and in-car sensors: over traffic,
around blocks, far-side-junction, beyond turns, and surface-curvatures.
This highlights the importance of networks in providing road-safety.
To summarize the H3-LISP solution outline:
(1) MicroPartition: 64bit indexed geo-spatial H3.r15 road-tiles
(2) EnumState: 64bit state values compile tile condition representation
(3) Aggregation: H3.r9 H3ServiceEID group individual H3.r15 road-tiles
(4) Channels: H3ServiceEIDs function as multicast state update channels
(5) Scale: H3ServiceEIDs distributed for in-network for latency-throughput
(6) Mapped Overlay: tunneled-network routes the mobility-network traffic
(7) Signal-free: tunneled overlay is used to map-register for mcast channels
(8) Aggregation: tunnels used between MobilityClients/H3ServiceEIDs <> edge
(9) Access: ClientXTRs/ServerXTRs tunnel traffic to-from the LISP EdgeRTRs
(10) Control: EdgeRTRs register-resolve H3ServiceEIDs and mcast subscription
|-0-|-1-|-2-|-3-|-4-|-5-|-6-|-7-|-8-|-9-|-A-|-B-|-C-|-D-|-E-|-F-|
| H3 Hexagon ID Key |
|-0-|-1-|-2-|-3-|-4-|-5-|-6-|-7-|-8-|-9-|-A-|-B-|-C-|-D-|-E-|-F-|
| H3 Hexagon State-Value |
|---------------------------------------------------------------|
___ ___
H3ServiceEIDs ___ / \ H3ServiceEIDs ___ / \
___ / | H3.r9 | ___ / | H3.r9 |
/ | H3.r9 \ ___ / / | H3.r9 \ ___ /
| H3.r9 \ ___ / sXTR | H3.r9 \ ___ / sXTR
\ ___ / sXTR | \ ___ / sXTR |
sXTR | | sXTR | |
| | | | | |
| | | | | |
+ - - + - - EdgeRTR EdgeRTR - + - + - - +
|| ( ( (( ||
( )
( Network Hexagons )
( H3-LISP )
( Mobility Network )
(( )
|| (( (()) () ||
|| ||
= = = = = = = = = = = = = =
|| ||
EdgeRTR EdgeRTR
.. .. .. ..
.. .. .. ..
((((|)))) ((((|)))) ((((|)))) ((((|))))
/|\ RAN /|\ /|\ RAN /|\
.. ..
.. ..
.. Road tiled by 1sqm H3.r15 ID-Ed Geo-States ..
.. ..
.. ___ ___ ___ ..
.. .............. / \/ \/ \ << cXTR::MobilityClientB
.. - - - - - - - H3.r15 H3.r15 H3.r15 - - - - - - -
MobilityClientA::cXTR >> \ ___ /\ ___ /\ ___ /..........
- MobilityClientA has seen MobilityClientB (20-30 sec) future, and, vice versa
- Clients share information using addressable shared-state routed by LISP Edge
- ClientXTR (cXTR): tunnel encapsulation through access network to LISP Edge
- ServerXTR (sXTR): tunnel encapsulation through cloud network to LISP Edge
- The H3-LISP Mobility overlay starts in the cXTR and terminates in the sXTR
- The updates are routed to the appropriate tile geo-state by the LISP network
- EdgeRTRs perform multicast replication to edges and then native or to cXTRs
- Clients receive tile-by-tile geo-state updates via the multicast channels
Each H3.r9 hexagon is an EID Service with corresponding H3 hexagon ID.
Bound to that service is a LISP xTR, called a ServerXTR, resident to deliver
encapsulated packets to and from the H3ServiceEID and LISP Edge. EdgeRTRs are
used to re-tunnel packets from MobilityClients to H3ServiceEIDs. Each
H3ServiceEID is also a source multicast address for updating MobilityClients
on the state of the H3.r15 tiles aggregated-represented by the H3ServiceEID.
2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. Definition of Terms
H3ServiceEID: Is an addressable aggregation of H3.r15 state-tiles. It is a
designated source for physical world reported annotations, and an (s,g)
source of multicast public-safety update channels. H3ServiceEID is itself
an H3 hexagon, large enough to provide geo-spatial conditions context, but
not too large as to over-burden (battery powered, cellular connected)
subscribers with too much information. For Mobility Network it is H3.r9.
It has a light-weight LISP protocol stack to tunnel packets aka ServerXTR.
The EID is an IPv6 EID that contains the H3 64-bit address numbering
scheme. See IANA consideration for details.
ServerXTR: Is a light-weight LISP protocol stack implementation that co-exists
with H3ServiceEID process. When the server roams, the xTR roams with it.
The ServerXTR encapsulates and decapsulates packets to/from EdgeRTRs.
MobilityClient: Is a roaming application that may be resident as part of an
automobile, as part of a navigation application, part of municipal, state,
of federal government command and control application, or part of live
street view consumer type of application. It has a light-weight LISP
protocol stack to tunnel packets aka ClientXTR.
MobilityClient EID: Is the IPv6 EID used by the Mobility Client applications
to source packets. The destination of such packets are only H3ServiceEIDs.
The EID format is opaque and is assigned as part of the MobilityClient
network-as-a-service (NaaS) authorization.
ClientXTR: Is the light-weight LISP protocol stack implementation that is
co-located with the Mobility Client application. It encapsulates packets
sourced by applications to EdgeRTRs and decapsulates packets from EdgeRTRs.
EdgeRTR: Is the core scale and structure of the LISP mobility network.
EdgeRTRs proxy H3ServiceEIDs and MobilityClient H3ServiceEID channel
registration. EdgeRTRs aggregate MobilityClients and H3Services using
tunnels to facilitate hosting-providers and mobile-hosting flexibility -
for accessing the nexagon mobility network.
EdgeRTRs decapsulate packets from ClientXTRs and ServerXTRs and re-encapsulates
packets to the clients and servers tunnels. EdgeRTRs glean H3ServiceEIDs
and glean MobilityClient EIDs when it decapsulates packets. EdgeRTRs store
H3ServiceEIDs and their own RLOC of where the H3ServiceEID is currently
reachable from in the map-cache. These mappings are registered to the LISP
mapping system so other EdgeRTRs know where to encapsulate for such EIDs.
EdgeRTRs do not register MobilityClients' EIDs at the mapping service as
these are temporary-renewed while using the mobility network. Enterprises
may provide their own client facing EdgeRTRs to mask their clients geo-
whereabouts while using the mobility network.
4. Deployment Assumptions
The specification described in this document makes the following
deployment assumptions:
(1) Unique 64-bit HID is associated with each H3 geo-spatial tile
(2) MobilityClients and H3ServiceEIDs share this well known index
(3) 64-bit BDD state value is associated with each H3-indexed tile
(4) Tile state is compiled 16 fields of 4-bits, or max 16 enums
|-0-|-1-|-2-|-3-|-4-|-5-|-6-|-7-|-8-|-9-|-A-|-B-|-C-|-D-|-E-|-F-|
0123012301230123012301230123012301230123012301230123012301230123
Subscription of MobilityClients to the mobility network is temporary-renewed
while on the move and is not intended as means of basic connectivity. This
is why MobilityClients use DNS/AAA to obtain temporary EIDs and EdgeRTRs
and why they use (LISP) data-plane tunnels to communicate using their
temporary EIDs with the dynamically assigned EdgeRTRs.
MobilityClient are otherwise unaware of the LISP network mechanism or mapping
system and simply regard the data-plane tunnels application specific virtual
private network (VPN) that supports IPv6 EID addressable geo-state for publish
(Ucast), Subscribe (Mcast) H3Services.
In order to get access to the MobilityVPN MobilityClients first authenticate
with the MobilityVPN AAA Server. DIAMETER based AAA is typically done at the
provider-edge PE by edge gateways. However the typical case involves handful
of customer-premise equipment(CPE/UE) types physically connected by wireline,
or, by wireless spectrum to a specific service-provider. The Mobility VPN
overlays potentially a number of wireless network providers and cloud-edge
providers, and it involves dozens of Car-OEM, Driving-Applications, Smart-
infrastructure vendors. It is therefore required to first go through AAA
in-order to get both a MobilityClientEID and EdgeRTR gateway RLOC opened.
ClientXTR performs the following steps in-order to use the mobility network:
1) obtain the address of the mobility network AAA server using DNS
2) obtain MobilityClientEID and EdgeRTR(s) from AAA server using DIAMETER
3) renew authorization from AAA while using the mobility network T1 minutes
MobilityClient Domain Name Server DIAMETER AAA Mobility EdgeRTR
| | | |
| nslookup nxgn.adas | | |
|------------------->| | |
|<-------------------| | |
| Mobility AAA IP | | |
| | | |
| ACR(AVP:IMSI/User/Password/Toyota) | |
|--------------------------------------->| |
| | | ACR(AVP ClientEID |
| | |------------------>|
| | |<------------------|
| | | ACA(AVP ClientEID)|
| ACA (Client::EID,EdgeRTR::RLOC) | |
|<---------------------------------------| |
| | | |
| Publish IPv6 H3ServiceEID, Subscribe MLDv2 H3ServiceEID |
|----------------------------------------------------------->|
|<-----------------------------------------------------------|
| Signal freeing multicast Updates from H3ServiceEIDs |
| | | |
| ACR (Interim) | |
|--------------------------------------->| ACR (Interim) |
| | |------------------>|
| | |<------------------|
| | | ACA (Interim) |
|&11. Acknowledgments
The authors would like to thank Mark Baugher, Ran Canetti, Martin
Euchner, Steffen Fries, Peter Barany, Russ Housley, Pasi Ahonen (with
his group), Rolf Blom, Magnus Westerlund, Johan Bilien, Jon-Olov
Vatn, and Erik Eliasson for their valuable feedback.
12. Author's Addresses
Jari Arkko
Ericsson
02420 Jorvas Phone: +358 40 5079256
Finland Email: jari.arkko@ericsson.com
Elisabetta Carrara
Ericsson Research
SE-16480 Stockholm Phone: +46 8 50877040
Sweden EMail: elisabetta.carrara@ericsson.com
Fredrik Lindholm
Ericsson Research
SE-16480 Stockholm Phone: +46 8 58531705
Sweden EMail: fredrik.lindholm@ericsson.com
Mats Naslund
Ericsson Research
SE-16480 Stockholm Phone: +46 8 58533739
Sweden EMail: mats.naslund@ericsson.com
Karl Norrman
Ericsson Research
SE-16480 Stockholm Phone: +46 8 4044502
Sweden EMail: karl.norrman@ericsson.com
13. References
13.1. Normative References
[AES] Advanced Encryption Standard (AES), Federal Information
Processing Standard Publications (FIPS PUBS) 197, November 2001.
[HMAC] Krawczyk, H., Bellare, M., Canetti, R., "HMAC: Keyed-Hashing
for Message Authentication", RFC 2104, February 1997.
[NAI] Aboba, B. and Beadles, M., "The Network Access Identifier",
IETF, RFC 2486, January 1999.
[OAKLEY] Orman, H., "The Oakley Key Determination Protocol", RFC
2412, November 1998.
Arkko, et al. [Page 56]
INTERNET-DRAFT msec-mikey-08 December, 2003
[PSS] PKCS #1 v2.1 - RSA Cryptography Standard, RSA Laboratories,
June 14, 2002, www.rsalabs.com
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[RFC2434] Narten, T., Alvestrand, H., "Guidelines for Writing an IANA
Considerations Section in RFCs", RFC 2434, October 1998.
[RSA] Rivest, R., Shamir, A., and Adleman, L. "A Method for Obtaining
Digital Signatures and Public-Key Cryptosystems". Communications of
the ACM. Vol.21. No.2. pp.120-126. 1978.
[SHA-1] NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995.
http://csrc.nist.gov/fips/fip180-1.ps
[SRTP] Baugher, M., Blom, R., Carrara, E., McGrew, D., Naslund, M,
Norrman, K., and Oran, D., "The Secure Real Time Transport Protocol",
Internet Draft, IETF, Work in Progress (AVT WG).
[URI] Berners-Lee. T., Fielding, R., Masinter, L., "Uniform Resource
Identifiers (URI): Generic Syntax", IETF, RFC 2396.
[X.509] Housley, R., Polk, W., Ford, W., and Solo, D., "Internet
X.509 Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile", IETF, RFC 3280.
[AESKW] Schaad, J., Housley R., "Advanced Encryption Standard (AES)
Key Wrap Algorithm", IETF, RFC 3394.
13.2. Informative References
[AKE] Canetti, R. and Krawczyk, H., "Analysis of Key-Exchange
Protocols and their use for Building Secure Channels", Eurocrypt
2001, LNCS 2054, pp. 453-474, 2001.
[BDJR] Bellare, M., Desai, A., Jokipii, E., and Rogaway, P., "A
Concrete Analysis of Symmetric Encryption: Analysis of the DES Modes
of Operation", in Proceedings of the 38th Symposium on Foundations of
Computer Science, IEEE, 1997, pp. 394-403.
[BMGL] Hastad, J. and Naslund, M.: "Practical Construction and
Analysis of Pseduo-randomness Primitives", Proceedings of Asiacrypt
'01, Lecture Notes in Computer Science vol 2248, pp. 442-459.
[DBJ] Johnson, D.B., "Theoretical Security Concerns with TLS use of
MD5", Contribution to ANSI X9F1 WG, 2001.
Arkko, et al. [Page 57]
INTERNET-DRAFT msec-mikey-08 December, 2003
[FIPS] "Security Requirements for Cryptographic Modules", Federal
Information Processing Standard Publications (FIPS PUBS) 140-2,
December 2002.
[GKMARCH] Baugher, M., Canetti, R., Dondeti, L., and Lindholm, F.,
"Group Key Management Architecture", Internet Draft, Work in Progress
(MSEC WG).
[GDOI] Baugher, M., Hardjono, T., Harney, H., Weis, B., "The Group
Domain of Interpretation", Internet Draft, Work in Progress (MSEC
WG).
[GSAKMP] Harney, H., Colegrove, A., Harder, E., Meth, U., Fleischer,
R., "Group Secure Association Key Management Protocol", Internet
Draft, Work in Progress (MSEC WG).
[HAC] Menezes, A., van Oorschot, P., and Vanstone, S., "Handbook of
Applied Cryptography", CRC press, 1996.
[IKE] Harkins, D. and Carrel, D., "The Internet Key Exchange (IKE)",
RFC 2409, November 1998.
[ISO1] ISO/IEC 9798-3: 1997, Information technology - Security
techniques - Entity authentication - Part 3: Mechanisms using digital
signature techniques.
[ISO2] ISO/IEC 11770-3: 1997, Information technology - Security
techniques - Key management - Part 3: Mechanisms using digital
signature techniques.
[ISO3] ISO/IEC 18014 Information technology - Security techniques -
Time-stamping services, Part 1-3.
[KMASDP] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and
Norrman, K., "Key Management Extensions for SDP and RTSP", Internet
Draft, Work in Progress (MMUSIC WG).
[LOA] Burrows, Abadi, and Needham, "A logic of authentication", ACM
Transactions on Computer Systems 8 No.1 (Feb. 1990), 18-36.
[LV] Lenstra, A. K., and Verheul, E. R., "Suggesting Key Sizes for
Cryptosystems", http://www.cryptosavvy.com/suggestions.htm
[NTP] Mills, D., "Network Time Protocol (Version 3) specification,
implementation and analysis", RFC 1305, March 1992.
[OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., and Adams
C., "X.509 Internet Public Key Infrastructure Online Certificate
Status Protocol - OCSP", IETF, RFC 2560.
Arkko, et al. [Page 58]
INTERNET-DRAFT msec-mikey-08 December, 2003
[RAND] Eastlake, D., Schiller, J., and Crocker, S., "Randomness
Requirements for Security", RFC 1750, December 1994.
[RTSP] Schulzrinne, H., Rao, A., and Lanphier, R., "Real Time
Streaming Protocol (RTSP)", RFC 2326, April 1998.
[SDP] Handley, M., Jacobson, V., and Perkins, C., "SDP: Session
Description Protocol", Internet Draft, IETF, Work in progress
(MMUSIC), draft-ietf-mmusic-sdp-new-15.txt.
[SHA256] NIST, "Description of SHA-256, SHA-384, and SHA-512",
http://csrc.nist.gov/encryption/shs/sha256-384-512.pdf
[SIP] Rosenberg, J. et al, "SIP: Session Initiation Protocol", IETF,
RFC3261.
[TLS] Dierks, T. and Allen, C., "The TLS Protocol - Version 1.0",
IETF, RFC 2246.
Appendix A. - MIKEY - SRTP relation
The terminology in MIKEY differs from the one used in SRTP as MIKEY
needs to be more general, nor is tight to SRTP only. Therefore it
might be hard to see the relations between keys and parameters
generated in MIKEY and the ones used by SRTP. This section provides
some hints on their relation.
MIKEY | SRTP
-------------------------------------------------
Crypto Session | SRTP stream (typically with related SRTCP stream)
Data SA | input to SRTP's crypto context
TEK | SRTP master key
The Data SA is built up by a TEK and the security policy exchanged.
SRTP may use a MKI to index the TEK, or TGK (the TEK is then derived
from the TGK that is associated with the corresponding MKI), see
below.
A.1 MIKEY-SRTP interactions
In the following, we give a brief outline of the interface between
SRTP and MIKEY and the processing that takes place. We describe SRTP
receiver side only, the sender side will require analogous
interfacing.
1. When an SRTP packet arrives at the receiver and is processed, the
triple <SSRC, destination address, destination port> is extracted
from the packet and used to retrieve the correct SRTP crypto context,
hence the Data SA. (The actual retrieval can e.g. be done by an
explicit request from the SRTP implementation to MIKEY, or, by the
Arkko, et al. [Page 59]
INTERNET-DRAFT msec-mikey-08 December, 2003
SRTP implementation accessing a "data base", maintained by MIKEY. The
application will typically decide which implementation is preferred.)
2. If an MKI is present in the SRTP packet, it is used to point to
the correct key within the SA. (Alternatively, if SRTPÆs <From, To>
feature is used, the ROC||SEQ of the packet is used to determine the
correct key.)
3. Depending on whether the key sent in MIKEY (as obtained in step 2)
was a TEK or a TGK, there are now two cases.
- If the key obtained in step 2 is the TEK itself, it is used
directly by STRP as a master key.
- If the key instead is a TGK, the mapping with the CS_ID (internal
to MIKEY, Section 6.1.1) allows MIKEY to compute the correct TEK
from the TGK as described in Section 4.1 before SRTP uses it.
If multiple TGKs (or TEKs) are sent, it is RECOMMENDED to associate
each TGK (or TEK) to a distinct MKI. It is RECOMMENDED to limit the
use of <From, To> in this scenario to very simple cases, e.g. one
stream only.
Besides the actual master key, other information in the Data SA (e.g.
transform identifiers) will of course also be communicated from MIKEY
to SRTP.
IPR Notices
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Copyright Notice
Arkko, et al. [Page 60]
INTERNET-DRAFT msec-mikey-08 December, 2003
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
This Internet-Draft expires in June 2004.
Arkko, et al. [Page 61]