IAM
====
Name:		Labeled IPsec phase 1
Submitter:	Bill Sommerfeld
Owner:		Kais Belgaied
Intern:		Mark Martin
Interest:	labeledipsec-core@sun.com
Status:		commitment scheduled 01/28/2009
Comment:         inception held 08/06/2008
Exposure:	open
Comment:	

SUMMARY
=======
The current labeled networking technologies in Trusted
Extensions assume that the underlying network will not
misroute or manipulate packets in flight between parties.
This project proposes to augment labeled networking to allow
IPsec to be used instead of or in addition to the existing
CIPSO security option, with the IPsec SADB augmented to
associate sensitivity labels with each security association.


ISSUES
=======
 

gw-10    How does this project support MAC for human readable labels
    (label_to_str() M_LABEL not M_INTERNAL)?
    At what label does ipseckey run?  Where is the global IKE
    configuration wire-label <label> stored (/etc/inet/ike/config)?
    What is its label?  What form do the in.iked debug message
    labels take?  How are they protected?

answer: all this code is global zone only; ipseckey and in.iked only
run in the global zone; the config file and debug logs live there as well.

gw-11    Bob Hagmann memorial question:
    What is the administrator experience?  How does administration of
    IPsec/IKE change with this project?

answer: will discuss in meeting

gw-12    5.2: "Precisely how the label is carried in this case is TBD, but ..."
    What's been determined?

answer: system will behave as it does in nevada today: there will be a
CIPSO label in the ip header which may (AH) or may not (ESP) be
integrity protected and which isn't confidentiality protected.
I'll fix the design doc.

gw-13    Release binding, 20Q1 says Patch, yet 20Q11 says SunOS 5.11

answer: this project is intended to be eligible for backport but the
project team has no plans at present to backport. 
gw-14    Is the interface table complete?
    Are the ike config file and PF_KEY extensions Committed?
    Are there other exported interfaces?

answer: Both interfaces were originally ARC'ed at Evolving and are in
the ON consolidation so as I understand it they were bumped to
Committed.

there is one more interface change: ipseckey has been extended to
allow labels to be associated with manually created security
associations.  this capability is mostly useful for testing/debug
purposes but for consistency with the rest of ipseckey would likely
best be considered Committed as well.

gw-99    If you care:
Mandatory Access Control (MAC)
   gww: A non-bypassable policy imposed by the TCB of access to objects
    by subjects based object and subject attributes whose values are
    not under the user's discretionary control.
    Resource limits are an example of non-sensitivity based MAC.
    In sensitivity (labeled) based systems the Bell-LaPadula
    model (simple security property and *-property), sensitivity labels
    and clearances are examples of object and subject attributes.

   ML-MRPP: A means of restricting access to objects based on subject
    and object sensitivity labels. The Bell LaPadula model is an example of
    Mandatory Access Control.

   TCSEC: A means of restricting access to objects based on the sensitivity
    (as represented by a label) of the information contained in the
    objects and the formal association (i.e., clearance) of subjects to
    access information of such sensitivity.

answer: thanks; will add this to the design review doc.

jdc-1    Should single-label really be the default on a TX system?  The
    default elsewhere in TX is label-aware, and you have to drive
    well out of your way to get unlabeled (single-label) behavior.

    I realize that this choice is consistent with existing IPsec
    behavior, but my understanding (from working on Rampart) was
    that unlabeled nodes were weird and special in a TX network.

answer: my understanding is that in practice TX systems often serve as
gateways between multiple single-label networks of label-unaware
systems, and that single-label systems in such networks vastly
outnumber multi-label systems.

that said, the single-label default was something of a design artifact
from the time when I thought I could get away without making tn*db
queries in in.iked.  Now that it is making those queries, it might
make sense to revisit this decision - defaulting to multi-label for
label-aware peers and single-label for label-unaware peers.

I'm open to a TCR here.

    If this hasn't yet been run by Jarrett Lu and Glenn Faden, it
    should be.

answer: both of them participated in the design review.

jdc-2    Some use-cases for the "wire-label" values would be helpful.

    It's not clear to me why labelling for IKE traffic and ESP/AH
    traffic are tied together.  (Are only a few combinations
    useful?)

answer: Unfortunately I don't have customer data on what combinations
will likely be useful in practice.

jdc-99    5.5.1 (nit): I think "unlabeled" versus "labeled" might be
    more familiar for TX users than "single-label" versus
    "multi-label."  Maybe more importantly, a host that handles
    labels explicitly needn't necessarily handle more than one.

answer: I'm torn.  I see your point about consistency but I find the
term "unlabeled" as inherently confusing and misleading.  Let's
discuss in the meeting.

ram-3: in 20Q, q17, you reference a open spec which to your knowledge no other
      implementation exists. Do you expect others to eventually participate?
     Do you know of any implementations contrary to the specification?

answer: that's unclear.  I think it's unlikely but it's hard to
predict the future.  I see a lot of energy around the type-enforcement
model in Flask (which is used by SELinux and which is being ported to
OpenSolaris as part of the FMAC project).

ram-4: In phase1-0.6.pdf, section 5.7 (packaging) you suggest a useful split of
      packages. Do you intend to do this?

answer: yes

ram-96: in phase1-0.6.pdf, page 2, section 2 (Use Cases), third paragraph,
   is "systemadministration" correct?

answer: typo; should be: "Note: two multi-label systems may be
configured to treat each other as single-label"

ram-97 in phase1-0.6.pdf, page 7, section  5.7 (Packaging), first paragraph,
      "Solaris" instead of "solaris".

answer: thanks

ram-98 Glossary was great help...thanks




 
 
VOTE
====
Approve - James Carlson, Kais Belgaied, Mark Carlson, 
Richard Matthews, Sebastien Roy,  Gary Winiger
Deny - 
Abstain - 
Not Participating (NP) - 



THE NEXT STEP
=============

Work with case owner/intern on TCRs, Spec update details.
Case is approved.