Subject: Re: [Isms] TLSTM -04 draft being published: wraps up all outstanding edits

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 1 Jan 2010 12:52:05 +0100

On Thu, Dec 31, 2009 at 04:13:48PM +0100, tom.petch wrote:
> ----- Original Message -----
> From: "Juergen Schoenwaelder" [email-masked]
> Sent: Thursday, December 31, 2009 1:51 PM
> 
> > On Thu, Dec 31, 2009 at 09:42:57AM +0100, tom.petch wrote:
> >
> > > 4366 requires the HostName to be a fully qualified DNS name
> > > so if we follow that RFC, we would require our securityNames-to-be
> > > to be fully qualified DNS names.  I think that wrong.
> >
> > Why?
> 
> You seem to be suggesting that your principal names are
> fully qualified DNS names.  I know of none such so forcing
> the SNI to be a fully qualified DNS name, which is my
> reading of RFC4366, means yet another mapping table
> to be configured by the admin, mapping fully qualified
> DNS names into what admins actually assign to users.

My understanding of the server-name extension is that it is used by a
client to indicate to which server it is talking. This is important
for HTTP where a single server can serve multiple different "sites" by
way of the HTTP Host: header. Since the server needs to pick the cert
before the Host: header is sent, the server-name extension is used to
communicate the host name.

I am not sure why this problem would be relevant for SNMP. If it is, I
would argue that a host name to identify the SNMP engine is kind of
best practice (through it should really be the SnmpEngineID).

> I see a need for another case allowing snmpAdminString format.

It seems you are looking at a mechanism to tell the server to
establish a session with certs for [email-masked] or just foo@
while talking to a given transport endpoint. In this case, I think we
are talking about another TLS extension to identify a 'user' or
'principal' and this extension should likely be independent of the
server-name extension. I have no clue whether someone has already
invented this but I suspect that such a thing should go via the TLS
working group since it likely has much broader applicability if done
right.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 04 Jan 2010 16:28:29 -0800

>>>>> On Thu, 31 Dec 2009 09:30:41 +0100, "tom.petch" <[email-masked]> said:

tp> Some editorial suggestions, of grammar, semantics and clarity.

I've made the changes you requested.  Thanks for specifying precisely
what you wanted the wording to be for most of them.  Notes on some:

tp> 3.1.2
tp> " and the type and address associated "
tp> suggest  "and the transport type and address associated "
tp> type on its own left me floundering

Actually used: "... address authenticated principal, the transport type
                    and the transport addresss associated with an
                    incoming message."

tp> 3.1.3
tp> "Each unique combination of these
tp> parameters MUST have a locally-chosen unique tlstmSessionID
tp> associated for active sessions.  "
tp> The last clause seems barely grammatical; suggest removing 'associated
tp> for active sessions'  If you want to limit this to active sessions, suggest
tp> 'for each active session'

Used the suffix, since I think it's important.

tp> 3.2 "(e.g..," an extra period to go with ...

Actually, I removed a period instead.

tp> 5.2 5 4b (eh???? but that is what it says:-(

I don't understand that comment.

tp> 5.3 3b
tp> "The (D)TLS client side of the connection MUST verify that
tp> authenticated identity of the (D)TLS server's presented
tp> certificate is the expected certificate"
tp> ie 'the authenticated identity is the certificate'
tp> ok grammatically, but for me, not semantically; identities and certificates
tp> come from different universes

Actually, grammatically it was missing a 'the'.

I changed the sentence to just:

  "The (D)TLS client side of the connection MUST verify that the (D)TLS
  server's presented certificate is the expected certificate."

since the (new in -04) next sentence actually states that it must be
authenticated too.

-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 04 Jan 2010 16:33:38 -0800

>>>>> On Thu, 31 Dec 2009 06:13:39 +0100, Juergen Schoenwaelder <[email-masked]> said:

JS> I heard David Harrington, Randy Presuhn, Andrew Donati and myself (as
JS> technical contributor) speaking in favour of II.b) and all three
JS> provided different arguments for choosing II.b):

To support this I've simply removed all the text describing fate sharing
entirely, which brings us back to the SMI default of "none":

--- a/draft/draft-ietf-isms-dtls-tm.xml
+++ b/draft/draft-ietf-isms-dtls-tm.xml
@@ -2166,13 +2166,7 @@ tlstmParamsRowStatus OBJECT-TYPE

         An attempt to set these objects while the value of
         tlstmParamsRowStatus is active(1) will result in
