2nd internet draft for labeled ipsec based on IKEv2 and updated
IPSec Architecture, rfc 4301.
regards,
Joy
Network Working Group J. Latten
Internet-Draft G. Wilson
Intended Status: Standards Track S. Hallyn
Expires: ? IBM
T. Jaeger
Penn State
July 2008
Security Label Addendum to IPsec
draft-jml-ipsec-ikev2-security-label-00
Status of This Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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 December, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008)
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
Latten, et al. Expires ? [Page 1]
Internet-Draft IKEv2SecurityLabel June 2008
negotiation of the security label 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 context consisting of a sensitivity or security
level and category. This document will refer to the security level
and category as the security classiffication. In MLS, the use of a
security classification allowed segregation of information thus
facilitating data confidentiality.
MAC systems have become more mainstream and is no longer just
associated with MLS. Within a strictly hierarchical system such as
MLS, often there are tasks that need to be exempt from the MLS
policy, thus leaving them exposed. However, methods such as Type
Enforcement (TE) are not hierarchical and allow precise rules to
be written about access using security attributes [MayMacCap]. TE can
be used to control access these "exempt" tasks. A MAC system can
employ both MLS and TE to control access. Such systems require
additional security attributes besides the security classification
used by MLS. For example, a domain type attribute may be used to
control access in TE [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 when
communicating with homogenous systems.
Techniques such as IP Security Options (IPSO) allow IP datagrams to
be labeled with a MLS security classification [RFC1108]. However,
they do not accomodate additional security attributes such as the
type in TE. MAC implementations requiring additional security
attributes, such as SELinux, can use IPsec mechanisms to control
access [LevIPsecMAC].
This document will describe how IPsec mechanisms can support
MAC networking. It will also describe the additions to IKEv2 to
support communication of a security context during negotiations to
Latten, et al. Expires ? [Page 2]
Internet-Draft IKEv2SecurityLabel June 2008
establish an AH and ESP security association.
Within this document, security label and security context refer to
the same thing. And MAC networking and labeled networking are
used interchangeably.
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
exported over the network. The MAC system can then use labeled
networking to make informed access decisions. Systems wishing to
communicate with each other must deploy the same MAC authorization
policy and security context for consistency.
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 label 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 provides implicit
labeling in that the security context is part of the IPsec Security
Association and not transmitted with each packet.
3.1 Relationship Between a Security Association and Security Label
In MAC networking, the traffic between two systems may require
several different security contexts. For example, ftp and a mail
program 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 label will require an SA pair. Thus
traffic between two systems may have several SA pairs with identical
selectors except for the security context. If using a combination of
Latten, et al. Expires ? [Page 3]
Internet-Draft IKEv2SecurityLabel June 2008
ESP and AH, then there will be an ESP SA pair and an AH SA pair per
instance of a security label.
3.2 Security Context Selector
[RFC4301] describes the Security Policy Database (SPD), and the
Security Association Database (SAD) and corresponding selectors.
MAC networking introduces an additional selector, the Security
Context selector. This selector is only required when MAC
networking is deployed.
- Security Context: MAC implementation's security context.
The security context can be an IPSO/CIPSO label when
IPsec is used to support explicit labels.
Recall, in MAC networking, multiple SAs may exist between two
systems differing only in their security labels. The Security Context
selector ensures that the appropriate SA pair is used to secure a
particular communication.
The Security Context selector within the SPD allows the system
administrator to specify which traffic streams will be authorized
to communicate within the system's MAC policy. It also specifies
which traffic streams will have labeled communications and which
will not.
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.
In MAC implementations, the security context that will be associated
with the new SA MUST NOT be the SPD entry's security context. The
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 can also indicate the security attributes of the
sender or process. Keeping these separate allows a MAC implementation
to control which packets may use a particular IPsec configuration.
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.
Latten, et al. Expires ? [Page 4]
Internet-Draft IKEv2SecurityLabel June 2008
3.4 Outbound Processing for MAC Networking
When consulting the SPD for an outbound policy, the data's security
label is used to determine if it is authorized to access the
particular SPD entry and use its configuration information for
sending. This adds the additional check in that the outbound packet
will not generate an SA pair that the policy entry does not allow.
So for example, in an MLS implementation, a high secrecy process
cannot generate an SA allowing it to send data to a low secrecy
process.
Similarly, when consulting the SAD to find an outbound SA, the
the data's security context is used to select the appropriate SA to
send on.
In the case that a suitable outbound policy is found, but there isn't
an SA, the message sent to the key management system to create an SA
MUST contain the security label associated with the data. This allows
for the key manager to create an SA pair with the correct security
label for the data to be transmitted.
A MAC implementation MAY label it's interface and/or configured IP
address. If so, before forwarding the packet out to its destination,
a check should be made that the outbound packet is authorized to
send out on the interface and/or configured ip address [RFC2401].
3.4 Inbound Processing for MAC Networking
The use of the SPI to map IPsec protected packets to an SA ensures
we select the correct SA to process the inbound packet.
The MAC implementation MUST retain the binding between the data
received in the IPsec protected packet and the security label in
the SA used to process the packet. This is required so that
suitable MAC policy decisions can be made when delivering the data
to an application or when fowarding. The means for maintaining this
binding are implementation specific. [RFC2401]
A MAC implementation MAY label it's interface or configured IP
address. If so, the MAC implementation SHOULD check the inbound
packet's security label (as defined by the SA used to process the
packet) with the security label of the interface or configured IP
address before forwarding to upper-layer protocol or to
destination [RFC2401].
3.5 MAC Processing for Security Gateways
A security gateway enforcing MAC and using labeled SAs MUST follow
Latten, et al. Expires ? [Page 5]
Internet-Draft IKEv2SecurityLabel June 2008
the inbound and outbound processing mentioned above as well as some
additional processing particular to the intermediate protection of
packets in a MAC environment [RFC2401].
A security gateway enforcing MAC MUST create and use appropriate
SAs to protect packets that it forwards for systems behind it.
[RFC2401] The systems behind the security gateway may or may not be
using MAC. The gateway SHOULD utilize various attributes of the
traffic and/or existing labels to determine the security labels for
the SAs to be created and applied.
Similarly, such a gateway SHOULD accept and process inbound AH
and/or ESP packets and forward appropriately, utilizing various
attributes of the traffic and/or existing labels [RFC2401].
4. Security Context Transform
When the initiator requests a new SA to be created, the
security context is communicated in the information required for
the new IPsec SA. Security contexts are not communicated for IKE_SAs,
only IPsec SAs.
The following transform definition is used to communicate a security
context when creating the CHILD_SA in the IKE_AUTH exchange or when
creating or rekeying an IPsec SA in the CREATE_CHILD_SA exchange.
The transform type value is:
Description Transform Type Used In
.................................................
Security Context (?)6 ESP and AH
When using IPsec's implicit labelin, the existence of a security
context for the SPD entry indicates all SAs created by this entry
MUST be labeled. If an SPD entry does not have a security context,
then resulting SAs will not have a security context. Within MAC
it may be desireable that some network communications not be labeled
and just protected by IPsec. For example, a security gateway
enforcing MAC but the systems behind it do not. These SPD entries
would not have a security context. However, when the security
gateway talks to another security gateway, it may want to use
implicit labeling. Therefore, the use of a security context with
the ESP and AH protocols when MAC is enforced is optional.
Only one transform of type (?)6 is allowed per protocol. In other
words, you cannot communicate two different security contexts within
a single SA payload being negotiated.
Latten, et al. Expires ? [Page 6]
Internet-Draft IKEv2SecurityLabel June 2008
For Transform Type (?)6 (Security Context), the defined Transform IDs
are:
Security Mechanism Number
...........................................
Reserved 0
SELinux (?)1
Smack (?)2
Reserved to IANA (?)3 - 1023
Private Use 1024 - 65535
The Transform Attribute Type:
Attribute Type Value Attribute Format
.......................................................
Security Context (?)18 TLV
The attribute format is Type/Length/Value allowing for a variable
length security context.
The security context 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 length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Security Context Format
- doi (1 octet) - The first octet contains the security label's
domain of interpretation.
The domain of interpretation can be viewed as a group of
systems that agree on the meaning of particular values within
the security label of a security mechanism.
Reserved 0
Default (?)1
Private Use (?)2 - 255
- security context (variable length number of octets)
The actual content will be dependent on the security mechanism
that is specified. Within IKE context, this is regarded as
an opaque bit string.
Latten, et al. Expires ? [Page 7]
Internet-Draft IKEv2SecurityLabel June 2008
4.1 Attribute Negotiation
The description of attribute negotiation in [RFC4306] is applicable
also when using security contexts. In addition, only one security
context transform (Type 6) is allowed per protocol. And if the
initiator sends multiple proposals when negotiating an SA, each
proposal MUST contain the same transform type and security context.
In other words, a single SA negotiation should contain only one
security context.
4.3 CREATE_CHILD_SA Exchange
[RFC4306] describes the NO_ADDITIONAL_SAS notification.
This notification is sent by a responder who is unwilling to accept
additional SAs on an IKE_SA or a minimal IPsec implementation.
Within MAC, the data transmitted between two systems may have
different security contexts. For example, ftp and telnet data may
each have their own security contexts. Each instance of a security
context requires an SA pair to support context granularity.
There may be multiple SAs with same selectors except for the
security context selector. A responder should be willing to accept
more than one SA on an IKE_SA in MAC networking.
4. Security Considerations
Some IPsec implementations may dynamically update the SPD.
If the responder does not have an SPD entry, the information within
the SA payload is used to generate an SPD entry.
MAC networking may impose limitations on IPsec implementations that
dynamically update the SPD. The security contexts associated with an
SPD entry and an SA are for different purposes as described
already in this document. Therefore, the security context in the
SA should not be used as the security context for the SPD entry.
IPsec implementations that generate SPD entries during SA
negotiation and wish to enforce labeled networking will require a
mechanism for system administrators to specify the security context
to be used for these SPD entries.
Latten, et al. Expires ? [Page 8]
Internet-Draft IKEv2SecurityLabel June 2008
5. IANA Considerations
This document contains several new numbers which are allocated
and maintained by the IANA registry.
- The Transform Type value for the security context.
Description Transform type
-----------------------------------------
Security Context (?)6
- The Transform IDs defined within the Security Context Transform
Type.
Name Number
---------------------------
Reserved 0
SELinux (?)1
Smack (?)2
Reserved to IANA (?)3 - 1023
Private Use 1024 - 65535
Additional values may be assigned by IANA for the security
mechanisms requiring IKE to communicate its security label.
- The Security Context attribute type.
Attribute Type Value Attribute Format
-----------------------------------------------------
Security Context (?)18 TLV
6. 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.
7. References
7.1 Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Level", BCP 14, RFC 2119, March 1997.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
Latten, et al. Expires ? [Page 9]
Internet-Draft IKEv2SecurityLabel June 2008
[RFC4306] Kaufman, Ed., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
7.2 Informative References
[LevIPsecMAC]
Jaeger, T., King, David., Butler, K., Hallyn, S.,
Latten, J., Zhang, X., "Leveraging IPsec for Mandatory
Per-Packet Access Control", 2006
http://www.cse.psu.edu/~tjaeger/papers/securecomm06.pdf
[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.
[RFC2401] Kent, S., Atkinson, R., Security Architecture for the
Internet Protocol, RFC 2401, November 1998.
[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
IBM
email: latten@xxxxxxxxxxxxxx
George Wilson
IBM
email: gcwilson@xxxxxxxxxx
Serge Hallyn
IBM
email: serue@xxxxxxxxxx
Trent Jaeger
Penn State
email: tjaeger@xxxxxxxxxxx
Latten, et al. Expires ? [Page 10]
Internet-Draft IKEv2SecurityLabel June 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights 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; nor does it
represent that it has made any independent effort to identify any
such rights. Information on the procedures with respect to rights
in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required
to implement this standard. Please address the information to the
IETF at ietf-ipr@xxxxxxxxx
Latten, et al. Expires ? [Page 11]
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.
