Subject: [IPsec] IPsec Security Context drafts

From: Joy Latten <[email-masked]>
Date: Mon, 12 Jan 2009 13:59:57 -0600

The following IPsec Security Context drafts were announced last week.  

We would appreciate any comments, suggestions or reviews. 

Thanks!!

regards,
Joy

http://www.ietf.org/internet-drafts/draft-jml-ipsec-ikev2-security-context-00.txt

Filename:        draft-jml-ipsec-ikev2-security-context
Revision:        00
Title:           Security Context Addendum to IPsec
Creation_date:   2009-01-08
WG ID:           Independent Submission
Number_of_pages: 12

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.

http://www.ietf.org/internet-drafts/draft-jml-ipsec-ikev1-security-context-00.txt

Filename:        draft-jml-ipsec-ikev1-security-context
Revision:        00
Title:           draft-jml-ipsec-ikev1-security-context-00
Creation_date:   2009-01-08
WG ID:           Independent Submission
Number_of_pages: 8

Abstract:
This document describes the need for and use of a security context
within IPsec. It describes the extension to the Internet IP Security
Domain of Interpretation (IPsec DOI) [RFC2407] for the Internet
Security Association and Key Management Protocol (ISAKMP) [RFC2408].
This extension supports the negotiation of the security context for a
particular IP Authentication Header (AH) [RFC4302] or IP
Encapsulating Security Payload (ESP) [RFC4303] security association.
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Paul Moore <[email-masked]>
Date: Tue, 20 Jan 2009 17:58:08 -0500

> We would appreciate any comments, suggestions or reviews.

[NOTE: I've CC'd the SELinux mailing list since this draft was also 
announced there]

> WG ID:           Independent Submission

Hello,

I've only had a chance to read the IKEv2 version of the drafts but I 
believe that most of my comments apply to the IKEv1 version of the 
draft as well.  My comments are below, ordered by section:

 * Section 1 (Introduction)

- In paragraph two, second sentence it might be nice to mention that 
sensitivity levels are hierarchical and categories are not.

- In paragraph three you mention that domain type enforcement is not 
hierarchical but fail to explain how it differs from the MLS concept of 
categories which is also a non-hierarchical security attribute.

- In paragraph three you mention "exempt tasks" but it is not clear to 
me what you are referring to.

- In paragraph five you mention how RFC1108 when used in conjunction 
with FIPS-188 would enable additional security attributes (assumed to 
be DTE attributes), why is RFC1108 needed?  Why not just FIPS-188?

 * Section 3 (Labeled Networking)

- In paragraph two you only mention data export, text on data import is 
missing.

- In paragraph four and five you talk about using IPsec to protect both 
implicitly and explicitly labeled network traffic, it would be helpful 
if you could explain why implicit labeling is needed since the 
combination of IPsec and explicit labeling seems to address the issues 
you listed in section 1.

 * Section 3.1 (Relationship Between a Security Association ...)

- It would be nice to mention in this section how to deal the potential 
for packets employing both AH and ESP with differing security contexts.

 * Section 3.2 (Security Context Selector)

- In general I feel this section is not specific enough for 
implementation, e.g. in paragraph two how are traffic streams 
controlled via SPD security labels?

- In paragraph three you don't mention how the security label assigned 
to a newly SA is determined.

- In paragraph four you don't mention how the correct SA pair is 
determined.

 * Section 3.3 (Security Context Selector and PFP)

- In this section you never mention how a SA created via PFP would 
arrive at the correct security label.  In addition, while you describe 
SPD entries as "objects" from a security perspective it isn't clear if 
an SA's security label represents a "subject" or an "object".

 * Section 3.5 (Additional Outbound Processing)

- What happens when an SA doesn't exist?  Compare labeled versus 
unlabeled SPD entries and how a SA's security label is determined.

- How are errors (unknown DOI, invalid label, etc.) and denials (access 
not allowed per security policy) handled?  Is the sender notified, if 
so, how?  

 * Section 3.6 (MAC Processing for Security Gateways)

- In paragraph two you discuss the potential for forwarding packets with 
security attributes derived from either explicit labeling protocols, in 
this particular case how do you handle the traffic?  Specifically, what 
happens to the explicit labeling information?  What about security 
label translations?

- In paragraph three you mention how outgoing forwarded traffic should 
be labeled using explicit labeling or security attributes of the 
destination, how is this determined and managed?

- How are errors (unknown DOI, invalid label, etc.) and denials (access 
not allowed per security policy) handled?  Is the sender notified, if 
so, how?

 * Section 4 (Security Context Transform)

- I believe it should be a "MUST" that each SA in a bundle use the same 
security label.

- The term "doi" should be capitalized since it is an acronym.

- Is any part of the DOI space reserved for private use?

 * Section 4.1 (Attribute Negotiation)

- On systems that support multiple DOIs, how is a DOI selected for 
outbound traffic?

- More detail is needed on how the SA security label negotiation process 
works.

 * Section 4.3

- If a system's security policy for a given SPD entry only allows for a 
single SA with a specific security label, "MUST" is be willing to 
accept another SA?  Why and how?

-- 
paul moore
linux @ hp