-        an inconsistentValue error.
-
-        If this row is deleted it has no effect on the corresponding
-        row in the targetParamsTable.
-
-        If the corresponding row in the targetParamsTable is deleted
-        then this row must be automatically removed."
+        an inconsistentValue error."
     ::= { tlstmParamsEntry 3 }

 -- Lists expected certificate fingerprints to be presented by a DTLS
@@ -2325,13 +2319,7 @@ tlstmAddrRowStatus OBJECT-TYPE

         An attempt to set these objects while the value of
         tlstmAddrRowStatus is active(1) will result in
-        an inconsistentValue error.
-
-        If this row is deleted it has no effect on the corresponding
-        row in the targetAddrTable.
-
-        If the corresponding row in the targetAddrTable is deleted
-        then this row must be automatically removed."
+        an inconsistentValue error."
     ::= { tlstmAddrEntry 4 }

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 04 Jan 2010 16:56:04 -0800

>>>>> On Fri, 1 Jan 2010 12:52:05 +0100, Juergen Schoenwaelder <[email-masked]> said:

JS> I am not sure why this problem would be relevant for SNMP. If it is, I
JS> would argue that a host name to identify the SNMP engine is kind of
JS> best practice (through it should really be the SnmpEngineID).

The relevancy primarily comes from the long standing desire expressed in
various places to send notifications to a single port but to multiple
identities.  In practice, I've never been convinced this is used in the
wild, but people have talked about a notification receiver application
that "routes" notifications to the right principal after it receives and
processes them.  This was possible with USM and people have said it
should be possible with any ISMS related solutions as well.

The server-name extension for TLS lets you do this by telling the server
which certificate it should be using (IE, which identity it should be
receiving the notification for).

I agree I don't think we should get in the habit, as you've suggested,
as specifying *how* this is done within (D)TLS.  The best we can do is
reference an existing specification (eg, 4366) and say you should use
that.  Maybe the right thing to do would be to say something more
generic.

IE:

OLD:
   Servers that wish to support multiple principals at a particular port
   SHOULD make use of the Server Name Indication extension defined in
   Section 3.1 of [RFC4366].

NEW:
   Servers that wish to support multiple principals at a particular port
   SHOULD make use of +++a (D)TLS extension that allows server-side
   principal selection like+++ the Server Name Indication extension
   defined in Section 3.1 of [RFC4366].

I have not made this change and merely pose it here as a possibility.
-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 5 Jan 2010 11:21:39 +0100

> I have not made this change and merely pose it here as a possibility.

Speaking as technical contributor, I like this proposed NEW text.

/js

---

From: "tom.petch" <[email-masked]>
Date: Tue, 5 Jan 2010 11:41:26 +0100

Wes

Picking up on a couple of points:

I don't understand that comment

Section 5.2 has a sub-section 5 which then has sub-sub-sections 4b and 4a.;
there are no sub-sub-sections 1, 2, 3; looks odd - I would have made the
sub-sub-sections just a) and b) as secshell did.

tp> 5.3 3b

I like your replacement sentence.
<aside>
My original comment no longer applies,
but the thinking behind it is that a thingy/person/principal/.. has an identity
(and a single person may have multiple identities in different contexts) and
asserts those identities with identifiers and then produces security credentials
to authenticate that assertion.  This is something that came up very early in
the life of isms, raised, as I recall, by our AD.
</aside>

Tom Petch

---

From: "tom.petch" <[email-masked]>
Date: Tue, 5 Jan 2010 11:48:50 +0100

Wes

I am easy either way.  My original point was that it should be 4366bis rather
than 4366 which obviously raises a dependency which some do
not like.

Incidentally, it was Joe that originally raised this (6Dec09) so I would
value his comments on the current state of this topic.

Tom Petch

----- Original Message -----
From: "Wes Hardaker" <[email-masked]>
To: "tom.petch" <[email-masked]>
Cc: "Wes Hardaker" <[email-masked]>; <[email-masked]>
Sent: Tuesday, January 05, 2010 1:56 AM
Subject: Re: TLSTM -04 draft being published: wraps up all outstanding edits

> >>>>> On Fri, 1 Jan 2010 12:52:05 +0100, Juergen Schoenwaelder

---

From: "tom.petch" <[email-masked]>
Date: Tue, 5 Jan 2010 12:01:33 +0100

