One document matched: draft-jml-ipsec-ikev2-security-context-01.txt
Differences from draft-jml-ipsec-ikev2-security-context-00.txt
Network Working Group J. Latten
Internet-Draft G. Wilson
Intended Status: Standards Track S. Hallyn
Expires: January 10, 2010 IBM
T. Jaeger
Penn State
July 10, 2009
Security Context Addendum to IPsec
draft-jml-ipsec-ikev2-security-context-01
Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 10, 2010.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Latten, et al. Expires January 10, 2010 [Page 1]
Internet-Draft IKEv2SecurityContext July 2010
Abstract
This document describes the high-level requirements needed within
IPsec to support Mandatory Access Control (MAC) on network
communications. It describes the extensions to the Security
Architecture for the Internet Protocol [RFC4301] and the Internet
Key Exchange Protocol Version 2 [RFC4306]. It also describes the
negotiation of the security context for a particular Authentication
Header (AH) [RFC4302] and/or Encapsulating Security Payload (ESP)
[RFC4303] security association.
1. Introduction
In computer security, Mandatory Access Control usually refers to a
system in which all subjects and objects are labeled with a security
context. The security context is comprised of a set of security
attributes. The security contexts along with a system authorization
policy determine access. Rules within the system authorization policy
determine whether the access will be granted based on the security
attributes of the subject and object.
Traditionally, MAC implied Multilevel Security (MLS) systems. MLS
utilizes a security level consisting of a sensitivity and a set of
categories [MayMacCap]. The sensitvity level is hierarchical, the
categories are not. This document will refer to the sensitivity
and set of categories as the MLS security level. The MLS security
levels allow segregation of information thus facilitating data
confidentiality.
As MAC systems have become more mainstream, they are no longer just
associated with MLS. Operating system security concerns have
expanded beyond the MLS goal of protecting the confidentiality of
sensitive data using the model of government classified documents
[MayMacCap]. Methods such as Type Enforcement are being used to
compose rules about access using security attributes other than
a sensitivity level and categories. Some MAC systems employ both
MLS and Type Enforcement to control access and require additional
security attributes as well as the sensitivity level and categories
[MayMacCap].
These MAC systems concentrate on securing local objects and
resources but have no way of applying their security contexts to
network communications to ensure the same security.
Techniques such as IP Security Options (IPSO) allow IP datagrams to
be labeled with a MLS security level [RFC1108]. However, they do not
accomodate additional security attributes. [FIPS-188] describes free
form tags that would allow additional attributes, but the data
including the security context is not protected nor are the bindings
Latten, et al. Expires January 10, 2010 [Page 2]
Internet-Draft IKEv2SecurityContext July 2009
between the data and the security context.
This document will describe how IPsec mechanisms can support MAC
on network communications. It will also describe the additions to
IKEv2 to support security contexts during negotiations to establish
an AH or ESP security association.
Within this document, MAC networking and labeled networking are
used interchangeably and refer to applying MAC on network
communications.
2. Terminology
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. Labeled Networking
Within a MAC environment, the underlying security mechanism applies
a security context to all the subjects and objects on the local
system. The security context along with a MAC authorization policy
determines whether a subject may access an object.
In labeled networking, a security context is applied to data
transmitted over the network. The MAC policy can then use this label
to make informed access decisions.
IPsec mechanisms can support labeled networking whether implicit or
explicit labels are being used.
Explicit labeling refers to transmitting the security context in the
IP datagram, such as in IPSO. When explicit labeling is used the
encryption and authentication services provided in IPsec can be
used to authenticate the bindings between the security context in
the IP header and payload and provide confidentiality [RFC2401].
In an implicit labeling scheme, the security context is not
transmitted as part of the IP datagram. IPsec can provide implicit
labeling by including the security context in the Security
Association. Thus requiring the use of only one protocol, IPsec,
to associate a label with the data, protect the label and the data,
as well as protect and preserve the binding between the label and
the data.
3.1 Relationship Between a Security Association and Security Context
In labeled networking, the traffic between two systems may require
several different security contexts. For example, ftp and telnet
Latten, et al. Expires January 10, 2010 [Page 3]
Internet-Draft IKEv2SecurityContext July 2010
programs may each label their data with a different security context.
Recall that SAs exist in pairs, one for inbound and one for outbound.
Each instance of a security context on a traffic stream will require
an SA pair. Thus traffic between two systems may have several SA
pairs with identical selector information except for the security
context. If using both ESP and AH for a particular traffic stream,
then there will be an ESP SA pair and an AH SA pair per instance of
a security context.
3.2 Security Context Selector
[RFC4301] describes the Security Policy Database (SPD), and the
Security Association Database (SAD) and corresponding selectors.
This document introduces an additional selector, the Security
Context selector. Both the SPD and SA entries contain a security
context selector and this selector is only required when labeled
networking is deployed. The selector contains security context data
that is determined by the MAC layer.
The security context selector effectively labels the SPD and SA
entries, permitting the local MAC policy to authorize use of the
entries.
The security context within the SPD entry also indicates that labeled
networking is to be deployed on this particular traffic stream. Thus,
SPD entries containing a security context MUST generate SAs that
contain a security context. The security context data within
the SA also provides a label for the data.
[RFC4301] describes the use of selectors to determine the
granularity of the SA. An SA pair will exist for each unique instance
of a security context on a traffic stream. Thus for a given traffic
stream, there may be multiple SAs with the same selector values
except for the security context selector. Matching the data's
security context determined by the MAC layer to the security context
in the security context selector ensures the appropriate SA is chosen
when using labeled networking.
3.3 Security Context Selector and PFP
[RFC4301] introduced and described Populate From Packet (PFP)
flags. When creating an SA, the PFP flag determines whether to
instantiate the corresponding selector in the new SA with
information from the packet that triggered the creation or from
information in the corresponding SPD entry.
Within a MAC environment, the security context associated with
an SA will not be the same as the one in the SPD entry. The
Latten, et al. Expires January 10, 2010 [Page 4]
Internet-Draft IKEv2SecurityContext July 2009
security contexts in the SPD entry and in the SA entry are to label
two different objects respectively. The security context in the SPD
entry controls access to the entry itself and it's IPsec
configuration information. Thus the SPD entry itself is considered an
object. The SA's security context provides security attributes for
the packet which may also indicate the security attributes of the
sender or process.
Therefore, when using IPsec to provide implicit labels, the PFP flag
MUST NOT be used to determine where to get the security context for
the new SA. This could result in SPD entry and SA having the same
security context.
3.4 Consistency Checking
[RFC2401] described Sensitivity Consistency Checking for MLS. This
description is included here and extended to include security
contexts.
A MAC implementation MAY associate a security context with an
interface, or a configured IP address with its associated prefix.
If so, the MAC implementation SHOULD authorize the security context
associated with the packet and the security context of the
interface or address/prefix from which the packet arrived or through
which the packet will depart [RFC2401].
The checking SHOULD be done on both inbound and outbound processing.
3.5 Additional Inbound Processing
[RFC2401] described Additional Inbound Processing for MLS. This
description is included here and extended to include security
contexts.
The MAC system MUST retain the binding between the data received
in an IPsec protected packet and the security context in the SA
used for processing, so appropriate policy decisions can be made
when delivering the datagram to an application of forwarding engine.
The means for maintaining this binding are implementation specific
[RFC2401].
3.5 Additional Outbound Processing
[RFC2401] described Additional Outbound Processing for MLS. This
description is included here and extended to include security
contexts.
When consulting the SAD to find an outbound security association,
the data's security context MUST be used to select the appropriate
Latten, et al. Expires January10, 2010 [Page 5]
Internet-Draft IKEv2SecurityContext July 2009
outbound SA.
3.6 MAC Processing for Security Gateways
[RFC2401] described Additional MLS Processing for Security Gateways.
The description is included here and extended to include security
contexts.
A security gateway enforcing MAC MAY act as an outbound proxy,
creating SAs for systems that originate packets forwarded by the
gateway. These systems may explicitly label the packets, or the
whole originating network may have security attributes associated
with it. The security gateway MUST create and use SAs to protect
such traffic it forwards [RFC2401].
Similarly, such a gateway SHOULD accept and process inbound IPsec
packets and forward appropriately, using explicit packet labeling
or security attributes of the destination network [RFC2401].
4. Security Context Transform
This document introduces a new transform type to communicate the
security context when creating Child SAs during the IKE_AUTH exchange
and CREATE_CHILD_SA exchange. Security contexts are only included in
IPsec SAs and not IKE SAs.
The transform type value is:
Description Transform Type Used In
.................................................
Security Context IANA ESP and AH
Only one security context transform containing only one security
context is required per protocol. The security context data MUST
be the same for each protocol within each proposal for a particular
SA payload. In other words, only one instance of a security context
is communicated for the proposed SA.
For Security Context Transform Type, the defined Transform IDs are:
Name Number
No Security Context 0
Security Context 1
RESERVED 2 - 65535
This transform requires a transform attribute to communicate the
security context data.
Latten, et al. Expires January 10, 2010 [Page 6]
Internet-Draft IKEv2SecurityContext July 2009
The Transform Attribute Type:
Attribute Type Value Attribute Format
.............................................................
Security context To be assigned by IANA TLV
The attribute format is Type/Length/Value allowing for a variable
length security context.
The security context data has the following format.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DOI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| security context (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Security Context Format
- DOI (4 octets) - the first 4 octets contains the security
context's domain of interpretation. This value must be
assigned by IANA.
The Domain of Interpretation indicates the meaning of
particular values within the security context for the MAC
implementation.
- security context (1 or more octets) - the DOI is followed by
one or more octets of security context data. IKE leaves
interpretation of the security context to the local MAC
policy.
4.1 Attribute Negotiation
An implementation of IKEv2 that supports labeled SAs MUST also
include a management facility that allows a user or system
administrator to specify the security context data for SPD and
manual SA entries.
The security context data includes the security context and the
security context's DOI. The DOI aids the MAC layer in interpreting
the security context. For example, if two systems are running
different versions of the same MAC, the DOI can indicate to each MAC
how to interpret the differences. How this is done is left to the
MAC implementation and not in the scope of this paper. IPsec just
needs to be able to indicate the DOI.
The security context DOI is entered along with the security context
in the SPD entries. Thus each labeled SPD includes a DOI. Each
Latten, et al. Expires January 10, 2010 [Page 7]
Internet-Draft IKEv2SecurityContext July 2009
labeled SA generated from a labeled SPD entry must contain a matching
DOI. In other words, the DOIs of the labeled SA and the labeled SPD
entry that created it, MUST match. Therefore assuring the security
contexts are understood between two systems.
An SPD entry containing an invalid DOI should fail to be included
into the SPD. How this failure is handled is left to the
implementation. The validity of the DOI is determined by the MAC
implementation. SPD entries with valid security context DOIs ensure
SAs with valid DOIs.
An initiating IKE communicates the security context data in the
security context transform. IKE does not interpret security contexts
so the responding IKE should accept the security context transform.
Because two communicating systems use the same security context
DOI in their SPD entries, the transform's DOI should match the
responder's corresponding SPD entry's DOI.
4.2 CREATE_CHILD_SA Exchange
[RFC4306] describes the NO_ADDITIONAL_SAS notification. This
notification is sent in response to a CREATE_CHILD_SA by a responder
who is unwilling to accept additional SAs on an IKE_SA.
Within labeled networking, each instance of a security context
requires an SA pair. There may be multiple SAs with the same
selector values except for the security context. A responder SHOULD
be willing to accept more than one SA on an IKE_SA when using
labeled IPsec.
5. Security Considerations
Security is central to IPsec and this document. Security
considerations permeate throughout. It is not this document's purpose
to define MAC networking but to describe the changes required to IKE
and IPsec to support the use of implicit labels on data
communications.
The addition of the security context transform should not change
the underlying security characteristics of IKE nor IPsec.
6. IANA Considerations
This document contains several numbers requiring assignment by IANA
which allocates and maintains the following IKE registries.
- IKEv2 Transform Types
- The Transform Type value for the security context.
Latten, et al. Expires January 10, 2010 [Page 8]
Internet-Draft IKEv2SecurityContext July 2009
Description Transform type
--------------------------------------------
Security Context To be assigned by IANA
- IKEv2 Transform Attribute Types
- The Security Context attribute type.
Attribute Type Value Attribute Format
------------------------------------------------------------
Security Context To be assigned by IANA TLV
- The security context's DOI. This requires IANA creating a
registry of DOI numbers to be consumed by a Domain of
Interpretation authority that will provide the mappings.
A range of these numbers should be reserved for private use.
7. Acknowledgements
The authors would like to thank Stephen Smalley and James Morris
for their contributions during the initial design; and the members
of the SELinux community who have contributed to the development
and improvement of labeled ipsec and this specification.
8. References
8.1 Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Level", BCP 14, RFC 2119, March 1997.
[RFC2401] Kent, S., Atkinson, R., Security Architecture for the
Internet Protocol, RFC 2401, November 1998.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4306] Kaufman, Ed., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
8.2 Informative References
[FIPS-188] National Institute of Standards and Technology,
"Standard Security Label for Information Transfer",
Federal Information Processing Standard (FIPS)
Publication 188, September 1994,
http://www.itl.nist.gov/fipspubs/fip188.htm
Latten, et al. Expires January 10, 2010 [Page 9]
Internet-Draft IKEv2SecurityContext July 2009
[MayMacCap] Mayer, F., Macmillan K., Caplan D., SELinux by Example,
Section 1.2.4, Prentice Hall, Upper Saddle River, NJ,
2007
[RFC1108] Kent, S., "U.S. DoD Security Options for the Internet
Protocol", RFC 1108, November 1991.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
December 2005.
[RFC4303] Kent, S. "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
Authors' Addresses
Joy Latten
email: latten@austin.ibm.com
George Wilson
email: gcwilson@us.ibm.com
Serge Hallyn
email: serue@us.ibm.com
Trent Jaeger
email: tjaeger@cse.psu.edu
Latten, et al. Expires January 10, 2010 [Page 10]
| PAFTECH AB 2003-2026 | 2026-04-24 02:54:47 |