Subject: Re: [Isms] draft-hardaker-isms-dtls-tm-05 submitted - tlstmNotifications

From: "Donati Andrew-MGIA0477" <[email-masked]>
Date: Mon, 14 Sep 2009 12:40:38 -0400

Wes,

Will it be feasible to define optional notifications for each the 
events defined by the counters below ?

tlstmSessionInvalidClientCertificates
tlstmSessionInvalidServerCertificates 

- Andy Donati
  Motorola HN&M

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Wes Hardaker
Sent: Wednesday, June 24, 2009 12:30 PM
To: [email-masked]
Subject: [Isms] draft-hardaker-isms-dtls-tm-05 submitted

I've just posted an updated version of my DTLS draft.  I've left the
name the same until it becomes a WG document after the charter is
approved, at which point I'll drop the 'd' in the draft title so it's
just '-tls'.

The biggest change in this version of the draft is the incorporation of
the straight TLS transport in addition to the DTLS transport previously
described.  Most of the text changes are very straight forward as the
text was fairly generically pointed to TLS related features in the first
place.  In a few places, however, TLS or DTLS are specifically called
out.

  http://www.ietf.org/internet-drafts/draft-hardaker-isms-dtls-tm-05.txt

--
Wes Hardaker
Cobham Analytic Solutions
_______________________________________________
Isms mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isms

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 14 Sep 2009 10:36:55 -0700

>>>>> On Mon, 14 Sep 2009 12:40:38 -0400, "Donati Andrew-MGIA0477" <[email-masked]> said:

DA> Will it be feasible to define optional notifications for each the 
DA> events defined by the counters below ?

DA> tlstmSessionInvalidClientCertificates
DA> tlstmSessionInvalidServerCertificates 

I think it's a good idea to have notifications defined for those two
cases.  The likely triggering points would be:

1) tlstmSessionInvalidClientCertificates

   - command responder, notification responder or proxy application
     receives a client cert it can't cope with.

2) tlstmSessionInvalidServerCertificates

   - a command generator in a remote device (e.g., disman-event mib type
     functionality or ...) or proxy application receives a server cert
     it can't cope with.

   - in theory a local manager could trigger this condition too, but it
     doesn't make as much sense.  There is no reason to say they can't
     send it though.

The interesting question is that for #1, we actually already have such a
notification in a more generic form:  the authenticationFailure
notification from the SNMPv2-MIB.  The questions in my mind are:

A) should we include a more specific one for DTLS
B) should we specify in the documentation other likely (recommend)
   DTLS specific variables to add to the generic authenticationFailure
   notification when being sent?

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 14 Sep 2009 20:29:18 +0200

>      doesn't make as much sense.  There is no reason to say they can't

The question is to what extend the SNMP agent is really involved in
all this or whether the DTLS transport takes care of the processing
itself. In the SNMP over SSH case, we did decide to stay out of things
that really concern the SSH layer. It seems with TLS/DTLS, we seem to
go into much more details - perhaps this is even justified. I just
notice that we seem to deal with these different secure transports
differently.

/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, 14 Sep 2009 12:02:00 -0700

>>>>> On Mon, 14 Sep 2009 20:29:18 +0200, Juergen Schoenwaelder <[email-masked]> said:

JS> The question is to what extend the SNMP agent is really involved in
JS> all this or whether the DTLS transport takes care of the processing
JS> itself. In the SNMP over SSH case, we did decide to stay out of things
JS> that really concern the SSH layer. It seems with TLS/DTLS, we seem to
JS> go into much more details - perhaps this is even justified. I just
JS> notice that we seem to deal with these different secure transports
JS> differently.

I'd argue that if it helps the operator it doesn't matter much.  We're
not violating layers because we want to help manage a transport just as
we're not violating layers when we send a linkUp notification (which if
you drew an architectural diagram, would be way outside the SNMPv3
blocks).

In other words, do we want managers to be able to get notifications
about failed (D)TLS connections?  If yes, then we need to define the
notifications and it's implementation specific as to how to detect the
need to send them.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 14 Sep 2009 15:08:56 -0400