"   DTLS over UDP is significantly different in terms of session handling
   than when TLS or DTLS is run over session based streaming protocols
   like TCP or SCTP.  Specifically, the DTLS protocol, when run over
   UDP, does not have a session identifier that allows implementations
   to determine through which session a packet arrived.  "

I have read this several times and think that I am missing an important point.

If I have a stream of UDP data arriving at a host, then I identify that stream
by a 4-tuple of source and destination IP address and port.

If I have a stream of TCP data arriving at a host, then I identify that stream
by a 4-tuple of source and destination IP address and port.

If I have DTLS over UDP or TLS over TCP, then then I identify that stream by a
4-tuple of source and destination IP address and port.

What is the difference?  Given the length of the description of processing
that follows, this is something big, which I am totally missing.

The TCP protocol does not have a session identifier, it uses the 4-tuple of
source and destination IP address and port (as in the TCP MIB module RFC4022:-)

Tom Petch

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 5 Jan 2010 13:31:24 +0100

> source and destination IP address and port (as in the TCP MIB module RFC4022:-)

Common TCP implementations give you a separate socket for each
connection. With UDP, this is usually not the case.

/js

---

From: "David Harrington" <[email-masked]>
Date: Tue, 5 Jan 2010 15:57:04 -0500

Hi,

I prefer the NEW text to the old text, but I am not convinced we need
to discuss multiple principals on a port. 

I have worked on applications that provided support for multiple
principles on a port, particularly for receiving different sets of
traps, and I think this is an engineering implementation decision. It
is really quite simple to use different ports for different
applications; demultiplexing a single port across multiple
applications adds complexity and requires some type of
registration/subscription mechanism. I am not convinced ISMS needs to
address this port-sharing approach, especially since using different
ports is so much easier. If we believe cross-vendor interoperability
for this feature is really important, then we should standardize the
feature more strongly than either the old or new text does. 

I smell significant feature-creep here, and the more complex we make
the transport model, the less likely it will be implemented and
deployed. 

dbh

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Juergen Schoenwaelder
> Sent: Tuesday, January 05, 2010 5:22 AM
> To: Wes Hardaker
> Cc: [email-masked]
> Subject: Re: [Isms] TLSTM -04 draft being published: wraps up 
> all outstanding edits
> 
> _______________________________________________
> Isms mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isms
>

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 05 Jan 2010 16:56:48 -0800

>>>>> On Tue, 5 Jan 2010 13:31:24 +0100, Juergen Schoenwaelder <[email-masked]> said:

JS> Common TCP implementations give you a separate socket for each
JS> connection. With UDP, this is usually not the case.

Exactly; it's an implementation hint.  Others people who are either
implementing it or thinking about it have told me that the description
helped them.

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 05 Jan 2010 16:59:32 -0800

>>>>> On Tue, 5 Jan 2010 11:21:39 +0100, Juergen Schoenwaelder <[email-masked]> said:

>> defined in Section 3.1 of [RFC4366].

JS> Speaking as technical contributor, I like this proposed NEW text.

I like it a lot better because we really shouldn't care how it's done
per say, just that it can be.  I've changed my local copy (but can
obviously change it back if others have issues with it).

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 05 Jan 2010 17:01:02 -0800

>>>>> On Tue, 5 Jan 2010 11:41:26 +0100, "tom.petch" <[email-masked]> said:

tp> I don't understand that comment

tp> Section 5.2 has a sub-section 5 which then has sub-sub-sections 4b and 4a.;
tp> there are no sub-sub-sections 1, 2, 3; looks odd - I would have made the
tp> sub-sub-sections just a) and b) as secshell did.

Ahh....  Gotcha.  fixed!  Thanks!
-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 05 Jan 2010 23:29:00 -0500

--On Tuesday, January 05, 2010 01:31:24 PM +0100 Juergen Schoenwaelder 
<[email-masked]> wrote:

>> The TCP protocol does not have a session identifier, it uses the 4-tuple
>> of source and destination IP address and port (as in the TCP MIB module
>> RFC4022:-)
>

Also, TCP identifies connections by a pair of addresses and ports _at a 
particular point in time_, and its state machine goes to a fair bit of 
effort to insure that there are never two connections named by the same 
5-tuple at the same time.

UDP does no connection tracking, and so does not inherently provide a way 
to tell whether a received message is part of the "same" connection as some 
previous message.

---

From: "tom.petch" <[email-masked]>
Date: Wed, 6 Jan 2010 10:06:33 +0100

