Subject: [secdir] Secdir review of draft-ietf-appsawg-received-state

From: Paul Hoffman <[email-masked]>
Date: Sun, 1 Jul 2012 15:07:43 -0700

I have reviewed this document as part of the Security Directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the Security ADs. Document editors and WG chairs should treat these comments just like any other last call comments.

This document defines the new "state" clause for trace header fields that are used in SMTP. The use of these clauses are optional, and are used to indicate that a message is entering processing queues such as for moderation or quarantine.

The Security Considerations section is quite short; basically, the section says "this might leak some local policy information" and "there are more security considerations for SMTP trace headers in the current SMTP spec". Because the new clause is completely optional, this adequately describes the relevant security issues.

--Paul Hoffman

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 2 Jul 2012 00:27:16 -0400

Hi Dan,
  Thanks a lot for your comments. Please find responses inline.

On 06/30/2012 01:49 PM, Dan Harkins wrote:
> 
>   Hello,
> 
>   I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG.  These comments were written primarily for the benefit of the
> security area directors.  Document editors and WG chairs should treat
> these comments just like any other last call comments.
> 
>   This draft defines a new destination option for IPv6 datagrams that
> tunnel router solicitation and router advertisement messages. The
> purpose of the option is to allow an edge router in a broadband
> subscriber network to identify a particular subscriber that comes up.
> 
>   I found the draft a bit confusing. Terms are referred to before they
> are defined and once defined are not consistently used. There were
> several paragraphs that I had to re-read a couple times to figure out
> what was being intended. I would suggest the following editorial
> changes:
>   - in section 1.1, move definition of GPON and RG up before they
>     are referred to (AN, and Edge Router, respectively)
>   - in section 5.3, pick either AN or "access node" and stick to it.
>      By sometimes referring to the entity by acronym and sometimes
>      by full name, the casual reader (me) does not immediately
>      tie them together and creates 2 entities in his mind as he's
>      putting the described behavior together.
>   - in section 6.2 it talks about creating a new IPv6 datagram, then
>      about adding the option to it and how to determine the contents
>      of this datagram, and then it says a new IPv6 datagram is created.
>      Wait, so there's 2 IPv6 datagrams or is this the same one? I had to
>      read this a few times to figure out what's going on.

Will make these changes.

> 
>   There is an apparent technical problem in section 7 where the new
> option is laid out. The option type is an octet and the option length
> is also an octet (whose length does not include the option type or
> itself). Then follows the a field for the length of the lineID and the
> lineID itself. But the length of the lineID is 2 octets implying that
> a lineID can be more than 255 octets long. How does this work? If
> the lineID itself is greater than 253 octets then the length required
> to be encoded in the option length would be greater than 255
> which cannot be described with a single octet.
> 
>   Either there is the possibility of a valid but unparsable option
> that would likely make the rest of the packet unparsable too
> (which is bad) or the lineID can never be greater than 253 octets
> which then makes me ask why the field to encode its length has to
> be 2 octets?

The LineIDLen is actually 8 bits like you suspected and there is an
error in the ascii art. I will fix this in the next rev.

> 
>   The other option is, of course, that I'm completely missing something.
> If that's the case, forgive my ignorance but please do enlighten me.
> 
>   I found no security issues with the draft that require the attention
> of the ADs. The Security Considerations mention that this is all
> unauthenticated and should only be used on a network where the
> communicating entities are already trusted, which seems reasonable
> for the way this will be deployed.

Great.

Thanks
Suresh

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 04 Jul 2012 22:04:22 +0100

I have reviewed this document as part of the Security Directorate's 
ongoing effort to review all IETF documents being processed by the IESG. 
These comments were written primarily for the benefit of the Security 
ADs. Document editors and WG chairs should treat these comments just 
like any other last call comments.

This document describes an information model for Kerberos version 5
from the point of view of an administrative service. This document
describes the services exposed by an administrative interface to a
KDC.

I believe the Security Consideration section correctly describes what 
kind of information needs protecting and how. It also talks about access 
controls and issues associated with exporting this information. I can't 
think of anything else that needs covering in the document.