--On Monday, September 14, 2009 12:02:00 PM -0700 Wes Hardaker 
<[email-masked]> wrote:

>>>>>> On Mon, 14 Sep 2009 20:29:18 +0200, Juergen Schoenwaelder
>>>>>> <[email-masked]> said:
>

Agree.  We're not talking here about the SNMP agent breaking layers and 
looking at things it has no business knowing about.  We're talking about 
the (D)TLS transport itself being manageable.

-- Jeff

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 14 Sep 2009 22:14:19 +0200

> the (D)TLS transport itself being manageable.

But in the case of SSH, we decided to _not_ go into SSH details and
leave that to future SSH management work. I just noticed that we seem
to treat TLS/DTLS different. I am not saying this is good or bad (and
I am speaking as a technical contributor). All I want to achieve is
that we reflect the reasons if we do things differently for different
transports.

/js

---

From: "David Harrington" <[email-masked]>
Date: Mon, 14 Sep 2009 16:28:26 -0400

Hi,

It looks to me like we *would* be violating layers.

If (D)TLS gets an invalid certificate, will it still pass the payload
to SNMP?
If (D)TLS gets an invalid certificate during the "service
authorization" step, will it even start the SNMP service?

In SSHTM, we document what we know after asking for a session to be
opened or closed - i.e., it failed. We make the assumption we can tell
whether the failure was a user-authentication failure or a
server-authentication failure or a channel-open failure or a subsystem
failure. We do not assume we know what authentication method was used
when authentication failed; we have one error counter for userauth
failure and another for serverauth failure, whether SSH used passwords
or certificates or some other method to perform the authentication.

I think the InvalidClientCertificate and InvalidServercertificate
counters cross the line into (D)TLS specific processing.

If you want insight into what is happening at the (D)TLS "layer", then
you should write a (D)TLS MIB to capture that information. That does
not belong in the transport model though, just as the specific SSH
failures do not get documented in the SSHTM MIB. 

Think of it this way. If you write a generic (D)TLS MIB that recorded
InvalidClientCertificates and InvalidServercertificates, would these
only be incremented when SNMP was the protocol utilizing the (D)TLS
service, or might they also be incremented when using, say, IPFIX or
Netconf or HTTP? I think these are (D)TLS-specific errors, not
SNMP-TM-specific errors.

dbh

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Jeffrey Hutzelman
> Sent: Monday, September 14, 2009 3:09 PM
> To: Wes Hardaker
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Isms] draft-hardaker-isms-dtls-tm-05 submitted 
> - tlstmNotifications
>

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 14 Sep 2009 16:52:31 -0400

> Netconf or HTTP? I think these are (D)TLS-specific errors, not

There really isn't such a thing as "_the_ (D)TLS service".  A given host 
might have any number of services utilizing TLS or DTLS on different ports 
with different configuration.  It's not multiplexed the way SSH might be, 
and you wouldn't want to combine management information for them.  Ideally, 
there'd be some kind of "MIB fragment" describing (D)TLS which could be 
incorporated into MIB's for various services using those protocols, of 
which the SNMP DTLS TM is just one.

---

From: "David Harrington" <[email-masked]>
Date: Mon, 14 Sep 2009 16:56:16 -0400

If one were to implement the DTLS-TM using a DTLS toolkit, would the
SNMP side of the API likely know why that the client certificate was
invalid, or would that likely be internal to the toolkit?

dbh 

> From: Jeffrey Hutzelman [mailto:[email-masked]] 
> Sent: Monday, September 14, 2009 4:53 PM
> To: David Harrington; 'Wes Hardaker'
> Subject: RE: [Isms] draft-hardaker-isms-dtls-tm-05 submitted 
> - tlstmNotifications
>

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 14 Sep 2009 14:07:49 -0700

>>>>> On Mon, 14 Sep 2009 16:56:16 -0400, "David Harrington" <[email-masked]> said:

DH> If one were to implement the DTLS-TM using a DTLS toolkit, would the
DH> SNMP side of the API likely know why that the client certificate was
DH> invalid, or would that likely be internal to the toolkit?