----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
Sent: Tuesday, January 05, 2010 1:31 PM

> On Tue, Jan 05, 2010 at 12:01:33PM +0100, tom.petch wrote:
<snip>
> connection. With UDP, this is usually not the case.

Right, so what we are talking about here is an implementation specific detail
for some of the currently available DTLS over UDP libraries.  Should that not
belong in an appendix, with just a line or two here that a session is identified
by these parameters and for one way to achieve this, see appendix?

Tom Petch

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 6 Jan 2010 12:16:01 +0100

On Wed, Jan 06, 2010 at 10:06:33AM +0100, tom.petch wrote:
 
> Right, so what we are talking about here is an implementation
> specific detail for some of the currently available DTLS over UDP
> libraries.  Should that not belong in an appendix, with just a line
> or two here that a session is identified by these parameters and for
> one way to achieve this, see appendix?

I do not really care much but I also do not see the big difference
whether the text is inline or in an appendix. What do you think does
improve by moving this to an appendix?

/js

---

From: "tom.petch" <[email-masked]>
Date: Wed, 6 Jan 2010 10:37:27 +0100

----- Original Message -----
From: "Jeffrey Hutzelman" <[email-masked]>
To: "Juergen Schoenwaelder" <[email-masked]>; "tom.petch"
<[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Wednesday, January 06, 2010 5:29 AM
Subject: Re: [Isms] TLSTM -04 draft being published: s5.1.1

> to tell whether a received message is part of the "same" connection as some

Agreed, but this is DTLS over UDP and TLS most definitely has the concept of a
TLS connection, regardless of the underlying UDP, SCTP or TCP.  One could hope
that DTLS over UDP libraries would recognise this and provide a
connection-oriented API at some stage.

I see this detail as an Informative appendix, not a Normative part of the
specification.

Tom Petch

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 06 Jan 2010 07:07:55 -0800

>>>>> On Wed, 6 Jan 2010 10:37:27 +0100, "tom.petch" <[email-masked]> said:

tp> Agreed, but this is DTLS over UDP and TLS most definitely has the
tp> concept of a TLS connection, regardless of the underlying UDP, SCTP
tp> or TCP.  One could hope that DTLS over UDP libraries would recognise
tp> this and provide a connection-oriented API at some stage.

One would hope, yes.  But one of the most popular stacks out there *does
not do this*.  I suspect many other TLS stacks were developed in similar
ways and made internal assumptions about how the underlying transport
handles stuff because the software was written with the state of mind
that it would never run over an unconnected transport.

Anyway, I doubt anything in there actually hurts the document and since
I've received multiple side-comments from peoples saying that it helps I
certainly don't see a reason to remove it.

tp> I see this detail as an Informative appendix, not a Normative part of the
tp> specification.

It's normative because it's *required* that implementations that are
self-handling stuff don't send out multiple DTLS session data through
the same port or else implementations on the other side won't be able to
cope well.
-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 06 Jan 2010 07:10:08 -0800

>>>>> On Tue, 5 Jan 2010 15:57:04 -0500, "David Harrington" <[email-masked]> said:

DH> I smell significant feature-creep here, and the more complex we make
DH> the transport model, the less likely it will be implemented and
DH> deployed. 

Well, I'm not necessarily against removing it per-say.  But I don't
think the current small paragraph describing a hint-ish type text seems
like a complexity hit on the document.
-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: "David Harrington" <[email-masked]>
Date: Wed, 6 Jan 2010 10:39:34 -0500

Hi,

Like Tom, I am a bit concerned about implementation hints being
interspersed with normative text. The draft should be clear and
unambiguous about what is in the standard and what is not.

Moving implementation hints to a separate section or appendix makes
this distinction clear. Another approach would be to prefix each
separate paragraph that contains implementation hints with
"Implementation hint:"

dbh

> Sent: Wednesday, January 06, 2010 6:16 AM
> To: tom.petch
> Cc: [email-masked]

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 06 Jan 2010 08:04:26 -0800

>>>>> On Wed, 6 Jan 2010 10:39:34 -0500, "David Harrington" <[email-masked]> said:

DH> Like Tom, I am a bit concerned about implementation hints being
DH> interspersed with normative text. The draft should be clear and
DH> unambiguous about what is in the standard and what is not.

I'd be happy to mark (preferred) or move (less preferred) any text you
feel needs moved.  Please let me know exactly which text you're thinking
about.

Note that the requirement that a separate port/address combination is
not an implementation hint.  It's a requirement.  Tom seemed to think
that this wasn't required text and was one of the things he suggested
moving to an appendix.  The following text:

   When establishing a new session implementations MUST use a different
   UDP source port number for each connection to a remote destination
   IP- address/port-number combination to ensure the remote entity can
   easily disambiguate between multiple sessions from a host to the same
   port on a server.

is *not* an implementation hint.  It's a hard requirement so that
implementations are even possible.
-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 6 Jan 2010 17:18:17 +0100

> separate paragraph that contains implementation hints with

Can you tell us which part of the text you consider an implementation
hint so that we can easily check and either agree or disagree?

/js

---

From: "tom.petch" <[email-masked]>
Date: Wed, 6 Jan 2010 18:45:09 +0100

----- Original Message -----
From: "Wes Hardaker" <[email-masked]>
Sent: Wednesday, January 06, 2010 5:04 PM

> implementations are even possible.

No, I agree that sessions can only be differentiated by a 5-tuple of protocol,
source/destination port/address (be they UDP or TCP:-).

They differ in that UDP applications may be sloppy in their use of the source
port which makes it impossible to set up a stream of data and libraries may be
careless of the need to pass this information on.

So I would make 5.1.1 something like

"A session over UDP is identified by a unique combination of the remote
address, remote port number, local address and local port number and this
information MUST be available to the Transport Model for each and every incoming
datagram in order to derive the corresponding tlstmSessionID.

Since DTLS may not make this information available, this may require an incoming
datagram to be preprocessed by the Transport Model in order to derive the
tlstmSessionID prior to passing the datagram to DTLS.  One mechanism to achieve
this is described in Appendix ... but any mechanism that achieves the same
result conforms to this specification.

Note too that entities MUST use a unique UDP source port number for each session
(connection?)  to a remote destination IP-
address/port-number combination so that the remote entity can
distinguish one session from another."

The rest of the current 5.1.1 is not wrong and is undoubtedly helpful, as Wes
reports, it just seems more like motherhood than a protocol specification:-) so
I would move it more or less as is to Appendix ...