I do however have a long list of nits and minor issues which I think 
need to be addressed:

In the Introduction: LDAP needs an Informative Reference.

In Section 1:

    Implementations of this document MUST be able to support default
    values for attributes as well as the ability to specify syntax for
    attribute values.

What does "the ability to specify syntax" means?

In Section 4.1.1.6 - What is the allowed range for "integer"?

In Section 4.1.1.13 - what is an enctype? :-). How do you represent one?

4.3.  Key

    Implementations of this model MUST NOT REQUIRE keys to be
    represented.

I don't know what this means.

4.3.1.2.  keyValue

    The binary representation of the key data.  This MUST be a single-
    valued octet string.

Can it be zero-length?

4.3.1.3.  keySaltValue

    The binary representation of the key salt.  This MUST be a single-
    valued octet string.

As above.

4.3.1.5.  keyNotUsedBefore

    This key MUST NOT be used before this date.  The syntax of the
    attribute MUST be semantically equivalent with the standard ISO date
    format.  This MUST be a single-valued attribute.

Is this the same format as RFC 3339? If not, why not (and what is the 
proper reference)? If yes, can you please change the definition to match 
other sections.

4.3.1.6.  keyNotUsedAfter

    This key MUST NOT be used after this date.  The syntax of the
    attribute MUST be semantically equivalent with the standard ISO date
    format.  This MUST be a single-valued attribute.

As above.

In Section 4.4.1.1: Normative References to documents defining OIDs, 
URIs (RFC 3986) and UUIDs are missing.

4.4.1.4.  policyUse

    This is an optional single enumerated string value used to describe
    the use of the policy.  Implementations SHOULD provide this attribute
    and MUST (if the attribute is implemented) describe the enumerated
    set of possible values.  The intent is that this attribute be useful
    in providing an initial context-based filtering.

I find this to be sufficiently vague to be pointless. Do you have some 
examples of what this value can be?

SOAP and Netconf (5.3/5.4) need Informative References.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 05 Jul 2012 00:17:52 -0400

> I do however have a long list of nits and minor issues which I think 

I think the majority of your comments can be addressed by noting that
this is an abstract data model, not a schema or protocol.  So, it
discusses values that must be representable, but not what the
representation must look like, because that's up to some schema or
protocol based on this data model (e.g. an LDAP schema or XML DTD).

I thought at this point that the introduction makes this point
reasonably clear, along with the notion that "implementations" of this
documents are schemas or protocols, not pieces of software.  However, if
you didn't pick up on that, then maybe there's a better way to get it
across.

Aside from those, you also pointed three specific issues (quoted below)
which I think are answered by text in RFC3961.  If that information is
sufficient to answer your questions, then appropriate references to that
document should be inserted in the text.  Otherwise, we'll have to talk
about what the document can say to be more clear.

> In Section 4.1.1.13 - what is an enctype? :-).

See RFC3961.

>     The binary representation of the key data.  This MUST be a single-

A valid question, I suppose.  But I don't see any point in saying,
because then someone will just follow up with a question asking whether
it is allowed to be length 1.

In fact, a key held by the KDC will be a valid key for the appropriate
enctype.  The set of valid keys is a property of the enctype, as
specified in RFC3961 section 3.

>     The binary representation of the key salt.  This MUST be a single-

RFC3961 is quite clear that any valid UTF-8 string is permissible as a
salt.

You also pointed out several missing references; I agree with all of
those.

Leif, can you make sure we get in whatever changes are needed to address
Alexey's comments?

-- Jeff

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 13 Jul 2012 20:00:33 +0100

> protocol based on this data model (e.g. an LDAP schema or XML DTD).

Not too abstract though. If you say something is an integer and one 
protocol can only support 32bit integers, while another can support 
128bit, one of them might be unusable unless your definition is more 
specific.

> you didn't pick up on that, then maybe there's a better way to get it

See above.

> about what the document can say to be more clear.

Having very specific references (to section numbers) is likely to solve 
issues, yes.

> specified in RFC3961 section 3.

Ok, a reference would do.

> You also pointed out several missing references; I agree with all of

Ok, good.