1) Yes.  I've seen the openssl code and know that you can determine this
   exact situation.

2) IMHO, it doesn't matter.  It's not up to us to specify how a service
   gets managed.  As an example, many of the interface counters, for
   example, were put into "exporting data" code in the linux kernel
   because SNMP needed access to them.

   There are only two cases:

   A) A (D)TLS implementation can export the situation already today
      within the existing APIs (such as the case for OpenSSL, as
      mentioned above).

   B) A (D)TLS implementation can not export the data and as far as the
      client goes, it's a silent fail with a generic error.  If this is
      the case, then one of three things must happen:

      i) the SSL implementation implements a mechanism through "some
         manner" so that the invalid-certificate notification can be
         sent by the application using the SSL API.  Maybe through a new
         error code, or whatever.

     ii) the SSL implementation implements an internal "I got a problem"
         event and sends through some aspect to anyone listening.  A
         listener (possibly the SNMP agent application) would listen for
         a problem and send a notification when it received that
         internal software event.

    iii) the SSL implementation won't export the details that a problem
         has occurred problem through any method.  This leaves the SNMP
         agent implementation out of luck as it simply can't send the
         notification at all.  If we think this is possible, wouldn't it
         make more sense to put the notification into an optional
         conformance group than to not put it in at all?

         And eventually, hopefully, all iii)s would eventually
         transition to either i) or ii).

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 14 Sep 2009 23:18:17 +0200

> which the SNMP DTLS TM is just one.

We implemented SNMP over SSH by linking in an SSH library; we do not
go through an sshd and hence assuming SSH is "multiplexed" is not
always correct. This is all implementation choice. I agree that an SSH
MIB or [D]TLS MIB would have to provide proper indexing so that
multiple concurrent SSH or D[TLS] instances can export data to the
SNMP agent.

/js

---

From: "David Harrington" <[email-masked]>
Date: Mon, 14 Sep 2009 17:21:42 -0400

Hi,

Following up on Juergen's and Jeff's comments, I think the document
should explain why this TM does pay attention to
authentication-mechanism-specific errors, as compared to, say, SSH -
IIUC, because TLS does not multiplex services while SSH does.

For interoperability purposes, it is important to know that some
agents might send a notification and count these particular errors,
while others do not, even though both would apparently be considered
compliant. A separate compliance clause might be the right approach
for this. A knob that indicates whether this support is available or
not might be helpful to NMSes.

dbh 

> From: Wes Hardaker [mailto:[email-masked]] 
> Sent: Monday, September 14, 2009 5:08 PM
> To: David Harrington
> Cc: 'Jeffrey Hutzelman'; 'Wes Hardaker'; [email-masked]
> Subject: Re: draft-hardaker-isms-dtls-tm-05 submitted - 
> tlstmNotifications
>

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 14 Sep 2009 15:15:04 -0700

>>>>> On Mon, 14 Sep 2009 17:21:42 -0400, "David Harrington" <[email-masked]> said:

DH> Following up on Juergen's and Jeff's comments, I think the document
DH> should explain why this TM does pay attention to
DH> authentication-mechanism-specific errors, as compared to, say, SSH -
DH> IIUC, because TLS does not multiplex services while SSH does.

I'm not sure it's necessary to document the differences, IMHO.  Each
document should define the objects that are necessary to manage them.  I
don't think a cross-comparison of "why" is necessary.

DH> For interoperability purposes, it is important to know that some
DH> agents might send a notification and count these particular errors,
DH> while others do not, even though both would apparently be considered
DH> compliant.

I agree.  I don't think imposing some of these should be MUSTs in terms
of interoperability, so I agree.  I think putting them in optional
compliance modules alleviates this problem.

DH> A knob that indicates whether this support is available or not might
DH> be helpful to NMSes.

Sadly, we have that knob now in SNMP (agent-capabilities); the problem
is that the solution isn't one that anyone likes to use.  I don't think
it's within the scope of the WG to fix the compliance reporting features
within SNMP itself.  (I'd love to see that work get done generically
somewhere; it's definitely a missing piece of the puzzle)
-- 
Wes Hardaker
Cobham Analytic Solutions