[Isms] Status of IESG-review changes for draft-ietf-isms-dtls-tm
Wes Hardaker <wjhns1@hardakers.net> Wed, 05 May 2010 20:35 UTC
Return-Path: <wjhns1@hardakers.net>
X-Original-To: isms@core3.amsl.com
Delivered-To: isms@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27A333A6CA1; Wed, 5 May 2010 13:35:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.833
X-Spam-Level:
X-Spam-Status: No, score=-0.833 tagged_above=-999 required=5 tests=[AWL=-1.481, BAYES_40=-0.185, FM_ASCII_ART_SPACINGc=0.833]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DpUELta0AfXw; Wed, 5 May 2010 13:34:54 -0700 (PDT)
Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id BB5F83A6ABF; Wed, 5 May 2010 13:34:51 -0700 (PDT)
Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 28E73981F1; Wed, 5 May 2010 13:34:38 -0700 (PDT)
From: Wes Hardaker <wjhns1@hardakers.net>
To: isms@ietf.org
Organization: Sparta
Date: Wed, 05 May 2010 13:34:37 -0700
Message-ID: <sdaase140y.fsf@wjh.hardakers.net>
User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Cc: iesg@ietf.org
Subject: [Isms] Status of IESG-review changes for draft-ietf-isms-dtls-tm
X-BeenThere: isms@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/isms>, <mailto:isms-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/isms>
List-Post: <mailto:isms@ietf.org>
List-Help: <mailto:isms-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/isms>, <mailto:isms-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 May 2010 20:35:00 -0000
Enclosed is a very long document describing in detail exactly where all
the outstanding items are (in my view) with respect to the IESG member
comment and discuss topics.
I've updated my marking list a bit to reflect who's got the current ball
on a given topic. Responses from each person involved in the discussion
are prefixed with their name.
Outstanding marks I'm waiting actively to hear back on:
DISCUSS: The state is still considered in "discussion" (regardless of
whether it's an IESG DISCUSS or COMMENT)
Marks that I consider "will assume closed at some point if they don't
respond with additional problems based on the proposed resolution.
DONE: The suggestion/issue was acted on and the changes are described
WONTDO: Nothing was done; refer to the WH: response for reasons why
I'm proposing nothing be done.
ANSWERED: A question was answered but had no action resulting from it.
Marks that indicate formal closure because the commenting party has
indicated all is well for the given topic:
CLOSED: Affirmation has been received that the results are good.
(in some cases when a direct suggestion was followed
verbatim this mark was applied as a response really isn't needed)
Most of the CLOSED/DONE changes have been already placed in the updated
-11 document, though there are a few changes locally that were done
after -11 was published yesterday.
IESG DISCUSS and COMMENT Review
===============================
Date: 2010-05-05 13:23:35 PDT
Table of Contents
=================
1 David Harrington <ietfdbh@comcast.net> DISCUSS and COMMENTS
1.1 Discuss Items
1.1.1 3.1.1, 4. Per RFC3365 (BCP61),
1.1.2 4.1.1 "Enterprise configurations are encouraged"
1.1.3 4.4.1.1 3rd para., "the tmSecurityName is presented to the
1.1.4 5.1.1 "If demultiplexing ..." Should this be strengthened?
1.1.5 5.2 4) "an implementation SHOULD ... an implementation MAY
1.1.6 5.4 4) Why SHOULD instead of MUST? What circumstances make
1.1.7 6. The MIB is included in the document to make it
1.1.8 MIB related issues
1.1.9 SnmpTLSAddress - "This textual convention SHOULD NOT be used
1.1.10 Fingerprint - should this be SnmpTLSFingerprint, to be
1.1.11 SnmpTlstmCertSANDNSName - will the requirement to use
1.1.12 SnmpTlstmCertSANiPAddress - the IPv6 support for this
1.1.13 snmpTlstmCertToTSNTable - "... then additional rows MUST
1.1.14 snmpTlstmCertToTSNTable and snmpTlstmCertToTSNMapType - It
1.1.15 snmpTlstmCertToTSNTable - the example text in the paragraph
1.1.16 snmpTlstmCertToTSNTable - Commonname field is
1.1.17 snmpTlstmCertToTSNData - what is this? there is no
1.1.18 8.1 "Implementations SHOULD limit the lifetime ..." Can you
1.1.19 8.3 I found this difficult to understand. The "default
1.1.20 9.2 I think this section does not describe the implications
1.1.21 10 IANA Considerations:
1.2 Comments:
1.2.1 section 1: s/standard defined/specification/
1.2.2 section 3: ist paragraph, second sentence - I had trouble
1.2.3 3.1.2 last sentence, s/should/SHOULD/
1.2.4 4.1.0 s/are are/are/
1.2.5 4.3.1 s/Outgoing message field/Outgoing message/
1.2.6 4.3.2 s/Incoming message field/Incoming message/
1.2.7 4.3.1 tmState (first usage - a reference?)
1.2.8 4.3.2 incomingMessage: I found this sentence hard to
1.2.9 4.4.1.1 s/through an TLSTM session/through a single TSLTM
1.2.10 SnmpTLSAddress - references rfc3986 and 5246 are never
1.2.11 snmpTlstmCertToTSNTable - instead of an example of
1.2.12 11. s/defined by David Harrington/documented by David Harrington/
1.2.13 The Appendix is too verbose
2 Dan Romascanu <dromasca@avaya.com> DISCUSS from IESG
2.1 Discuss Items:
2.1.1 1. There are a number of objects in the MIB module with a
2.1.2 2. I could not make sense what section 9.2 tries to
2.1.3 3. I know that the paragraph starting with 'Further,
2.2 Comments:
2.2.1 1. For consistency purposes (as TLS is expanded) expand
2.2.2 2. In a couple of places (section 1, section 9.1) I
2.2.3 3. In Section 3.3
2.2.4 4. In Section 4.1
2.2.5 5. In Section 5.2 5b) s/If there is not a corresponding
2.2.6 6. In Section 5.4.4
2.2.7 7. Some of the references in the MIB module are not
3 Alexey Melnikov <alexey.melnikov@isode.com>:
3.1 Discuss:
3.1.1 1) In Section 7:
3.1.2 2) In Section 7:
3.1.3 3) In Section 7:
3.1.4 4) In Section 7:
3.1.5 5).
3.2 Comment:
3.2.1 In Section 3.1.2, the last sentence of the last paragraph:
3.2.2 3.1.3. (D)TLS Connections
3.2.3 In Section 5.1.1:
3.2.4 In Section 7:
3.2.5 Also in Section 7:
3.2.6 8.1. Sessions
4 Peter Saint-Andre <stpeter@stpeter.im>
4.1 Discuss:
4.1.1 The definition of snmpTlstmCertSANIpAddress mentions that
4.1.2 The definition of SnmpTLSAddress states that
4.2 Comment:
4.2.1 Section 1.1 has:
4.2.2 I realize that RFC 3411 talks about "privacy", but the
4.2.3 Forgive my ignorance regarding SNMP/SMI, but I can't seem
4.2.4 The definition of snmpTlstmCertSANDNSName mentions
4.2.5 Is there any provision for supporting subjectAltName
4.2.6 Is there a preferred order of matching subjectAltName
4.2.7 How exactly does an entity prepare for matching of
4.2.8 It might be appropriate for this specification to say
5 Tim Polk <tim.polk@nist.gov>
5.1 RFC 5590 states:
5.2 The document requires use of TLS, and mandates
1 David Harrington <ietfdbh@comcast.net> DISCUSS and COMMENTS
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1.1 Discuss Items
=======================
1.1.1 CLOSED 3.1.1, 4. Per RFC3365 (BCP61),
--------------------------------------------
However security must be a MUST IMPLEMENT so that end users will have
the option of enabling it when the situation calls for it.
OLD:
"A TLS Transport Model implementation SHOULD support message
encryption to protect sensitive data from eavesdropping
attacks."
NEW:
"A TLS Transport Model implementation MUST support message
encryption to allow users to protect sensitive data from
eavesdropping attacks."
+ WH: I'm actually fine with this, and someone else had a
similar comment. But the original USM had a goal of not
requiring encryption and thus I tried to carry that forward.
I'll change it to a "MUST support" but I'll note that you
referenced RFC3365, but actually RFC3365 specifically says you
don't need to necessarily require encryption if it's not
needed and I can envision SNMP implementations that don't need
encryption for the data the CR or NG may be distributing.
I.E., SNMP certainly can carry sensitive information that
should not be disclosed, but I don't know that we require all
usages of the protocol to carry such information. Certainly
most probably do, however.
+ WH: Never heard directly back, but since I took his text I'm
assuming this is resolved.
1.1.2 DONE 4.1.1 "Enterprise configurations are encouraged"
------------------------------------------------------------
Why enterprises specifically? This purpose of this text is to
encourage the use of subjectAltName in preference to other
alterantives, right? Could this be strengthened to a SHOULD or
RECOMMENDED to promote a common interoperable configuration?
+ WH: Enterprise wasn't the right word, you're right. I've
changed the text to:
Deployments SHOULD map the "subjectAltName" component of
X.509 certificates to the TLSTM specific tmSecurityNames.
1.1.3 DONE 4.4.1.1 3rd para., "the tmSecurityName is presented to the
----------------------------------------------------------------------
TLS Transport Model by the application" is inaccurate;
securityName (possibly from snmpTargetParamsSecurityname) is
presented by the application to the Security Model, which
transforms the securityName into a tmSecurityname. An
application should have no access to tmState.
I am a bit uneasy with the wording that says "The securityName
MAY be derived ... and MAY be used ..." This looks like it is
making the behavior optional. I recommend "Transport-model-aware
security models derive tmSecurityName from a securityName,
possibly configured in MIB modules for notifications and access
controls. Transport models SHOULD use predictable
tmSecurityNames ..."; I debated whether this should be a comment
or a DISCUSS, but decided on DISCUSS because I think it is
important to make clear the "MAY" behavior is well-specified in
models designed for interoperability.
+ WH: All of the above text is functionally a copy with slight
modifications (SSH -> TLS) from section 4.1.1 of RFC5592,
which you authored. I find it amusing that you're marking the
text you wrote in 5592 as a DISCUSS!
More seriously, I think cleaning up the text is fine. In
general I tried to copy text from 5592 for consistency between
the documents.
How about this (your text was used for the second paragraph):
<t>
On the (D)TLS client side of a connection the
tmSecurityName is presented to the TLS Transport Model
by the Security Model. The Security Model likely
derived the tmSecurityName from the securityName
presented to the Security Model by the application
(possibly because of configuration specified in the
SNMP-TARGET-MIB).
</t>
<t>
Transport-model-aware security models derive
tmSecurityName from a securityName, possibly configured
in MIB modules for notifications and access controls.
Transport Models SHOULD use predictable tmSecurityNames
so operators will know what to use when configuring MIB
modules that use securityNames derived from
tmSecurityNames. The TLSTM generates predictable
tmSecurityNames based on the configuration found in the
SNMP-TLS-TM-MIB's snmpTlstmCertToTSNTable and relies on
the network operators to have configured this table
appropriately.
</t>
1.1.4 WONTDO 5.1.1 "If demultiplexing ..." Should this be strengthened?
------------------------------------------------------------------------
"MUST implement if DTLS implementation does not provide. If the
implementation is, say, a toolkit, and it is unknown whether the
DTLS implementation it will be used with does provide
demultiplexing, then it is MUST implement, but the
demultiplexing function in the implementation SHOULD be able to
be bypassed by a subsequent implementer if the DTLS provides
demultiplexing."
+ WH: I don't think that it's appropriate for us to dive into
the various different ways that a SNMP implementation may need
to get involved with a TLS implementation. I think that's way
too deep to be recommending things. All we should be saying
is that if you're going the route of doing it in the SNMP
stack, use these steps. I don't think it's appropriate for us
to dictate how they make the decision about where to put the
demultiplexing as it may depend on many stack issues that we
can't possibly enumerate or predict.
1.1.5 ANSWERED 5.2 4) "an implementation SHOULD ... an implementation MAY
--------------------------------------------------------------------------
return a snmpTlstmSessionNoSessions" - when is it appropriate to
not follow the SHOULD? Why do we need the extra complexity of
this option? Why not just make it a MUST so all implementatioins
behave in the same way?
+ WH: I believe there may be implementations where internally to
that particular point in the code it may not be possible to
open a new transport connection. Specifically, I'm not
positive it's safe to assume that a connection can be opened
that can modify or access connection parameters that may be
stored in a data structure higher up in the calling stack that
isn't accessible in the lower-level code that is actually
trying to send out an outgoing packet.
I know in Net-SNMP this actually looked like it might be a
problem, in fact, given the currently defined (and published
and thus non-modifiable) API. We've actually worked around it
but I'm not sure every stack could. It all depends on how the
API works between the various levels of stack. It becomes
rather implementation dependent as to whether you can open a
new connection when you've noticed that an existing one is no
longer usable.
1.1.6 DONE 5.4 4) Why SHOULD instead of MUST? What circumstances make
----------------------------------------------------------------------
this acceptable? Why not make the behavior consistent across
implementations with a MUST?
+ WH: I was worried there would be cases where it wouldn't be
possible. But since I can't think any, I'll assume that there
aren't any. I've changed it to a MUST. Turns out RFC5246
actually indicates a MUST as well.
1.1.7 DONE 6. The MIB is included in the document to make it
-------------------------------------------------------------
SNMP-manageable, but then there are places, like 6.3, that say
"can be used"; Is the MIB mandatory-to-implement for compliance?
It doesn't seem to say that explicitly. I recommend tightening
the text that says things like implementers "can".
+ WH: The "can" was meant to indicate that a management station
"can" use them, but you're right the wording isn't clear in
that regard. I've reworded to:
The SNMP-TLS-TM-MIB defines counters that provide network
management stations with information about session usage and
potential errors that a MIB-instrumented device may be
experiencing.
1.1.8 TODO MIB related issues
------------------------------
1.1.9 WONTDO SnmpTLSAddress - "This textual convention SHOULD NOT be used
--------------------------------------------------------------------------
directly in object definitions since it restricts addresses to a
specific format. However, if it is used it MAY be used either on
its own or ..." I'm a MIB Doctor and I don't understand what
this is talking about. I could not provide advice to an
implementer or future MIB writer interpreting this text. I don't
understand why a textual convention that restricts the format
SHOULD NOT be used - isn't that the purpose of a TC - to refine
the semantics and/or the format? And if it is SHOULD NOT, why do
we follow that with a MAY that really doesn't discuss the
circumstances when ignoring the SHOULD NOT is appropriate.
+ WH: That's another example of text that comes directly from
the text you wrote in RFC5592 with no modifications at all.
Looking further, though, I find that you copied it directly
from the objects in the TRANSPORT-ADDRESS-MIB.
I believe the goal of the wording was to say that the address
TCs should not be used directly in a MIB but instead a pair of
generic TDomain and the generic TAddress objects should be
used instead.
IE, don't do this:
snmpFooBarAddress OBJECT-TYPE
SYNTAX SnmpTLSAddress
but instead do:
snmpFooBarDomain OBJECT-TYPE
SYNTAX TDomain
snmpFooBarAddress OBJECT-TYPE
SYNTAX TAddress
So... I'm not sure what to do with this. I'm going to mark
it as WONTDO unless you come up with text you'd like to
replace it with. Sound good?
1.1.10 CLOSED Fingerprint - should this be SnmpTLSFingerprint, to be
---------------------------------------------------------------------
consistent with RFC4181 naming conventions?
+ WH: The object was originally designed to be used
generically but was then later TLSized but the name was
never made specific again. Changed.
+ WH: Never heard directly back, but since I took his text I'm
assuming this is resolved.
1.1.11 ANSWERED SnmpTlstmCertSANDNSName - will the requirement to use
----------------------------------------------------------------------
lowercase be problematic re: newPrep?
+ WH: the subjectAltName dNSName is defined to be case-insensitive
so you must compare it in a case insensitive way thus we
need to deal with it on the mapping side to ensure that no
matter what case mix is put into the certificate value it
maps to the same securityName
+ Alexey Melnikov <alexey.melnikov@isode.com>:
Hi David,
I am agreeing with many of the points you raised in your DISCUSS, but
I would like to comment on one which I think it incorrect:
David Harrington wrote:
>SnmpTlstmCertSANDNSName - will the requirement to use lowercase be problematic re: newPrep?
>
>
The document defines snmpTlstmCertSANDNSName as:
snmpTlstmCertSANDNSName OBJECT-IDENTITY
STATUS current
DESCRIPTION "Maps a subjectAltName's dNSName to a
tmSecurityName after first converting it to all
lower case."
::= { snmpTlstmCertToTSNMIdentities 3 }
Due to character restriction on subjectAltName's dNSName, it can't
contain Internationalized (non-US-ASCII) domains. So this is not an
issue.
1.1.12 CLOSED SnmpTlstmCertSANiPAddress - the IPv6 support for this
--------------------------------------------------------------------
object and the TSM prefix feature are impossible to use together
in combination with the mandatory-to-implement VACM. Yet no
recommendation is made about which is the feature to be
preferred, or how to make such a decision. If I remember
correctly, the enable/disable for the TSM prefix feature would
apply to ALL transport models, not just TLSTM. I think there
should be text, probably in the Security Considerations or
Operations Considerations that discuss the implications and
tradeoffs for SNMP security if the ipAddress field is used in an
IPv6 environment, or the prefix feature is disabled to permit
IPv6 ipAddress field authentication, and what to watch for in
terms of VACM errors if both ipAddress authentication and TSM
prefixing are enabled.
+ WH: How about something like the following new section in
the operational considerations:
8.5. IPv6 and securityName mapping when used with TSM and VACM
It is possible to create a condition where it is
impossible to map a subjectAltName to a securityName when
all of the following conditions are true:
o The snmpTlstmCertToTSNMapType object of a
snmpTlstmCertToTSNEntry is set to the
snmpTlstmCertSANIpAddress identity value.
o The X.509 certificate presented by the client contains a
subjectAltName with an IPv6 address in it.
o The security model in use is the Transport Security Model.
o The snmpTsmConfigurationUsePrefix object in the SNMP-TSM-MIB is
set to 'true'.
o The View-based Access Control Model is being used to authorize
requests.
If all of these conditions are true then the length of
the generated tmSecurityName will always be 32 octet
characters and the securityName generated by the TSM will
be at least 36, which is longer than the length allowed
by the VACM.
Thus, the use of IPv6 subjectAltName to tmSecurityName
mapping is NOT RECOMMENDED when
snmpTsmConfigurationUsePrefix is set to true.
+ David H: I recommend something a bit more succinct than
your proposed section 8.5:
"The standard VACM access control model constrains
securityNames to be 32 octets or less in length. A TLSTM
generated tmSecurityName, possibly in combination with a
messaging or security model that increases the length of
the securityName, might cause the securityName length to
exceed 32 octets. For example, a 32 octet tmSecurityName
derived from an IPv6 address, paired with a TSM prefix,
will generate a 36 octet securityName. Such a
securityName will not be able to be used with standard
VACM or TARGET MIB modules. Operators should be careful
to select algorithms and subjectAltNames to avoid this
situation."
This might be best in section 4.1 where there is already a
discussion of generation of tmSecurityName and subsequent
mapping into securityName used in MIB modules. I recommend
placing such advice after the paragraph that starts "This
tmSecurityName may be later translated".
This would satisfy my concerns. (Your original text made it seem like
the easy solution was to not use VACM.)
Does this work for you?
+ WH: I think that's fine too and have done as you've
described.
+ WH: Never heard directly back, but since I took his text I'm
assuming this is resolved.
1.1.13 DONE snmpTlstmCertToTSNTable - "... then additional rows MUST
---------------------------------------------------------------------
be searched ..." I think SecCons [Ed: security considerations]
should discuss whether this could be used by DoS attacks.
+ WH: I added the following sentence to the security
consideration section that discusses the
snmpTlstmCertToTSNTable:
When this table contains a significant number of rows it
may affect the system performance when accepting new
(D)TLS connections.
Note that I suspect it'd take a lot of rows to check before
it would surpass the length of time it takes to verify the
certificate cryptographically.
1.1.14 DONE snmpTlstmCertToTSNTable and snmpTlstmCertToTSNMapType - It
-----------------------------------------------------------------------
is unclear what the next steps are if a) an entry is found that
violates the VACM length requirement, and b) no other matching
entry is found.
+ WH: I've addressed this with a few changes:
1. Modification to the "accepting a session" section text so
the new sentence reads:
If the session can not be opened for any reason at all,
including cryptographic verification failures +++and
snmpTlstmCertToTSNTable lookup failures+++, then the
snmpTlstmSessionOpenErrors counter is incremented and
processing stops.
2. In the snmpTlstmCertToTSNTable text a new paragraph was
added (after the "once a matching row has been found"
paragraph):
If no matching and valid row can be found, the
connection MUST be closed and SNMP messages MUST NOT be
accepted over it.
(the previous paragraph already discusses that VACM
requirements may dictate that future rows are searched).
1.1.15 DONE snmpTlstmCertToTSNTable - the example text in the paragraph
------------------------------------------------------------------------
"Missing values ..." is unclear and ambiguous. "may legally
contain only two rows" makes it seem that the table MUST have
two and only two rows. Persoanlly, I don't think readers need an
example with two non-consecutive indices; that's normal SNMP.
+ WH: This is a duplicate of your other comment below in your
"comments" section. The text was revised based on your
suggestions below, so I'll refer you to those and if you
have further issues here that aren't addressed by the other
changes please let me know.
1.1.16 ANSWERED snmpTlstmCertToTSNTable - Commonname field is
--------------------------------------------------------------
deprecated. Should we be writing support for it into new
standards?
+ WH: Deprecated but still in very very very heavy use. In
fact (IMO), it's still the most commonly used form of
identifying the subject of a certificate. Yes we hope to
have subjectAltName's take over most of that role but until
it does we need to support using those certificates.
1.1.17 DISCUSS snmpTlstmCertToTSNData - what is this? there is no
------------------------------------------------------------------
description here of what this fields contains other than
"auxiliary data" - so is this an OPAQUE value? SMIv2
deliberately obsoletes the OPAQUE data type because it fostered
non-interoperable implementaitons; why are we defining opaque
fields here? If a vendor wants an opaque, proprietary field that
is MIB-accessible, let them put it into a vendor MIB
extension. We don't need it specified (opaquely) in the
standard. If there is real justification for standardization,
then at least provide an example of what it is and how it will
be used. And please include why the value is not necessary for
some rows, but it MUST be set before modifying the RowStatus,
and is in a mandatory-to-implement OBJECT-GROUP? I think MUST be
ignored should be strengthened to MUST NOT be used except for a
<please provde details> standardized purpose (to prevent
implementers from deicindg to use it for something totally
different that could cause interoperability problems
later). This object is just way underspecified as to its
purpose.
+ WH: If you re-read the description of the
"snmpTlstmCertSpecified" object identity you'll find it is
used elsewhere in the MIB. It's not a vendor specific
extension, it's a generic parameter extension mechanism that
may be needed for certain mapping types. This object is the
direct result of a WG discussion that occurred in Sweden
(I'm pretty sure) and it was decided that this route was
better than the other alternatives discussed that day. In
particular, Jeff H. brought up the details of a
to-be-standardized-in-the-future otherName mapping that
would require a parameter as well.
Does this already-documented mapping
(snmpTlstmCertSpecified) meet your requirement for an
example, or did you want an example in the text itself.
There is also an example in appendix A for using it but the
interesting thing is that the example text used the old
object name and no one has caught that to date. So if
nothing else, thanks for making me catch that! I've double
checked that the rest of the objects in the appendix match
the current text.
The object clearly states that the value is used by the
mapping type specified via the snmpTlstmCertToTSNMapType (be
a standards based mapping or a enterprise extension). Given
that I'm not sure what MUST NOT clause you're wanting to
insert. If you have text, please supply it as I can't
extract it from your problem description.
It's in the mandatory to implement object group because the
directly specified securityName mapping was one the working
group considered to be important and it is needed to fulfill
that mapping objective.
1.1.18 ANSWERED 8.1 "Implementations SHOULD limit the lifetime ..." Can you
----------------------------------------------------------------------------
provide a reasonable default lifetime?
+ WH: generally the security area has shied away from
recommending lifetimes in fixed documents since it's both
hardware dependent, cryptographic algorithm dependent and
timeline-of-the-world dependent. So the answer is "no". It's
likely implementation and/or deployment dependent.
1.1.19 DONE 8.3 I found this difficult to understand. The "default
-------------------------------------------------------------------
contextEngineID" is a self-identifying value that matches
snmpEngineID from the SNMP-FRAMEWORK-MIB(?). The
securityEngineID that you mention is the engineID for a remote
target. I don't think there is a default value for a remote
target. RFC3411 says that the value of a remote engineID is
determined in an implementation-dependent manner. Since RFC5434
updates the SNMP architecture defined in RFC3411, I think it
would be appropriate to RECOMMEND (much more strongly than the
current text) using RFC5343 to perform snmpEngineID discovery
that is independent of the messaging, security, and transport
models. I strongly recommend using the much-clearer text from
the abstract of RFC5343:
The Simple Network Management Protocol (SNMP) version three (SNMPv3)
requires that an application know the identifier (snmpEngineID) of
the remote SNMP protocol engine in order to retrieve or manipulate
objects maintained on the remote SNMP entity.
[RFC5343] introduces a well-known localEngineID and a discovery
mechanism that can be used to learn the snmpEngineID of a remote SNMP
protocol engine. The proposed mechanism is independent of the
features provided by SNMP security models and may also be used by
other protocol interfaces providing access to managed objects.
I would add:
Implementations SHOULD provide RFC5343 support for engineID discovery.
+ WH: does the following text work for you? I'm not sure we
needed the last line of the above paragraphs so I removed it.
SNMPv3 requires that an application know the identifier
(snmpEngineID) of the remote SNMP protocol engine in order to
retrieve or manipulate objects maintained on the remote SNMP
entity.
<xref target="RFC5343" /> introduces a well-known
localEngineID and a discovery mechanism that can be used
to learn the snmpEngineID of a remote SNMP protocol
engine. Implementations are RECOMMENDED to support and
use the contextEngineID discovery mechanism defined in
<xref target="RFC5343" />.
1.1.20 DONE 9.2 I think this section does not describe the implications
------------------------------------------------------------------------
of using TLSTM with an SNMPv1/v2c message, or specifying USM as
the securityModel in an SNMPv3 message sent over (D)TLS. This
section should state clearly that:
Using a non-transport-aware Security Model with a secure Transport
Model is NOT RECOMMENDED .
and there should be a reference to RFC5590 section 7.1 which
describes the reasons in detail.
+ WH: again, this is an identical copy (except SSH -> TLS) to
what you put in RFC5592. That being said, I've added a new
paragraph:
Using a non-transport-aware Security Model with a secure
Transport Model is NOT RECOMMENDED. See <xref
target="RFC5590" /> Section 7.1 for additional details on
the coexistence of security-aware transports and
non-transport-aware security models.
1.1.21 DONE 10 IANA Considerations:
------------------------------------
(I hate the fact we called the standard SNMPv3, but only one
model within the SNMPv3 standard actually is version 3 - the
SNMP message version 3; it makes things confusing). RFC3411
defines a modular approach where one model should not place
dependencies on another model, or work only with another
specific model. SNMPv3 is a messaging model, and TLSTM should
be able to work with any messaging model. The SNMPv3 prefix in
the IANA request should be just SNMP, to allow TLSTM to be used
with other messaging models, such as a future SNMP messaging
model version 4: s/SNMPv3-TLS/SNMP-TLS/,
s/SNMPv3-DTLS/SNMP-DTLS/, etc.
+ WH: changed. Note that the table in question was actually
from IANA originally as they reviewed the document during last
call. Because there was some confusion I copied it into the
document and fixed it so it made the assignments we wanted.
But I've now also changed it so it doesn't have "v3" in it.
1.2 Comments:
===================
1.2.1 CLOSED section 1: s/standard defined/specification/
----------------------------------------------------------
+ WH: done as suggested.
1.2.2 CLOSED section 3: ist paragraph, second sentence - I had trouble
-----------------------------------------------------------------------
parsing this. You seem to have a message passing between three
things, but really you should only have two. I think you
should drop "and the Transport Subsystem"
+ WH: I think your suggestion is the right approach and made
that change.
1.2.3 CLOSED 3.1.2 last sentence, s/should/SHOULD/
---------------------------------------------------
+ WH: done as suggested.
1.2.4 CLOSED 4.1.0 s/are are/are/
----------------------------------
+ WH: done as suggested.
1.2.5 CLOSED 4.3.1 s/Outgoing message field/Outgoing message/
--------------------------------------------------------------
+ WH: done as suggested.
1.2.6 CLOSED 4.3.2 s/Incoming message field/Incoming message/
--------------------------------------------------------------
+ WH: done as suggested.
1.2.7 DONE 4.3.1 tmState (first usage - a reference?)
------------------------------------------------------
+ WH: I changed the description to:
<t hangText="tmStateReference:">
A reference used to pass model-specific and
mechanism-specific parameters between the Transport
Subsystem and transport-aware Security Models.
</t>
Which came from RFC5590 and is the best text I found for
describing the generic cache.
1.2.8 DONE 4.3.2 incomingMessage: I found this sentence hard to
----------------------------------------------------------------
parse. I could benefit from rewriting.
+ WH: This wording has repeatedly been a problem. How about
just removing the "remove the DTLS bits" part of it since
that's what keeps causing problems. How about just:
The whole SNMP message after being processed by (D)TLS.
1.2.9 CLOSED 4.4.1.1 s/through an TLSTM session/through a single TSLTM
-----------------------------------------------------------------------
session/
+ WH: done as suggested.
1.2.10 CLOSED SnmpTLSAddress - references rfc3986 and 5246 are never
---------------------------------------------------------------------
used in the description; I'm not sure why they are needed in
the REFERENCE clause.
+ WH: removed.
1.2.11 DONE snmpTlstmCertToTSNTable - instead of an example of
---------------------------------------------------------------
non-consecutive indices, I recommend advice recommending
non-consecutive indices in case an admin wants insert an
entry; using non-consecutive indices means they can insert a
new entry into the gap between entries and won't need to
renumber all following entries.
+ WH: changed to:
It is recommended that administrators skip index values to
leave room for insertion the of future rows (E.G., use
values of 10 and 20 when creating initial rows).
1.2.12 CLOSED 11. s/defined by David Harrington/documented by David Harrington/
--------------------------------------------------------------------------------
+ WH: done as suggested.
1.2.13 CLOSED The Appendix is too verbose
------------------------------------------
Offline David H and I had discussions about the example
Appendix A being too long and verbose. We came to agreement
about what is in version -11 and beyond, which is functionally
the same example but with reduced verbiage surrounding it.
2 Dan Romascanu <dromasca@avaya.com> DISCUSS from IESG
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2.1 Discuss Items:
===========================
This is a very important and well written document, and before
baloting a YES vote I would like to clarify a few issues:
2.1.1 WONTDO 1. There are a number of objects in the MIB module with a
-----------------------------------------------------------------------
SYNTAX of Counter32, but there is no indication of the
behavior at discontinuity, or reference to a discontinuity
indicator.
+ WH: Last I checked it's fairly common not to require special
discontinuity checks or objects when there is no reason not
to use the SNMP standard mechanisms for handling
discontinuity. EG, the TARGET-MIB, the sister-MIB
SNMP-SSH-TM-MIB don't have special objects or special text.
It's expected that managers will use the sysUpTime.0 scalar
for detecting discontinuity as there isn't really a special
need for these having discontinuity issues beyond what
typical counters have. Is there a reason you believe this
MIB and it's counters should be different than other
published MIBs?
+ Dan: Let us put aside the 'sister-MIB', because the comment
may apply to it as well. My understanding is that using the
'standard' sysUpTime.0 mechanism assumes that the process
that implements the counters is the same as the process that
counts sysUpTime, or the two are tightly coupled so that all
events that lead to discontinuities are shared and lead to a
reboot. While this is obviously true for core SNMP engine
MIB modules like the TARGET-MIB I wonder and ask loud if
this is true for the TLS/DTLS transport.
+ JS: Not necessarily a reboot - all that is needed is to reset
sysUpTime when a discontinuity occurs.
+ DanR: Right.
+ JS: For those code bases I am familiar with, I think the
answer is very clearly yes. The transport subsystem not only
architecturally is part of an SNMP engine, also
implementation wise I have not seen someone inventing a
protocol between the transport model and the dispatcher in
order to separate things such that they would have different
discontinuity properties. For me, the transport models are
clearly part of the core SNMP engine.
+ DanR: This was exactly the issue I was raising, and the
question I was asking loud. If no different opinions or
experiences are shared I would rest my case on this
matter.
+ WH: I certainly know enough about one major SNMP stack to
say that the discontinuities would always be the same
because the transport system is definitely part of the rest
of the code and can't be 'rebooted' (or otherwise)
independently. In fact, the statistics information for the
transports and the rest of the code base are all kept in the
same place. For the other major SNMP stack, based on my
discussions with them but not based on direct code-reading,
I believe their transport system is also closely tied to the
rest of their infrastructure.
2.1.2 CLOSED 2. I could not make sense what section 9.2 tries to
-----------------------------------------------------------------
say. Is there a warning, describing a threat, a recommendation
to not use the model with older versions of SNMP?
+ WH: This is actually text copied almost verbatim from
RFC5592, our sister-RFC. Would adding the following
sentence to the end of the paragraph make it more clear:
It is RECOMMENDED that only SNMPv3 messages using the
Transport Security Model (TSM) or another
secure-transport aware security model be sent over the
TLSTM transport.
+ Dan: Yes, thanks.
2.1.3 DISCUSS 3. I know that the paragraph starting with 'Further,
-------------------------------------------------------------------
deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED.'
is part of the security boilerplate for all MIB documents. I am
wondering if this is not exactly the place to add text which in
a stronger language warns that configuring with a lower version
of SNMP the TLS transport model for SNMP is something not to
do.
+ WH: I'm not sure I understand your point here. The text
already recommends against anything less than SNMPv3 and
already recommends secure mechanisms. NOT RECOMMENDED is
already equal to SHOULD NOT and I don't think it's
appropriate to switch to a MUST level requirement. Can you
provide example text for what you're wishing to say, as I
believe I may be missing your point?
+ Dan: Why do you think that in this very specific instance
switching to a MUST level requirement is not appropriate?
+ WH: The text will fundamentally only apply to people
deploying it. I certainly don't think it's appropriate to
put in special access-control checks surrounding particular
objects to ensure that no one is allowed to modify certain
objects except with secured SNMPv3. We (or at least
I) have heard of many deployment situations where the physically
protected management network is utilizing SNMPv1 or SNMPv2c
for the speed benefits it can offer and they don't have a
security need on their management back-plane. But they may
desire to configure our new tables for those cases they need
their customers to be able to access counters, etc, or want
to allow themselves access externally over (D)TLS.
IMHO, it's not the job of the IETF to say "you MUST NOT do
stupid things in the real world" or even "you MUST NOT use
any management architecture different than what we envision
to be best for you". It's our job to ensure that
implementations *can* support secured networks in an
interoperable way.
2.2 Comments:
===================
2.2.1 CLOSED 1. For consistency purposes (as TLS is expanded) expand
---------------------------------------------------------------------
SNMP in the title.
+ WH: Expanded per request for -11
+ Dan: OK
2.2.2 CLOSED 2. In a couple of places (section 1, section 9.1) I
-----------------------------------------------------------------
encountered the term 'notification responder' while in all other
places 'notification receiver' is used. The terms are not
exactly synonims, is the inconsistency intentional?
+ WH: receiver is the correct term; changed!
+ Dan: OK.
2.2.3 CLOSED 3. In Section 3.3
-------------------------------
When configuring a (D)TLS target, the snmpTargetAddrTDomain and
snmpTargetAddrTAddress parameters in snmpTargetAddrTable should be
set to the snmpTLSTCPDomain or snmpDTLSUDPDomain object and an
appropriate snmpTLSAddress value. When used with the SNMPv3 message
processing model, the snmpTargetParamsMPModel column of the
snmpTargetParamsTable should be set to a value of 3. The
snmpTargetParamsSecurityName should be set to an appropriate
securityName value and the snmpTlstmParamsClientFingerprint parameter
of the snmpTlstmParamsTable should be set a value that refers to a
locally held certificate (and the corresponding private key) to be
used.
All 'should' seem to need to be capitalized.
+ WH: I've changed all instances of "should" to "SHOULD" in
that paragraph.
+ Dan: OK.
2.2.4 CLOSED 4. In Section 4.1
-------------------------------
Quoting the draft:
Enterprise configurations are encouraged to map a "subjectAltName"
component of the X.509 certificate to the TLSTM specific
tmSecurityName.
I do not think that we have a clear notion of what an
'enterprise configuration' is and why it would be more
appropriate for such a mapping. It looks like a
(non-capitalized) may is more appropriate here.
+ WH: David H. brought up a similar issue. I've changed the
text to:
Deployments SHOULD map the "subjectAltName" component of
X.509 certificates to the TLSTM specific tmSecurityNames.
Does this work for you?
+ Dan: Yes.
2.2.5 CLOSED 5. In Section 5.2 5b) s/If there is not a corresponding
---------------------------------------------------------------------
LCD entry/If there is no corresponding LCD entry/
+ WH: thanks; changed!
+ Dan: OK.
2.2.6 CLOSED 6. In Section 5.4.4
---------------------------------
4) Have (D)TLS close the specified connection. This SHOULD include
sending a close_notify TLS Alert to inform the other side that
session cleanup may be performed.
Unless I miss something sending the close_notify TLS Alert is
always part of the closing sequence, so s/SHOULD/MUST/
+ WH: Yep; David H. mentioned this as well.
+ Dan: OK.
2.2.7 CLOSED 7. Some of the references in the MIB module are not
-----------------------------------------------------------------
included as Informative References - for example RFC 1033, RFC
3490
+ WH: I've added those two references to the Informative section.
+ Dan: OK.
3 Alexey Melnikov <alexey.melnikov@isode.com>:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I agree that this document is important, however there is a list of
issues I would like to discuss before recommending approval of this
document:
3.1 Discuss:
==================
3.1.1 DONE 1) In Section 7:
----------------------------
Quoting the draft:
snmpTlstmParamsClientFingerprint OBJECT-TYPE
SYNTAX Fingerprint
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"A cryptographic hash of a X.509 certificate. This object
should store the hash of a locally held X.509 certificate that
should be used (along with the corresponding private key) when
initiating a (D)TLS connection as a (D)TLS client."
::= { snmpTlstmParamsEntry 1 }
How is the private key stored?
+ WH: That's implementation dependent as it should be, IMHO.
I'd expect different implementations to store private keys
in different ways, as is already done now with X.509
certificates used in other applications. Transfer and
maintenance of the certificate store is out of scope of this
working group. (multiple people have indicated interest in
eventually creating a MIB for generic X.509 management; it's
just not within the charter of ISMS to accomplish this).
+ Alexey: Ok. The "(along with the corresponding private key)"
text made me think that the private key is a part of the
snmpTlstmParamsClientFingerprint. Please reword to make it
clear that that is not the case.
+ WH: How does this sound?
"A cryptographic hash of a X.509 certificate. This
object should store the hash of the public portion of a
locally held X.509 certificate that should be used (along
with the corresponding private key) when initiating a
(D)TLS connection as a (D)TLS client."
+ Juergen S: Why not simply this:
xxx
+ WH: Because previous people were concerned that we needed to
mention the private key as being in existence locally and
needed. That's where the wording "along with the
corresponding private key" came from.
+ JS: Once you implement things, I think it will become pretty
obvious in which situations you need to have access to the
private key. But anyway, then it might be useful to discuss
the fact that there is also a private key in a separate
sentence to avoid confusion that the private key is part of
the MIB object.
+ Alexey: +1
+ WH: As I mentioned the original text didn't discuss
public/private keys but some people found this confusing and
created the existing suggested text as a replacement.
Because of their opinions were voiced during the WG
discussions I'm unwilling to ignore their original complaint
on the text. Thus I think that we have to discuss the fact
that the fingerprint is taken only over the public key and
that the private key is needed to actually perform the
tasks. Those two semi-separate issues are in the text as a
direct result of WG discussions (IE, the text didn't even
come from me).
So... How about the following:
"This object should store the hash of the public portion of a
locally held X.509 certificate. The public key from the
certificate and the corresponding private key should be
used when initiating a (D)TLS connection as a (D)TLS
client."
Which simplifies the text a bit, gets rid of the redundancy
that Juergen pointed out and separates the fingerprint
portion of the text from the usage portion of the text while
still mentioning how the public/private key split works.
+ WH: I decided that wasn't right either. How about this:
This object stores the hash of the public portion of a
locally held X.509 certificate. The X.509 certificate,
its public key, and the corresponding private key will
be used when initiating a (D)TLS connection as a (D)TLS
client.
+ Alexey: This is better. You can also clarify that the
private key is not accessible over SNMP, if you want.
+ WH: I'll stick with the text as is unless you think it's
important to include; there are no objects that specify
private key access so it's implied by the object set.
+ JS: I tend to agree with Wes here. We generally do not list
what a MIB does not contain.
3.1.2 DISCUSS 2) In Section 7:
-------------------------------
Quoting the draft:
snmpTlstmCertSANAny OBJECT-IDENTITY
STATUS current
DESCRIPTION "Maps any of the following fields using the
corresponding mapping algorithms:
Type Algorithm
------------+------------------------
rfc822Name snmpTlstmCertSANRFC822Name
dNSName snmpTlstmCertSANDNSName
iPAddress snmpTlstmCertSANIpAddress
The first matching subjectAltName value
found in the certificate of the above types
MUST be used when deriving the
tmSecurityName."
::= { snmpTlstmCertToTSNMIdentities 5 }
Does the table prescribe the order in which various
subjectAltName types are checked?
+ WH: No, each "mapping algorithm" can prescribe it's own
method of searching in order to keep the table generic.
In fact, the table doesn't (by design) talk about
subjectAltNames themselves and that's left up to the mapping
objects that define how to map certificate contents into
SNMPv3 securityNames.
+ Alexey: I might be missing something. This choice allows
different implementations to do different things. This
doesn't seem to encourage interoperability.
+ WH: I'm sorry if I've inadequately explained things.
Interoperability is definitely assured because all the
mapping algorithms we're defining in the document have
deterministic results.
So, using this example taken straight from the appendix we
have the following mapping set up:
snmpTlstmCertToTSNID = 1
(chosen by ordering preference)
snmpTlstmCertToTSNFingerprint = HASH (appropriate fingerprint)
snmpTlstmCertToTSNMapType = snmpTlstmCertSANAny
snmpTlstmCertToTSNData = "" (not used)
snmpTlstmCertToTSNStorageType = 3 (nonVolatile)
snmpTlstmCertToTSNRowStatus = 4 (createAndGo)
This says that if the incoming connection contains a public
key in the verification tree that matches the HASH then it
should use the 'snmpTlstmCertSANAny' mapping algorithm
(which is assigned a unique OID within the MIB tree so it
can't be confused by another conflicting definition).
So, looking up the rules for snmpTlstmCertSANAny we find:
Maps any of the following fields using the
corresponding mapping algorithms:
Type Algorithm
------------+----------------------------
rfc822Name snmpTlstmCertSANRFC822Name
dNSName snmpTlstmCertSANDNSName
iPAddress snmpTlstmCertSANIpAddress
The first matching subjectAltName value found in the
certificate of the above types MUST be used when
deriving the tmSecurityName.
The last paragraph clearly indicates we take the *first* SAN
of the above types in order to do the mapping with. So if
the certificate in use had 300 different SANs but the first
was a rfc822Name containing alexey.melnikov@isode.com then
that is the value that every implementation MUST pick in
order to meet the standard. There is no ambiguity about
what happens if you follow all the rules for the
configuration specified in the MIB.
The only extensibility is that future standards or
enterprises can define their own mapping algorithms,
assigned to their own unique OIDs that can be used in the
snmpTlstmCertToTSNMapType column. We're actually expecting
at some point in the future within the IETF to define a
standard for mapping (deterministically of course) the
kerberos principal from an otherName field. (But since that
doesn't exist now, it can't be used yet.)
Make more sense?
+ David Harrington:
I think the text you quote is not deterministic because it
says the tmSecurityName is derived, but doesn't specify how
the derivation is done:
> The first matching subjectAltName value found in the
> certificate of the above types MUST be used when
> deriving the tmSecurityName.
You do not specify a 1:1 identity mapping MUST be
used. Something derived is usually different than the
original. So if the subjectAltName was "David Harrington", I
could derive a tmSecurityName of "David", "Harrington", or
"David Harrington H73653" and still meet the definition you
quote. And if this was used in a securityName in a MIB
module, and read by a remote operator, it would not be
apparent that agent A's "David" was the same principal as
agent B's "Harrington".
And I have to agree that if everybody gets to define their
own additional algorithms for derivation, even if they are
registered by OID, that doesn't lend itself to
interoperability. Is "IETF Review" required for every
algorithm so the algorithm is at least published publicly?
+ WH: Well, it does. But if you missed it then more text is
needed to clarify it further.
In particular:
DESCRIPTION "Maps any of the following fields using the
corresponding mapping algorithms:
Type Algorithm
Note that the mapping algorithm is specified in the second
column, and each of those mapping algorithms are
deterministic in nature (we worked hard to make sure that
all case-sensitivity, etc, was dealt with in the
sub-algorithms).
If you're concerned about the above not being enforced
properly then I'll add the following new text (surrounded be
***s) to ensure compliance.
DESCRIPTION "Maps any of the following fields using the
corresponding mapping algorithms:
Type Algorithm
------------+----------------------------
rfc822Name snmpTlstmCertSANRFC822Name
dNSName snmpTlstmCertSANDNSName
iPAddress snmpTlstmCertSANIpAddress
The first matching subjectAltName value found in the
certificate of the above types MUST be used when
deriving the tmSecurityName. ***The mapping algorithm
specified in the 'Algorithm' column MUST be used to
derive the tmSecurityName.***"
Does that appropriately address your concerns with respect
to the "determinsticness" of the mapping?
+ WH: Regarding everyone defining their own algorithms: this
is nothing new to the IETF or to SNMPv3. We already allow
USM users, standards bodies and developers to define their
own security algorithms (i.e., auth and priv) via a
specified OID usable in the usmUserTable. If you want an
IETF standardized algorithm, you likely need to publish it
via IETF process and get an assignment in the MIB tree
from IANA. However, if you work at a device-vendor and
want to create your own then it's sort of up to you to get
it right. E.G. Supposedly there is an OID that was
created to allow interoperable 3DES encryption between
certain SNMP stacks that supported that
enterprise-specific assigned encryption
identifier. Knowing the people that defined how it was
supposed to work, I'm sure they got it right and
interoperability problems haven't resulted. However, there
was nothing stopping them in the USM wording that required
IETF review for them to publish said OID. Nor do I think
there should be. We also allow enterprise-specific
security-model identifiers to be defined, but yet we don't
mandate IETF-review for them to start implementing or
publishing documentation about them. How is this
different?
The important aspect in my mind is that if two
implementations implement a mapping algorithm registered
at an OID and there are no flaws in the language that
define the OID then will interoperability succeed? The
answer is certainly yes. If the definition or the
implementation is flawed then interoperability will
certainly fail, just as it would for USM auth/priv
algorithms and SNMPv3 security model algorithms.
+ Alexey:
Sorry, I've missed the text about ordering.
However there is another more subtle problem with this
approach. My understanding is that many TLS APIs don't
necessarily allow to iterate through subjectAltName types in
the order are specified in the certificate. It is more
common to have APIs that return SAN of a specific type. So
this choice really makes it hard for applications to
implement the mapping.
+ WH:
I'm not sure about all the stacks. If this is true I
suppose making the Any algorithm optional is the only way to
recover. We're implementing this using OpenSSL and it seems
to return stuff in order, but I'll double check that
tomorrow.
If other popular TLS X.509 manipulation stacks don't allow
for this we have the choice of:
1) Deleting the snmpTlstmCertSANAny entirely.
(I don't favor this one at all)
2) Making the snmpTlstmCertSANAny optional.
(My preference)
3) Requiring everyone to implement it :-)
+ Alexey:
I generally feel you have too many choices for extracting identity
from certificates. I think this is David's point as well.
And when you add algorithms that combine multiple other choices in a
certain way, you increase the number of choices.
But anyway, I think I need to think more about this and we should
discuss this with the rest of IESG.
+ WH:
It should be noted that the WG had this exact discussion (in
Sweden) and the WG members were of the opinion that we
needed the "Any" option for ease of configuration. I'm
reluctant to change the current behavior given these past
discussions.
The output is deterministic so there is no issue with
interoperability unless the APIs can't handle it.
3.1.3 CLOSED 3) In Section 7:
------------------------------
Quoting the draft:
snmpTlstmCertToTSNMapType OBJECT-TYPE
SYNTAX AutonomousType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Specifies the mapping type for deriving a
tmSecurityName from a certificate.
I couldn't find where allowed values for this are defined. Can
you please help me find it?
+ WH: In this MIB document the defined values are:
snmpTlstmCertSpecified
snmpTlstmCertSANRFC822Name
snmpTlstmCertSANDNSName
snmpTlstmCertSANIpAddress
snmpTlstmCertSANAny
snmpTlstmCertCommonName
But AutonomousType is a SNMP-ism for allowing other MIB
documents to define future mapping algorithms as well as
long as they're assigned to a unique OID (like those in this
document are). E.G. it's already been discussed that
eventually Kerberos users may wish to have a mapping
algorithm for extracting kerberos principal names from the
otherName type.
To make things more clear about where in the current MIB the
appropriate values are I've added the following text to the
object DESCRIPTION clause for the snmpTlstmCertToTSNMapType
column:
Suitable values for assigning to this object that are
defined within the SNMP-TLS-TM-MIB can be found in the
snmpTlstmCertToTSNMIdentities portion of the MIB tree."
I believe this will help future readers from needing to ask
the same question.
+ Alexey: Yes, this will help.
3.1.4 CLOSED 4) In Section 7:
------------------------------
SnmpTLSAddress ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1a"
STATUS current
DESCRIPTION
"Represents a IPv4 address, an IPv6 address or an US-ASCII
encoded hostname and port number.
An IPv4 address must be in dotted decimal format followed by a
colon ':' (US-ASCII character 0x3A) and a decimal port number
in US-ASCII.
An IPv6 address must be a colon separated format, surrounded
by square brackets ('[', US-ASCII character 0x5B, and ']',
US-ASCII character 0x5D), followed by a colon ':' (US-ASCII
character 0x3A) and a decimal port number in US-ASCII.
This is missing a reference to a document defining the exact
IPv6 format.
+ WH: so is RFC5592 which I copied that text from! I added a
reference to RFC3513 to fix this (both in the MIB and in the
normative references).
+ Alexey: This should be fine, but pointing to
draft-ietf-6man-text-addr-representation-07.txt would be
even better (it is in RFC Editor queue now).
+ WH: Ok, I've changed it to the above reference with the
following note added for the rfc editor:
-- RFC Editor: if I-D.ietf-6man-text-addr-representation fails to get
-- published ahead of this draft, RFC3513 has been agreed to be a
-- sufficient replacement instead.
+ Alexey: Works for me.
3.1.5 CLOSED 5).
-----------------
[RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
and T. Wright, "Transport Layer Security (TLS)
Extensions", RFC 4366, April 2006.
DISCUSS DISCUSS:
I think this reference is Normative, as it is a recommended
procedure (SHOULD level requirement) for allowing the client
to tell the server which hostname it is connecting to.
+ WH: I agree and have moved it to the normative section.
+ WH: Never heard directly back, but since I took his text I'm
assuming this is resolved.
3.2 Comments:
==================
3.2.1 CLOSED In Section 3.1.2, the last sentence of the last paragraph:
------------------------------------------------------------------------
Implementations should offer configuration settings for
mapping algorithms to SNMPv3 security levels.
s/should/SHOULD ?
+ WH: Another IESG member suggested the same thing and I've
changed it to a SHOULD
+ WH: Never heard directly back, but since I took his text I'm
assuming this is resolved.
3.2.2 CLOSED 3.1.3. (D)TLS Connections
----------------------------------------
As an implementation hint: note that the (D)TLS internal
SessionID does not meet these requirements, since it can
change over the life of the connection as seen by the TLSTM
(for example, during renegotiation), and does not
necessarily uniquely idenfify a TLSTM session (there can be
multiple TLSTM sessions sharing the same D(TLS) internal
SessionID).
typo: identify
+ WH: thanks, fixed!
+ WH: Never heard directly back, but since I took his text I'm
assuming this is resolved.
3.2.3 DONE In Section 5.1.1:
-----------------------------
The first reference to acronym LCD should be expanded and
should point to where it is defined.
+ WH: I've changed the source text of the initial acronym use
to read:
The TLS Transport Model queries the Local
Configuration Datastore (LCD) (see <xref
target="RFC3411" /> Section 3.4.2) using the transport
parameters (source and destination IP addresses and
ports) to determine if a session already exists.
3.2.4 DONE In Section 7:
-------------------------
Quoting the draft:
snmpTlstmCertToTSNRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The status of this conceptual row. This object may be used
to create or remove rows from this table.
To create a row in this table, an administrator must set this
object to either createAndGo(4) or createAndWait(5).
Until instances of all corresponding columns are appropriately
configured, the value of the corresponding instance of the
snmpTlstmParamsRowStatus column is 'notReady'.
Is 'notReady' correspond to an actual value of this field?
(Similar question regarding 'notReady' value in
snmpTlstmParamsRowStatus and snmpTlstmAddrRowStatus.)
+ WH: It's a standard value for the RowStatus type, so yes it
corresponds to an actual value. I've gone ahead and
modified the text so it reads notReady(3) in all three
places to make it match the rest of the text style when
referring to enum values. Thanks for the suggestion.
3.2.5 CLOSED Also in Section 7:
--------------------------------
Quoting the draft:
snmpTlstmServerInvalidCertificate NOTIFICATION-TYPE
OBJECTS { snmpTlstmAddrServerFingerprint,
snmpTlstmSessionInvalidServerCertificates}
STATUS current
DESCRIPTION
"Notification that the server certificate presented by an SNMP
over (D)TLS server could not be validated even if the
fingerprint or expected validation path was known. I.E., a
cryptographic validation occurred during certificate
validation processing.
Is the word "error" missing after the word "validation"?
+ WH: Yes it is; thanks for catching it.
+ WH: Never heard directly back, but since I took his text I'm
assuming this is resolved.
3.2.6 CLOSED 8.1. Sessions
----------------------------
Quoting the draft:
Whenever possible, implementations
SHOULD provide graceful session termination through the use of
disconnect messages.
Did you mean TLS disconnect messages here?
+ WH: Yep; I added "TLS" per your recommendation
+ WH: Never heard directly back, but since I took his text I'm
assuming this is resolved.
4 Peter Saint-Andre <stpeter@stpeter.im>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4.1 Discuss:
====================
4.1.1 CLOSED The definition of snmpTlstmCertSANIpAddress mentions that
-----------------------------------------------------------------------
securityName lengths might exceed what VACM can handle;
doesn't this introduce possible interoperability problems?
+ WH: The end result would need to be the same, based on the
definition of the VACM processing rules: the message would be
discarded. The 32-octet limitation of the VACM is not
something we can fix within the scope of the ISMS working
group (though many people would like this problem to go
away).
So in the end, no that no interoperability problem exists as
all implementations MUST do the same thing: discard the
packet (since no access rule would exist allowing it
through). That doesn't mean we're left in a wonderful
position and the best we can do is warn the operators; hence
the warning in the MIB.
+ Peter: OK, I see your point: it's not an interoperability
problem, but those who deploy the technology need to be
aware of the limitation and plan accordingly.
4.1.2 CLOSED The definition of SnmpTLSAddress states that
----------------------------------------------------------
"internationalized hostnames are encoded in US-ASCII as
specified in RFC 3490", but I think this could be defined more
precisely because (1) RFC 3490 does not talk about
"internationalized hostnames", (2) you need to state that you
are using the ToASCII operation, and (3) you need to specify
whether the UseSTD3ASCIIRules flag is set. This definition
also appears to make normative references to RFC 1033 and RFC
3490, but those specifications are not included in the
Normative References section. Finally, this definition
references RFC 3986 but that specification is never used here.
+ WH: I've changed the text to the following to address your
concerns; please let me know if you believe it needs further
changes.
A hostname is always in US-ASCII (as per RFC1033);
internationalized hostnames are encoded in US-ASCII as
domain names after transformation via the ToASCII
operation specified in RFC 3490. The ToASCII operation
MUST be performed with the UseSTD3ASCIIRules flag set.
The hostname is followed by a colon ':' (US-ASCII
character 0x3A) and a decimal port number in US-ASCII.
The name SHOULD be fully qualified whenever possible.
+ WH: references for 3490 and 1033 moved to the normative section.
+ WH: The 3986 reference has been removed (in the process of
responding to other similar comments).
+ Peter: Excellent.
4.2 Comments:
==================
4.2.1 CLOSED Section 1.1 has:
------------------------------
Quoting the draft:
"Authentication" in this document typically refers to the
English meaning of "serving to prove the authenticity of"
the message, not data source authentication or peer
identity authentication.
Why not reference the definition from RFC 4949?
+ David H:
Let me wade in as co-chair of the SNMPv3 WG, concluded.
[quoted above]
because then the definition used in this document would
not be consistent with definitions used in the SNMPv3
standard (RFC3411-3418) or the SNMP Transport subsystem
extension (RFC5590), the Transport Security Model
(RFC5591) the SSHTM (RFC5592), multiple (now mostly
Historic) versions of SNMPv2, the SNMP Coexistence BCP,
and a range of other SNMP documents, including every MIB
module that has the required MIB Security boilerplate.
For example, the term privacy has existed in SNMP at least
since RFC1352 (July 1992). It doesn't mean the rights of
an individual to decide how their information can be
shared; it means protecting the confidentiality of
information in SNMP messages. When SNMPv3 was advanced
from proposed standard (1998) to draft (1999) to full
standard (2002), the IESG accepted that it was better to
have consistency within the long list of SNMP security
documents than to rewrite everything to match the
(contentious) glossary document that was still in the
process of being written in 2000.
my $.02 ;-)
dbh
+ WH: I agree with David; if we were to rewrite the whole SNMP
system we'd likely use consistent terminology. But as this
new document is a small piece of a much larger system it
helps if all the terminology is consistent first within the
system itself.
+ Peter: OK, mostly I was just checking because it seems good
for us all to use consistent terminology, where possible.
4.2.2 CLOSED I realize that RFC 3411 talks about "privacy", but the
--------------------------------------------------------------------
more modern term is "data confidentiality" (see, again, RFC
4949).
+ WH: duplicate response as the above as it's really the same
issue.
+ Peter: See above.
4.2.3 CLOSED Forgive my ignorance regarding SNMP/SMI, but I can't seem
-----------------------------------------------------------------------
to find a definition of "transport domain"; is it a DNS domain
name, a trust domain, or something else? (It seems to be more
like an address type.) It might help to make this clearer in
the definitions of the snmpTLSTCPDomain and snmpDTLSUDPDomain
transport domains.
+ WH: Well, this document is really an standards
implementation of what is defined in RFC5590. It's
important to understand that document before reading this
one, as it says in the first sentence of the introduction.
In fact, RFC5590 is titled "Transport Subsystem for the
Simple Network Management Protocol". That being said,
transport domains are very much an SNMP-ism and it would
certainly be hard to understand if this was the first SNMP
document you had read. I'll put in a reference to RFC2579
in the object references section which I think is the best
that can really be done.
+ Peter: Thanks for the clarification.
4.2.4 DONE The definition of snmpTlstmCertSANDNSName mentions
--------------------------------------------------------------
converting the DNS domain name to lower case. Is the handling
of internationalized domain names inherited from dNSName in
RFC 5280 (i.e., convert to the ACE encoding)?
+ WH: RFC5280 specifically mentions that DNS names are
compared in a case-insensitive manner. And therefore since
the value 'Foo.example.com' must be equal within the
resulting derived tmSecurityName the working group decided
to make all DNS name instances lower case so that no matter
what was in the certificate we'd use names that would also
be comparatively the same.
+ Peter: OK, thanks for the clarification. It might be good to
add a short note to the effect that this requires one step
beyond the comparison rules specified in Section 7.2 of RFC
5280.
+ WH: Well, we're not actually doing a comparison at this
particular point. We're taking data out of the certificate
to make use of. The reason for requiring the lower-casing
is to make sure that because certificates *can* be
constructed with two values that are supposed to be the same
from the certificate's point of view and that our resulting
derived label (tmSecurityName) will also be unique per value
from the certificate. But we're not doing a comparison,
we're deriving a value from a X.509 field.
+ Peter:
Change "comparison" to "canonicalization" or whatever term
you prefer and I think my comment still makes sense as an
implementation note -- you could take the output of a string
preparation library that supports the Nameprep profile or a
security library that supports RFC 5280 but you would then
need to perform an additional step of lowercasing the domain
name before you could correctly do something useful with the
output.
I'm talking about something like the following parenthetical
remark:
snmpTlstmCertSANDNSName OBJECT-IDENTITY
STATUS current
DESCRIPTION "Maps a subjectAltName's dNSName to a
tmSecurityName after first converting it to all
lower case (note that [RFC5280] does not specify
converting to lower case so this involves an
extra step)."
+ WH: Ok, I'll add that to the MIB objects minus the []s
around the RFC5280 since hard references aren't allowed in
MIBs. Thanks for suggesting the text you wished to see in place.
4.2.5 CLOSED Is there any provision for supporting subjectAltName
------------------------------------------------------------------
extension types other than dNSName, rfc822name, and iPAddress,
such as SRVName (RFC 4395) or uniformResourceIdentifier
(cf. RFC 4088)?
+ WH: Not at the moment. Others were discussed as "future
desires" but the system as-is can be extended in the future
with future mapping algorithms. So this document only
defines a few of the possibilities, there is nothing
preventing a future (potentially short) document from
defining new ones.
+ Peter: OK
4.2.6 CLOSED Is there a preferred order of matching subjectAltName
-------------------------------------------------------------------
extensions?
+ WH: The objects specifically call out that you MUST pick the
first one in the list that is a match.
+ Peter: I must have missed that. My apologies.
4.2.7 DISCUSS How exactly does an entity prepare for matching of
-----------------------------------------------------------------
subjectAltName extensions? See the discussion in
draft-saintandre-tls-server-id-check for related material.
+ WH: I'm not entirely sure I'm exactly matching what you're
asking about. Certificate SAN to tmSecurityName mapping was
what you were last asking about, but I suspect you've now
switched to checking for name validity when making
connections?
The working group recognized that there was new work being
undertaken in this area. The current text in the
tlstmAddrTable object was added in an effort to put in
wording that addressed the issue of connection setup. If
you have suggested changes or additions that you feel are
important I'd gladly consider them.
+ Peter: By "prepare for" I mean that connecting party must
have some inputs to the matching operation so that it has a
canonical reference identifier that it expects the other
party to present in a certificate. For example, if I type
"[https://www.example.com/]" into the URL line of my browser
then my browser might expect the presented certificate to
include one of the following identifiers:
uniformResourceIdentifier = [https://www.example.com/]
dNSName = www.example.com
dNSName = *.example.com
CN = www.example.com
etc.
We have a discussion about this in
draft-saintandre-tls-server-id-check for various application
protocols, which might provide some concepts that you could
re-use.
+ WH: This is the text from the document that describes
setting up connections and what to expect from the
certificate contents. Is this text insufficient in your
mind then?
If the server's presented certificate has passed
certification path validation [RFC5280] to a configured
trust anchor, and an active row exists with a zero-length
snmpTlstmAddrServerFingerprint value, then the
snmpTlstmAddrServerIdentity column contains the expected
host name. This expected host name is then compared against
the server's certificate as follows:
- Implementations MUST support matching the expected host
name against a dNSName in the subjectAltName extension
field and MAY support checking the name against the
CommonName portion of the subject distinguished name.
- The '*' (ASCII 0x2a) wildcard character is allowed in the
dNSName of the subjectAltName extension (and in common
name, if used to store the host name), but only as the
left-most (least significant) DNS label in that value.
This wildcard matches any left-most DNS label in the
server name. That is, the subject *.example.com matches
the server names a.example.com and b.example.com, but does
not match example.com or a.b.example.com. Implementations
MUST support wildcards in certificates as specified above,
but MAY provide a configuration option to disable them.
- If the locally configured name is an internationalized
domain name, conforming implementations MUST convert it to
the ASCII Compatible Encoding (ACE) format for performing
comparisons, as specified in Section 7 of [RFC5280].
If the expected host name fails these conditions then the
connection MUST be closed.
4.2.8 DONE It might be appropriate for this specification to say
-----------------------------------------------------------------
that checking of the Common Name is a fallback and that
checking of subjectAltName extensions is preferred.
+ WH: The snmpTlstmCertToTSNTable table description says this
already. I'd be happy to mention it in other places too if
you feel it was appropriate and had places that you think
such a NOT RECOMMENDED statement belongs.
+ Peter: The specification contains the following text
regarding the Common Name:
###
7. MIB Module Definition
<snip/>
snmpTlstmCertCommonName OBJECT-IDENTITY
STATUS current
DESCRIPTION "Maps a certificate's CommonName to a tmSecurityName
after converting it to a UTF-8 encoding."
[...No mention that this usage is NOT RECOMMENDED or that objects of
type snmpTlstmCertSAN* are preferred...]
<snip/>
snmpTlstmCertToTSNTable OBJECT-TYPE
SYNTAX SEQUENCE OF SnmpTlstmCertToTSNEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
<snip/>
Users are encouraged to make use of certificates with
subjectAltName fields that can be used as tmSecurityNames so
that a single root CA certificate can allow all child
certificate's subjectAltName to map directly to a
tmSecurityName via a 1:1 transformation. However, this table
is flexible to allow for situations where existing deployed
certificate infrastructures do not provide adequate
subjectAltName values for use as tmSecurityNames.
Certificates may also be mapped to tmSecurityNames using the
CommonName portion of the Subject field. However, the usage
of the CommonName field is deprecated and thus this usage is
NOT RECOMMENDED. Direct mapping from each individual
certificate fingerprint to a tmSecurityName is also possible
but requires one entry in the table per tmSecurityName and
requires more management operations to completely configure a
device."
<snip/>
snmpTlstmAddrTable OBJECT-TYPE
SYNTAX SEQUENCE OF SnmpTlstmAddrEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
<snip/>
- Implementations MUST support matching the expected host
name against a dNSName in the subjectAltName extension
field and SHOULD support checking the name against the
common name portion of the subject distinguished name.
[...Here Common Name appears to be a SHOULD...]
<snip/>
A.2. Configuring the Command Responder
<snip/>
The above is an example of how to map a particular certificate to a
particular tmSecurityName. It is recommended, however, that users
make use of direct subjectAltName or CommonName mappings where
possible as it provides a more scalable approach to certificate
management.
[...Here Common Name appears to be RECOMMENDED...]
###
Thus it appears that there are some inconsistencies in the text
regarding whether Common Name is NOT RECOMMENDED or RECOMMENDED.
Peter
+ WH: Ok, I'll make the following changes to strengthen the
text. The last text you discussed was in the appedix and
was complete rewritten lately by David H. and myself and no
longer contains that recommendation at all.
+ Changed text 1 (addition of second sentence)
DESCRIPTION "Maps a certificate's CommonName to a tmSecurityName
after converting it to a UTF-8 encoding.
The usage of CommonNames is deprecated and
users are encouraged to use subjectAltName
mapping methods instead."
+ Changed text 2 (SHOULD -> MAY):
- Implementations MUST support matching the expected host
name against a dNSName in the subjectAltName extension
field and MAY support checking the name against the
common name portion of the subject distinguished name.
Look good?
5 Tim Polk <tim.polk@nist.gov>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
5.1 DONE RFC 5590 states:
==========================
It is considered desirable by some industry segments that SNMP
Transport Models utilize transport-layer security that addresses
perfect forward secrecy at least for encryption keys. Perfect
forward secrecy guarantees that compromise of long-term secret keys
does not result in disclosure of past session keys. Each proposed
Transport Model should include a discussion in its security
considerations of whether perfect forward secrecy is appropriate for
that Transport Model.
This document does not appear to include any such discussion.
+ WH: Would the addition of the following text to the security
considerations section satisfy this in your eyes:
The use of Perfect Forward Secrecy is RECOMMENDED and can be provided
by TLS with appropriately selected cipher suites, as discussed in
appendix F of [RFC5246].
5.2 CLOSED The document requires use of TLS, and mandates
==========================================================
certificate-based authentication for both the client and server.
This provides a nice baseline with a reasonably consistent level
of security. However, many people consider SSL and TLS to be
interchangeable, and early versions of SSL do not provide an
acceptable level of security. I would like to see text along
the following lines added to this specification:
Implementations of TLS typically support multiple versions of
the Transport Layer Security protocol as well as the older
Secure Sockets Layer (SSL) protocol. Because of known
security vulnerabilities, TLSTM clients and servers MUST NOT
request, offer, or use SSL 2.0. See Appendix E.2 of [TLS]
for further details.
The Security Considerations would be one possible location for
this text, but the exact placement is not an issue...
+ WH: I've added that exact text to a new security
considerations sub-section entitled "TLS Version
Requirements".
+ WH: Never heard directly back, but since I took his text I'm
assuming this is resolved.
--
Wes Hardaker
Cobham Analytic Solutions
- [Isms] Status of IESG-review changes for draft-ie… Wes Hardaker
- Re: [Isms] Status of IESG-review changes for draf… David Harrington
- Re: [Isms] Status of IESG-review changes for draf… Wes Hardaker
- Re: [Isms] Status of IESG-review changes for draf… David Harrington
- Re: [Isms] Status of IESG-review changes for draf… Wes Hardaker
- Re: [Isms] Status of IESG-review changes for draf… Juergen Schoenwaelder