Incidentally, the DTLS specification sort of recognises this issue with the
paragraph

"   Note that unlike IPsec, DTLS records do not contain any association
   identifiers.  Applications must arrange to multiplex between
   associations.  With UDP, this is presumably done with host/port
   number."

I like the "presumably":-)

Tom Petch

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 06 Jan 2010 17:43:40 -0500

> I like the "presumably":-)

DTLS says "presumably".
TLSTM strenghtens this to MUST.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 7 Jan 2010 08:29:54 +0100

> I would move it more or less as is to Appendix ...

The text you want to move contains elements of procedure like this:

   4)  The UDP packet and the tlstmSessionID are passed to DTLS for
       integrity checking and decryption.

       If the message fails integrity checks or other (D)TLS security
       processing then increment the tlstmDTLSProtectionErrors counter,
       discard and stop processing the message.

I consider text like this not appropriate for a non-normative appendix
since the text details when certain normative counters are incremented.
So if we make this multiplexing non-normative, we need to change what
is counted.

I still don't see what we gain by making this text non-normative. Are
there any concrete systems out there that can't implement the
multiplexing this way?

/js

---

From: "tom.petch" <[email-masked]>
Date: Thu, 7 Jan 2010 11:25:00 +0100

----- Original Message -----
From: "David Harrington" <[email-masked]>
Sent: Tuesday, January 05, 2010 9:57 PM

> the transport model, the less likely it will be implemented and

David

The TLS list, and to some extent the TLS documents, contain many references to
the high cost of establishing a TLS session, in arriving at a MasterSecret.  One
consequence of this is the ability to reuse the MasterSecret to generate
multiple sets of security credentials (which costs less to do) for use in
multiple TLS connections. This is seen as necessary in https: where the client
wants to download multiple objects in parallel.

This function - and DTLS is the same - is probably of no use to SNMP but the
idea that setting up a TLS session is expensive and to be avoided whenever
possible looks more relevant.  Hence the desire to multiplex principals across a
TLS session; yes, it costs the application but saves in TLS.

Tom Petch

---

From: "tom.petch" <[email-masked]>
Date: Thu, 7 Jan 2010 11:42:43 +0100

One of dbh's earlier comments on 5.1.1 was 
dbh So there can be only one DTLS session that exists between two
endpoints?

