Summary: Has a DISCUSS. Has enough positions to pass once DISCUSS positions are resolved.
Comments from mehmet during the ops dir review.
** The document lacks an IANA Considerations section.
http://www.ietf.org/id-info/checklist#anchor4 says: “If there is no action for
IANA, the section should say that, e.g., including something like "This
document has no actions for IANA."
== Outdated reference: A later version (-20) exists of
1) There's some SHOULDs in s3.2 that I'm not sure I follow:
MAC security labels and any related security state SHOULD always be
protected by these security services when transferred over the
network; as SHOULD the binding of labels and state to associated
objects and subjects.
If a system doesn't provide the services to keep the binding between the label
and the object or the user's identity and it's privileges how are you going to
get MAC to work?
2) s3.3: I think it's noble that clients reject anything it doesn't understand,
but I gotta admit that if I was a bad guy I'd kind of ignore that requirement
and keep on accepting whatever data I wasn't supposed to get. Would a better
requirement be to check that before allowing access a common policy MUST be
negotiated? Oh wait that's in s3.4 - should the concept of before allowing
access be worked in to s3.4?
3) s3.5: I don't follow why this isn't a MUST:
The server is allowed to translate the label but SHOULD NOT change
the semantic meaning of the label.
If the server changes the semantic meaning of the label will the client still
know what it means and then doesn't that conflict with an earlier requirement:
a security label MUST always mean
exactly the same thing on every system.
Doesn't it have to be "MUST NOT change the semantic meaning of the label"?
0) Note RFC 4949 has a definition for MAC that you might refer to.
1) In s3.1, there is a discussion about the security attribute of the subject.
Isn't this more commonly referred to as the client's privileges? And it might
make sense to add this to the Definitions section.
2) s3.1 #4: Ever heard of a SPIF or looked at ISO 15816? The were attempts to
do just that.
3) s4: Reads a little awkward:
Labeled NFS SHOULD support that the following security services are
provided for all NFSv4.2 messaging. These services may be provided
by lower layers even if NFS has to be aware of and leverage them:
Labeled NFS or the underlying system on which the Labeled NFS operates
SHOULD provide the following security services for all
4) s3.2: Could you better define strong mutual authentication - is that
certificate-based mutual authentication? Or is it that MD5-based security
shouldn't be used ;)
Also: r/will be required/is required
5) s3.3: Instead of:
MAC models base access decisions on security attributes bound to
subjects and objects.
I would have said:
MAC models base access decisions on security attributes and privileges
bound to objects and subjects, respectively.
6) s3.3: I'd probably add the following to the end of this sentence:
With a given MAC model, all systems have
semantically coherent labeling - a security label MUST always mean
exactly the same thing on every system.
because otherwise the label cannot be properly interpreted.
7) s3.3: What does the "this" in this sentence refer to the binding of stuff to
objects/subjects or to having labels mean the same thing:
While this may not be
necessary for simple MAC models it is recommended that most label
formats assigned an LFS incorporate this concept into their label
8) (no action required) s3.3: I think you're more likely to get weighed down by
corner cases than a global scheme :)
- general: some systems have a requirement that some
labels are visible in clear, whereas others are
encrypted, when passed over the network at least. Is
that a requirement you want to impose/meet here? Either
way, it might be good to say.
- 3.2: s/Privacy/Confidentiality/ would be better here
- 4.3: the term foreign label is not used in 3.3
- 5.3: Whis is a US-specific section included here?
Surely this ought be more international? This section
should really be generalised or deleted.
- 5.4: You could explain what "legal hold" means. I
assume its where someone is suing someone and a court
says "don't you go changing X" - is that right?
The case is well made without cases
5.3. International Traffic in Arms Regulations (ITAR) . . . . . 12
5.4. Legal Hold/eDiscovery . . . . . . . . . . . . . . . . . . 13
Traditionally the IETF stays well away from such areas, are we sure we want to
make any comment on them in this text?