There cannot be two with different security principals or
different securityLevels?

+ WH: where endpoints is srcaddr/srcport/dstaddr/dstport,
yes. As is described as a MUST in multiple places.

dbh I think that contradicts something I read
earlier about securityLevels and mappings to crypto suites.
+ WH: I don't believe so. Let me know if you find a conflict.

I wonder if dbh had s3.1.2 in mind which says
"   If a suitable interface between the TLS Transport Model and the
   (D)TLS Handshake Protocol is implemented to allow the selection of
   security level dependent algorithms (for example a security level to
   cipher_suites mapping table) then different security levels may be
   utilized by the application."

Clearly not the case for DTLS between a given pair of endpoints.

Tom Petch

---

From: Robert Story <[email-masked]>
Date: Thu, 7 Jan 2010 10:34:57 -0500

On Thu, 7 Jan 2010 11:42:43 +0100 tom.petch wrote:
TP> One of dbh's earlier comments on 5.1.1 was 
TP> dbh So there can be only one DTLS session that exists between two
TP> endpoints?
TP> 
TP> There cannot be two with different security principals or
TP> different securityLevels?
TP> 
TP> + WH: where endpoints is srcaddr/srcport/dstaddr/dstport,
TP> yes. As is described as a MUST in multiple places.
TP> 
TP> dbh I think that contradicts something I read
TP> earlier about securityLevels and mappings to crypto suites.
TP> + WH: I don't believe so. Let me know if you find a conflict.

maybe the last paragraph of 5.3?

-- 
Robert Story
Senior Software Engineer
SPARTA (dba Cobham Analytic Soloutions)

---

From: "David Harrington" <[email-masked]>
Date: Thu, 7 Jan 2010 11:12:09 -0500

Hi,

My earlier comment was about multiple securityLevels multiplexed via
the same port. I am less concerned about multiple principals using the
same port.

I do not think support for multiple security levels is really needed
in TLSTM. It was added to USM, but except for very specific tasks like
non-secure autodiscovery and non-secure Reports, it is not being used
to my knowledge for normal communications. And since USM is
mandatory-to-implement, it makes sense to use USM for these special
non-secure tasks, and use SSHTM and TLSTM only for secure
communications. I question whether support for multiple security
levels is really needed in TLSTM. If not, it is added complexity
without significant corresponding benefit.  

If a single port will be multiplexed for multiple securityLevels, then
we need to make sure that a reduced-security connection doesn't
somehow get used where a secure connection is expected. 

However, as we learned in the SSHTM work, we actually have no way of
knowing the actual securityLevel of an underlying transport session,
unless we have far more access into the underlying transport
processing than we agreed we should have. It is up to the admin to
actually configure the underlying transport to deliver that expected
level of security. So the SNMP engine should always assume a secure
transport model is being used to provide authPriv secure transport,
and make the admin aware of that expectation.

For comparison, this is from RFC 5592:
   The SSH Transport Model determines from SSH the identity of the
   authenticated principal and the type and address associated with an
   incoming message, and provides this information to SSH for an
   outgoing message.  The SSH transport-layer algorithms used to
provide
   authentication, data integrity, and encryption SHOULD NOT be
exposed
   to the SSH Transport Model layer.  The SNMPv3 WG deliberately
avoided
   this and settled for an assertion by the Security Model that the
   requirements of securityLevel were met.  The SSH Transport Model
has
   no mechanisms by which it can test whether an underlying SSH
   connection provides auth or priv, so the SSH Transport Model trusts
   that the underlying SSH connection has been properly configured to
   support authPriv security characteristics.

   An SSH Transport-Model-compliant implementation MUST use an SSH
   connection that provides authentication, data integrity, and
   encryption that meets the highest level of SNMP security
(authPriv).
   Outgoing messages specified with a securityLevel of noAuthNoPriv or
   authNoPriv are actually sent by the SSH Transport Model with
   authPriv-level protection.

dbh

> From: Robert Story [mailto:[email-masked]] 
> Sent: Thursday, January 07, 2010 10:35 AM
> To: tom.petch
> Cc: David Harrington; 'Juergen Schoenwaelder'; 'Wes 
> Hardaker'; [email-masked]
> alloutstanding edits - sessions
>

---

From: "Donati Andrew-MGIA0477" <[email-masked]>
Date: Fri, 8 Jan 2010 09:18:46 -0500

I am in agreement with the following opinion.

dbh> I do not think support for multiple security levels is really
needed in TLSTM. ...
dbh> I question whether support for multiple security levels is really
needed in TLSTM.
dbh> If not, it is added complexity without significant corresponding
benefit.

Andy Donati

---

From: "tom.petch" <[email-masked]>
Date: Wed, 13 Jan 2010 09:49:10 +0100

Juergen

I think that this, like its predecessors, deserves a wider review for what it
says about TLS.  Now that the storm on the TLS list has died down, I would
suggest asking them to review it.

I am concerned that what it says about TLS is not quite right, especially with
the focus of this I-D on authentication. IMO, what it says is not good, but may
be it is good enough; I am unsure.  I do not want details of what goes on under
the covers of TLS but do want a fair representation of what TLS does and does
not offer.

Tom Petch

---

From: "tom.petch" <[email-masked]>
Date: Wed, 13 Jan 2010 09:51:35 +0100

Juergen

Comments by Jeff and Joe prompted me to look into fingerprints which in turn
forced me to read parts of the MIB module.  This is what I found from the bits
of the MIB module I looked at - if I looked at more, I suspect that I would find
more.

1) tlstmCertSpecified OBJECT-IDENTITY
... /value or contains/value or contain/

2) tlstmCertSANRFC822Name
/[email-masked]/[email-masked]/

3a) tlstmCertSANAny
dNSName presumably uses the capitalisation of RFC5280 in which case it should be
'iPAddress' and presumably tlstmCertSANIPAddress, here and in other places.

3b) I agree with Jeff's comment in December that this could be better named.

4) snmpTlstmSessionInvalidServerCertificates OBJECT-TYPE
"I.E.,  a cryptographic validation occurred during certificate
         validation processing."
This seems to be telling me that cryptographic validation occurred during
cryptographic validation:-)

5a) tlstmCertToTSNTable OBJECT-TYPE
"A table listing the X.509 certificates known to the entity..."
Not really, it list fingerprints, which is not the only way they could be
listed; suggest
"A table listing the fingerprints of X.509 certificates known to the entity"

5b)"public certificate (e.g. RFC5280).  "
This seems a bit bald.  Is it a reference? if so make it one, give it a clause.
And why EG; what other examples had the author in mind?

5c) "Subject field but usage of the CommonName field is deprecated."
This sounds to me like a SHOULD NOT.

6) tlstmCertToTSNID OBJECT-TYPE
        "A unique, prioritized index for the given entry."
How are they prioritized, what represents high and what low priority? I am sure
that some people will come to the opposite view to that of the author.

7) tlstmCertToTSNData OBJECT-TYPE
"Axillary "
Has our object tree sprouted axils?

8) -- Lists expected certificate fingerprints to be presented by a DTLS
-- server

Why DTLS and not (D)TLS?  I was going to say client not server, since this
immediately follows the client table but then I realised that this relates to
three objects hence.  If it is going to say 'Lists expected certificate
fingerprints ' then I think that it should immediately precede tlstmAddrTable
not be separated by two other objects.

9) tlstmAddrTable
/columnshould/column should/

10) tlstmAddrServerIdentity OBJECT-TYPE
This references draft-saintandre-tls-server-id-check which goes into detail
about the use of asterisk and about which fields to use, but then includes text
about asterisks with nothing about fields.  This is potentially contradictory
and ambiguous.  Are you saying anything in draft-saintandre-tls-server-id-check
goes, are you saying that draft-saintandre-tls-server-id-check applies unless
overridden by the description clause or what?  Given that
draft-saintandre-tls-server-id-check is still under discussion and yet to be
finalised, this issue needs more attention.

Tom Petch

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 13 Jan 2010 06:56:55 -0800

>>>>> On Wed, 13 Jan 2010 09:49:10 +0100, "tom.petch" <[email-masked]> said:

tp> I think that this, like its predecessors, deserves a wider review
tp> for what it says about TLS.  Now that the storm on the TLS list has
tp> died down, I would suggest asking them to review it.

It should be noted that a TLS WG chair (Joe Salowey) reviewed it already
and his comments have already been responded to.
-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 13 Jan 2010 06:57:50 -0800

>>>>> On Wed, 13 Jan 2010 09:51:35 +0100, "tom.petch" <[email-masked]> said:

tp> Comments by Jeff and Joe prompted me to look into fingerprints which
tp> in turn forced me to read parts of the MIB module.  This is what I
tp> found from the bits of the MIB module I looked at - if I looked at
tp> more, I suspect that I would find more.

Given that these new comments are months beyond the last call, I'll wait
for the WG chairs to decide whether I should address them now or wait
until IETF last call to look at them.
-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 25 Jan 2010 14:02:50 -0800

Thanks again for your various comments on the document; they've
certainly helped improve the overall readability of it.

My responses are prefixed below with "WH:" if you want to search for
them.  The status of each item is as follows:

  DONE:     Suggestion was acted on
  WONTDO:   Nothing was done; refer to the WH: response for reasons why
  DISCUSS:  There is an outstanding question back to you
  ANSWERED: A question was answered but had no action resulting from it

* DONE 1) tlstmCertSpecified OBJECT-IDENTITY 
  ... /value or contains/value or contain/
  + WH: text actually changed entirely (see Dave S's comments)
* DONE 2) tlstmCertSANRFC822Name 
  /[email-masked]/[email-masked]/
  
* DONE 3a) tlstmCertSANAny 
  dNSName presumably uses the capitalisation of RFC5280
  in which case it should be 'iPAddress' and presumably
  tlstmCertSANIPAddress, here and in other places.
  
* WONTDO 3b) I agree with Jeff's comment in December that this 
  could be better named.
  + WH: What could be better named?  Your comment doesn't list what
    you are referring to, nor does it propose alternate names.
* WONTDO 4) snmpTlstmSessionInvalidServerCertificates OBJECT-TYPE 
  "I.E.,  a cryptographic validation occurred during certificate
           validation processing."
  This seems to be telling me that cryptographic
  validation occurred during cryptographic validation:-)
  + WH: Actually I think it points out that
    cryptographic validation failed when doing
    'certificate' processing.  You didn't propose any
    replacement text so I'm not sure what to do in the
    first place since I find the current text sufficient.
  
* DONE 5a) tlstmCertToTSNTable OBJECT-TYPE 
  "A table listing the X.509 certificates known to the
  entity..."
  
  Not really, it list fingerprints, which is not the
  only way they could be listed; suggest "A table
  listing the fingerprints of X.509 certificates known
  to the entity"
  
* ANSWERED 5b)"public certificate (e.g. RFC5280).  " 
  This seems a bit bald.  Is it a reference? if so make
  it one, give it a clause.  And why EG; what other
  examples had the author in mind?
  + WH: It's shying away from specifying that *only* 5280
    path validation procedures must be used; others
    could be appropriate.
* DONE 5c) "Subject field but usage of the CommonName field is deprecated." 
  This sounds to me like a SHOULD NOT.
  + WH: Changed to "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."
* DONE 6) tlstmCertToTSNID OBJECT-TYPE 
  "A unique, prioritized index for the given entry."
                  How are they prioritized, what represents high and
                  what low priority? I am sure that some people will
                  come to the opposite view to that of the author.
  
                  + WH: I added "Lower numbers indicate a higher
                    priority."  (note, however, that it discusses this
                    in other portions of the document.  It's still wise
                    to put the extra text in this DESCRIPTION as well).
* DONE 7) tlstmCertToTSNData OBJECT-TYPE 
  "Axillary "
  Has our object tree sprouted axils?
  + WH: never blindly trust the first replacement choice
    from a spelling checker.
* DONE 8) -- Lists expected certificate fingerprints to be presented by a DTLS 
  -- server

  WH: Actually, I don't think the comment is needed at
  all.  The descriptions in the objects are much better
  than that comment, so I've removed it.
  
* DONE 9) tlstmAddrTable 
  
* DONE 10) tlstmAddrServerIdentity OBJECT-TYPE 
  This references draft-saintandre-tls-server-id-check
  which goes into detail about the use of asterisk and
  about which fields to use, but then includes text
  about asterisks with nothing about fields.  This is
  potentially contradictory and ambiguous.  Are you
  saying anything in
  draft-saintandre-tls-server-id-check goes, are you
  saying that draft-saintandre-tls-server-id-check
  applies unless overridden by the description clause
  or what?  Given that
  draft-saintandre-tls-server-id-check is still under
  discussion and yet to be finalised, this issue needs
  more attention.
  + WH: The text has been changed.  It no longer allows
    for *.example.com.  It still allows for a single
    '*' to indicate accept anything when the
    fingerprint column is specified.  It is illegal,
    now, to have a blank fingerprint column and a
    '*' wildcard though.