Subject: [Isms] (D)TLS question #2: expecting a server side certificate

From: Wes Hardaker <[email-masked]>
Date: Tue, 07 Jul 2009 10:29:43 -0700

As just discussed, when a client (typically using the SNMP-TARGET-MIB)
is opening an outgoing connection it needs to select a client-side
certificate to use when making the connection.

But, it also has to have an expectation of which remote machine it's
connecting to as well.  It shouldn't just connect to any old system that
answers it's call.  It needs to know that the remote system is, in fact,
the responder it was hoping to reach.

This can be done a number of ways:

1) Add additional rows to the snmpTargetAddrTable that specifies a
   hash-type/hash-value column pair to refer to a locally held copy of
   the remote certificate that should be presented.  IE, this requires an
   additional row in an additional table per target.

2) Use one of the more standardized mapping techniques for assuring
   target certificates are ok based on a trust-anchor CA certificate and
   accepted mappings of either the CommonName field (which is commonly
   what web-browsers use, for example) or the subjectAltName field,
   which is what is currently being recommended within the IETF and the
   CN field is actually being deprecated.  See the following draft for
   the current thoughts and details on TLS server side identity checks:

      draft-saintandre-tls-server-id-check-00.txt

   We'd then need to specify the allowable bindings.  In particular,
   we already have the remote entity specified by the
   snmpTargetAddrTAddress variable which pretty much dictates the type
   of lookup that needs to happen in the subjectAltName list.

   The nice advantage of this approach is that it's the one used in
   industry today for other TLS connection types and requires no
   configuration (assuming we're going to stay out of CA-trust-anchor
   configuration because it's out of scope of the charter).

3) A combination of #1 and #2 allowing for both 1:1 X.509 hash
   references to an expected certificate and allowing for 1:1 mapping
   for those folks that don't have control over the certificate
   generation process or have such small installations that they don't
   want to set up anything other than self-signed certificates.

Personally, I'm leaning toward just #2.

Note that the current draft doesn't discuss this much and only hints at
it.  I intend to write up text for #2 unless the WG participants feel
I'm taking the wrong direction in this approach.

-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 7 Jul 2009 12:01:22 -0700

Hi -

> From: "Wes Hardaker" <[email-masked]>
> To: <[email-masked]>
> Sent: Tuesday, July 07, 2009 10:29 AM
> Subject: [Isms] (D)TLS question #2: expecting a server side certificate
>
> 
...

I think there is at least one other possibility.

(4) Use additional column(s) in tlstmParamsTable to hold the information.
Though at first glance this might seem problematic, I believe the weirdness
is no worse than with USM.

Randy

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 07 Jul 2009 15:25:40 -0700

>>>>> On Tue, 7 Jul 2009 12:01:22 -0700, "Randy Presuhn" <[email-masked]> said:

RP> (4) Use additional column(s) in tlstmParamsTable to hold the information.
RP> Though at first glance this might seem problematic, I believe the weirdness
RP> is no worse than with USM.

You know, I half typed that one out and then erased it.  In fact, that's
even what I have written up in my unpublished copy of the draft.

But in hind-site I think it's architecturally wrong with respect to the
TARGET-MIB.  In particular, the target MIB is split in half right now:
the snmpTargetAddrTable is composed of remote destination type
parameters: addresses, ports, timeouts, retries, etc.  IE, things that
may be specific to the remote server.

The snmpTargetParamsTable, which is referenced by the
snmpTargetAddrTable table and by extension the tlstmParamsTable, is
designed for storing client-side connection information (security model,
security name, etc).

Right now, you have to have one row in the snmpTargetAddrTable for each
row remote target.  But you only need one row in the
snmpTargetParamsTable and the tlstmParamsTable if you only have one set
of client-side credentials to use.

Putting the server side certificate information into the
tlstmParamsTable would change this such that a new row would be required
in the tlstmParamsTable for each remote target, which I think is not a
good model.  And I think it breaks how the original target mib storage
model was designed.  Hence the reason I didn't include it.  But you're
right that if we want to be complete it is an option.
-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 07 Jul 2009 18:52:01 -0400

> right that if we want to be complete it is an option.

I am inclined to suggest that server certificate validation be done in the 
usual fashion, by comparing the CN and/or dnsName in the certificate the 
server presents to the configured server name, and that the issues of 
certificate validation, trust anchor selection, and handling of exceptional 
cases are all best handled by the implementation and/or its certificate 
store and really should be out of scope for the present specification.

If someone wants to write a MIB to maange certificate stores, great.
But that work is not within the current or proposed scope of ISMS.

-- Jeff

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 07 Jul 2009 16:35:29 -0700

>>>>> On Tue, 07 Jul 2009 18:52:01 -0400, Jeffrey Hutzelman <[email-masked]> said:

JH> I am inclined to suggest that server certificate validation be done in
JH> the usual fashion, by comparing the CN and/or dnsName in the
JH> certificate the server presents to the configured server name, and
JH> that the issues of certificate validation, trust anchor selection, and
JH> handling of exceptional cases are all best handled by the
JH> implementation and/or its certificate store and really should be out
JH> of scope for the present specification.

Just to be sure you agree: that's functionally option #2 and the one I
suggested.  I'd add a bit of detail stating that's how it's expected,
though you're right that adding "implementation dependent" is probably
ok.  I think I'd lean toward a standard implementation expectation though.

JH> If someone wants to write a MIB to maange certificate stores, great.
JH> But that work is not within the current or proposed scope of ISMS.

Right.  I agree.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 07 Jul 2009 19:47:31 -0400

--On Tuesday, July 07, 2009 04:35:29 PM -0700 Wes Hardaker 
<[email-masked]> wrote:

> Just to be sure you agree: that's functionally option #2

Yes, with the proviso that the implementation might provide features like 
the ability to map a server name to a specific certificate, whether or not 
that certificate would pass the normal validation process.

The tricky bit here is that in reality, such exceptions are far more 
commonplace than we'd like, and while the usual model for web browsers is 
to handle them interactively, that won't fly for SNMP NO's.

I wonder if PKIX could be convinced to take up the work of specifying a 
certificate store MIB.

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 07 Jul 2009 17:15:09 -0700

>>>>> On Tue, 07 Jul 2009 19:47:31 -0400, Jeffrey Hutzelman <[email-masked]> said:

JH> Yes, with the proviso that the implementation might provide features
JH> like the ability to map a server name to a specific certificate,
JH> whether or not that certificate would pass the normal validation
JH> process.

Ah, which is like an implementation dependent version of the features
#3.  I'm good with that.

JH> The tricky bit here is that in reality, such exceptions are far more
JH> commonplace than we'd like, and while the usual model for web browsers
JH> is to handle them interactively, that won't fly for SNMP NO's.

Agreed, which is why I even suggested #3 which in spec implementation
would look like:

A) A new table extension to the snmpTargetAddrTable that did hash
   reference specifying of a cert.  The certificates matching the hashes
   would be stored out of ISMS WG specifications in an implementation or
   future-defined method.

B) If no match is found in the above table, then the CommonName or
   subjectAltName style match would be checked.  (order actually doesn't
   matter; either check regardless of ordering would still be a success)

Opinions sought if this would be better than just option #2, which was
functionally just B without the A component.
-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 7 Jul 2009 17:43:08 -0700

Hi -

> To: "Randy Presuhn" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Tuesday, July 07, 2009 3:25 PM
> Subject: Re: (D)TLS question #2: expecting a server side certificate
>

I'm not wild about it as a model.  However, the target mib *already* has
this property.  Think about the USM symmetric keys needed in a
notification originator.  To prevent one compromised notification
receiver from impersonating another, it's necessary to give each one
its own set of securityNames for the notification receiver role.

To get around this, you could use another table INDEXed by
snmpTargetAddrName (*NOT* snmpTargetParamsName)
to hold the information.

Randy

and

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 08 Jul 2009 07:38:56 -0700

>>>>> On Tue, 7 Jul 2009 17:43:08 -0700, "Randy Presuhn" <[email-masked]> said:

RP> I'm not wild about it as a model.  However, the target mib *already* has
RP> this property.  Think about the USM symmetric keys needed in a
RP> notification originator.  To prevent one compromised notification
RP> receiver from impersonating another, it's necessary to give each one
RP> its own set of securityNames for the notification receiver role.

Yes, but doing that for server addresses would do it for every type of
connection.  Right now you need different secNames only when using
INFORMs.  Adding server parameters to the snmpTargetParamsTable (via an
extension table) would require it for all types of messages.  That would
affect TRAPs and command messages generated via the disman-event-mib, eg.

RP> To get around this, you could use another table INDEXed by
RP> snmpTargetAddrName (*NOT* snmpTargetParamsName)
RP> to hold the information.

Um, yeah.  That's what I said in the original message!
-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 8 Jul 2009 11:13:42 -0700

Hi -

> Sent: Wednesday, July 08, 2009 7:38 AM

This same issue exists with USM.

> Um, yeah.  That's what I said in the original message!

:-)  It would be interesting to think through how the event or expression MIBs
would work with this.  Maybe we should invoke Bob Stewart.

Randy

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 08 Jul 2009 11:22:06 -0700

>>>>> On Wed, 8 Jul 2009 11:13:42 -0700, "Randy Presuhn" <[email-masked]> said:

>> affect TRAPs and command messages generated via the disman-event-mib, eg.

RP> This same issue exists with USM.

No, for USM you can have an identical security name as a single row (1)
in the params table for the remote agents and many different rows (N) in
the USM table.  With the hash of the remote certificate in the params
table you'd need N rows in the parms table and N rows in the params
extension table.  That's worse.

RP> :-) It would be interesting to think through how the event or
RP> expression MIBs would work with this.  Maybe we should invoke Bob
RP> Stewart.

I actually have thought about it actually, but the details of my
thoughts haven't been transcribed to 1s and 0s.
-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 8 Jul 2009 11:54:41 -0700

Hi -

> Sent: Wednesday, July 08, 2009 11:22 AM
...
> extension table.  That's worse.

But it's the snmpTargetAddrTable that determines where that securityName
gets sent, and the usmUserTable (indexed by BOTH usmUserEngineID and
usmUserName) for the key.

The idea behind the snmpTargetParamsTable was to avoid duplicating
a lot of information in snmpTargetAddrTable, and only hold the bits that
would likely be identical for multiple entries in the snmpTargetAddrTable.

It sounds like the requirements for the remote certificates are more
like those of some of the bits in the usmUserTable.  Its entries do
not exist 1:1 with either the snmpTargetAddrTable or the
snmpTargetParamsTable.  The problem, though, is whether you'd
have access to an engineID in addition to the securityName for indexing.

Randy

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 08 Jul 2009 13:51:36 -0700

>>>>> On Wed, 8 Jul 2009 11:54:41 -0700, "Randy Presuhn" <[email-masked]> said:

RP> The idea behind the snmpTargetParamsTable was to avoid duplicating
RP> a lot of information in snmpTargetAddrTable, and only hold the bits that
RP> would likely be identical for multiple entries in the snmpTargetAddrTable.

Why does it sound like we're agreeing not disagreeing?

RP> It sounds like the requirements for the remote certificates are more
RP> like those of some of the bits in the usmUserTable.  Its entries do
RP> not exist 1:1 with either the snmpTargetAddrTable or the
RP> snmpTargetParamsTable.

They're *possibly* 1:1 for the snmpTargetAddrTable for every row that
is a (D)TLS domain and address.

[the exception being is if we allow for the CommonName or subjectAltName
mapping, then you don't need a TLS specific row]

RP> The problem, though, is whether you'd have access to an engineID in
RP> addition to the securityName for indexing.

There is no need for an security engineID in (D)TLS land.  Or ISMS
land for that matter.

The important question that needs answering though is:

  Should we even provide MIB instrumentation for 1:1 address->server-X.509
  support or not.

If the answer is "no we should not" then the whole discussion is moot anyway.

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 8 Jul 2009 14:44:55 -0700

Hi -

> Sent: Wednesday, July 08, 2009 1:51 PM
...
> Why does it sound like we're agreeing not disagreeing?

Probably because you're convincing me as you walk me through your reasoning.  :-)

> is a (D)TLS domain and address.

I think we're in violent agreement here - that this stuff would be more
closely associated with the snmpTargetAddrTable than with the
snmpTargetParamsTable.

(FWIW, this is a great example of how the factoring of the target MIB was
affected by the USM design, even though the intent was to keep
them decoupled.)

...
> If the answer is "no we should not" then the whole discussion is moot anyway.

The only good reason I can see for doing it is if there were an operational
requirement to deliver or remove them using SNMP.  Would doing so make
initial setup, provisioning, or deployment easier?  I think the spirit of ISMS
would be to say "no", but I think the operational case of the node which is
primarily a notification generator would need to be worked through.

Randy

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 09 Jul 2009 10:40:37 -0700

>>>>> On Wed, 8 Jul 2009 14:44:55 -0700, "Randy Presuhn" <[email-masked]> said:

RP> I think we're in violent agreement here - that this stuff would be more
RP> closely associated with the snmpTargetAddrTable than with the
RP> snmpTargetParamsTable.

I'm glad we're in agreement then!

>> Should we even provide MIB instrumentation for 1:1
>> address->server-X.509 support or not.
>> 

RP> The only good reason I can see for doing it is if there were an
RP> operational requirement to deliver or remove them using SNMP.  Would
RP> doing so make initial setup, provisioning, or deployment easier?  I
RP> think the spirit of ISMS would be to say "no", but I think the
RP> operational case of the node which is primarily a notification
RP> generator would need to be worked through.

Operationally, the certificate still needs to be uploaded as well, which
I think is generally considered to be out of scope.  So even if we do
provide a MIB it's not necessarily a complete solution (but we'd be
providing "our half" of the responsibility and would still allow a
certificate store to be present and referenced, which would be better
than nothing).

So it's unclear from the above if you have an opinion.  It sounds like
you're on the fence?

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 9 Jul 2009 11:06:27 -0700

Hi -

> Sent: Thursday, July 09, 2009 10:40 AM
...
> So it's unclear from the above if you have an opinion.  It sounds like

I think a "half solution"  would miss the whole point of why the isms work
was chartered in the first place.

>From my perspective, the issue isn't whether SNMP is used to deliver
the information, but rather that the isms documents address the whole problem.
If there is a standardized way to deliver the certificates, we should reference it.
If there isn't, then we need to provide a mechanism to support delivering the
certificates for the (D)TLS transport of SNMP.  (I agree that solving the
certificate delivery problem in full generality would be out of scope.)  Otherwise,
we're leaving implementors and those trying to deploy this with an "and then
a miracle occurs" solution.  If folks really believe the charter prevents the WG
from addressing the problem, then the draft should go right out and say
"there's this big ol' hole where certificate delivery should be, and you'll
have to invent something to put there to get this to work."

Providing a way to deposit the necessary certificates using SNMP
seems to be an obvious and straightforward way to plug that hole.
It doesn't go as far as I think the spirit of isms should take it (remember,
objections to the amount of provisioning necessary to prepare
an SNMP engine for use in an operational network triggered this
work) but it would be better than nothing.  Exposing the information
as a MIB could make it possible, for example, to remove certificates
deposited by other means.  I don't know whether that would be a
bug or a feature.

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 9 Jul 2009 20:28:07 +0200

On Thu, Jul 09, 2009 at 08:06:27PM +0200, Randy Presuhn wrote:
 
> the information, but rather that the isms documents address the
> whole problem.  If there is a standardized way to deliver the
> certificates, we should reference it.  If there isn't, then we need
> to provide a mechanism to support delivering the certificates for
> the (D)TLS transport of SNMP.  (I agree that solving the certificate
> delivery problem in full generality would be out of scope.)
> Otherwise, we're leaving implementors and those trying to deploy
> this with an "and then a miracle occurs" solution.  If folks really
> believe the charter prevents the WG from addressing the problem,
> then the draft should go right out and say "there's this big ol'
> hole where certificate delivery should be, and you'll have to invent
> something to put there to get this to work."
>

Most operators know how to deal with SSH keys or [D]TLS certificates.
As far as I recall, the reason why operators did not like USM was that
it is yet another key management system they have to deal with. The
fact that USM has an SNMP way of managing keys did not make it fly too
high either. I agree with Joe that we are better served not to solve
certificate management issues - like we decided not to solve SSH key
management issues. (Me speaking as a technical contributor.)

/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: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 09 Jul 2009 14:42:58 -0400

> management issues. (Me speaking as a technical contributor.)

Note also that the goal of ISMS is not just "make it easier", but "make it 
work with our existing infrastructure".  That means eliminating the n*m 
keying explosion of USM in favor of using existing enterprise 
authentication mechanisms for both users and hosts, whether that's RADIUS, 
Kerberos, PKI, leap-of-faith, or some combination.  In any case, _managing_ 
that infrastructure is not just "not in our charter"; it's actually out of 
scope -- we don't have enough of the expertise for it.

I don't think it's appropriate to develop an ISMS-specific approach to 
using SNMP to manage certificate stores.  Management of certificate stores 
should be done in a standardized way, not tied to a particular application, 
and the expertise for doing it right lies in PKIX, not here.

-- Jeff

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 9 Jul 2009 14:59:37 -0700

Hi -

> From: "Jeffrey Hutzelman" <[email-masked]>
> To: "Juergen Schoenwaelder" <[email-masked]>; "Randy Presuhn" <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>
> Sent: Thursday, July 09, 2009 11:42 AM
> Subject: Re: [Isms] (D)TLS question #2: expecting a server side certificate
...
...

It would be fine with me if we just had a pointer to the appropriate RFC
indicating how it should be done.  My point is that it should not be left
to the reader's imagination.  If there is no specification for us to point to,
then the work here is not standardization, but rather just wishful thinking.

Randy

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 09 Jul 2009 15:09:35 -0700

>>>>> On Thu, 9 Jul 2009 14:59:37 -0700, "Randy Presuhn" <[email-masked]> said:

RP> It would be fine with me if we just had a pointer to the appropriate
RP> RFC indicating how it should be done.  My point is that it should
RP> not be left to the reader's imagination.  If there is no
RP> specification for us to point to, then the work here is not
RP> standardization, but rather just wishful thinking.

There are some CA based mapping systems we can point to (as I've
noted).  It's just a standardized certificate uploading process that
isn't.  If we're fine with just the CA CommonName/subjectAltName mapping
then we have something to point to.  It's only if we want to support a
hash pointing to a unique X.509 cert that we either have to say the
installation of that certificate is out of scope or we don't do it (or
we work with a group where it is in scope).

I don't think that it's a waste of time if we want to go to the halfway
point and use a hash reference but not specify how the certificate
itself is uploaded.  It's completing some of the work.  Netconf has yet
to produce a fully working system of specifications but I wouldn't say
their effort has been wasted just because they haven't completed their
definitions yet.  The same goes for this situation: half-way is still
better than no-way.

[aside: at some point there is *always* a bootstrapping problem that you
have to fall down on, be it certificates or ssh keys or ...  At some
point you have to plug in the box, turn on the device and touch it via a
human controlled first-certificate upload process or password setting
process that is not standardized because it falls on the native physical
interface system to make that happen]

[if we were to standardize on an upload system, the easiest one would
probably be a URL reference to go fetch it from; bootstrapping of the
first certificate to validate the first URL pull would still be up to
the initial install though]

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 09 Jul 2009 22:07:04 -0400

--On Thursday, July 09, 2009 02:59:37 PM -0700 Randy Presuhn 
<[email-masked]> wrote:

>> To: "Juergen Schoenwaelder" <[email-masked]>;
>> "Randy Presuhn" <[email-masked]> Cc: <[email-masked]>;
>> <[email-masked]>
>> using SNMP to manage certificate stores.  Management of certificate
>> stores  should be done in a standardized way, not tied to a particular
>> application,  and the expertise for doing it right lies in PKIX, not
>> here.
> ...
>
> to the reader's imagination.  If there is no specification for us to
> point to, then the work here is not standardization, but rather just
> wishful thinking.

It turns out that it is useful to have standards describing how license 
plates are formatted, what information they contain, how they are affixed 
to the vehicle is useful, and even requiring their use by all vehicle 
owners -- even though there is no standard specifying how they are 
distributed to the vehicle owner.

Provisioning certificates is not the same as provisioning USM keys.  A 
device generally needs to know only about approximately two certificates -- 
its own and that of a CA which signs the certificates of the entities it 
talks to.  Defining a secure transport model using certificates furthers 
ISMS's goals by making it possible for operators to use their existing 
infrastructure to provision each device and each user, rather than 
provisioning each user on each device, and each NG on each NR, and so on.

The reality is that certificate management is already widely deployed, it 
is highly implementation-dependent, and as Wes notes, it is frequently part 
of the bootstrapping process.  Leaving this problem up to the implementors 
is _not_ wishful thinking; they have largely already solved it.  Wishful 
thinking would be designing an ISMS certificate store MIB that no one ever 
uses because it fails to meet anyones actual needs or be consistent with 
implementors certificate management strategies.

-- Jeff

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 9 Jul 2009 19:39:42 -0700

Hi -

> To: "Randy Presuhn" <[email-masked]>; <[email-masked]>
> Cc: <[email-masked]>
> Sent: Thursday, July 09, 2009 7:07 PM
...
...

Then the document should simply say something like:

    How certificates are delivered, installed, and managed is
    implementation-dependent, and outside the scope of this
    memo.

and declare victory.

Randy

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 10 Jul 2009 10:46:39 -0700

>>>>> On Thu, 9 Jul 2009 19:39:42 -0700, "Randy Presuhn" <[email-masked]> said:

RP> Then the document should simply say something like:

RP> How certificates are delivered, installed, and managed is
RP> implementation-dependent, and outside the scope of this
RP> memo.

[there actually is similar text in there now, but I like your wording so
may replace it with yours]

I think that consensus on this has been pretty much reached and I'll
summarize below

* We won't be defining a certificate management process [with text
  similar to the above]
* We will be at least referring to how snmp address datatypes should be
  used for the CommonName/subjectAltName server-side certificate
  comparison and will reference another document describing the details
  of how those comparisons are done.
* We will only be relying on CommonName/subjectAltName mapping and not a
  hash-reference for the standardized TLSTM work.  We won't prohibit an
  implementation for offering other implementation-dependent mapping
  functionality, though.

---

From: "Purvis, Ray" <[email-masked]>
Date: Fri, 10 Jul 2009 07:53:09 -0400

Hi,

Well said.  I like the approach Wes currently has of seeing the loaded certs using hashed references, this is universal no matter how they got there.  In my own little world we have our own methods, as Jeff points out, of delivering the certs, and really don't require an ISMS specific method....but that's just us!  We may require SNMP managed methods of handling our delivery process, but, imho, that shouldn't be an ISMS MIB.  My 2 cents....

Ray

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jeffrey Hutzelman
Sent: Thursday, July 09, 2009 9:07 PM
To: Randy Presuhn; [email-masked]
Cc: [email-masked]
Subject: Re: [Isms] (D)TLS question #2: expecting a server side certificate

-- Jeff
_______________________________________________
Isms mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isms

---

From: "David Harrington" <[email-masked]>
Date: Sat, 11 Jul 2009 19:59:54 -0400

Hi,

syslog/TLS requires implementation of self-signed certs for when a PKI
system is not available (either by configuration choice or because the
device has not yet established conectivity to the PKI).

I am no expert in PKI and TLS, but my understanding is we have this is
in syslog because SamH insisted that a non-PKI solution MUST be
available (when syslog/TLS became a MUST to meet congestion control
demands of the transport ADs). Pasi agreed and liked the
fingerprint/self-signed certs for when PKI was not available.

If I have this wrong, I invite correction by Sam and/or Pasi.

Without making this a MUST implement for SNMP as well, an SNMP system
not co-resident with a syslog system might not support the self-signed
certs, and that means operators would need to use a different
configuration for the TLS for SNMP-alone vs SNMP+syslog. I think that
indirectly defeats the purpose of ISMS, which is to simplify the
security configuration needed for SNMP. Woudn't it be simpler to
mandate implementation of (but not use of) self-signed certs for
SNMP/TLS as well?

dbh

> From: Wes Hardaker [mailto:[email-masked]] 
> Sent: Saturday, July 11, 2009 1:20 PM
> To: David Harrington
> Cc: 'Wes Hardaker'
> >>>>> On Sat, 11 Jul 2009 10:31:12 -0400, "David Harrington" 
> <[email-masked]> said:
> 
> DH> I was thinking of End-entity certificate matching, using 
> fingerprints,
> DH> as described in 4.2.2. "This method provides an 
> alternative to a PKI
> DH> that is simple to deploy and still maintains a reasonable level
of
> DH> security.
> DH> Both transport receiver and transport sender implementations
MUST
> DH> provide means to generate a key pair and self-signed 
> certificate in
> DH> the case that a key pair and certificate are not available
through
> DH> another mechanism." 
> 
> Ah, but see that's basically what we've been talking about (but have
> also been talking about MIB support around it).  I think ISMS has
> functionally agreed that the subjectAltName is a MUST but we're not
> going to prohibit the above (and thus it becomes a MAY). 
> 
> -- 
> Wes Hardaker

---

From: Wes Hardaker <[email-masked]>
Date: Sun, 12 Jul 2009 21:22:45 -0700

>>>>> On Sat, 11 Jul 2009 19:59:54 -0400, "David Harrington" <[email-masked]> said:

DH> Woudn't it be simpler to mandate implementation of (but not use of)
DH> self-signed certs for SNMP/TLS as well?

I think you bring up a lot of good points and I suspect that this
discussion will roll into the meeting at this point, but that's a good
thing.  I'll make sure to have slides available to talk about it (and in
fact, I already do).

It'd probably take me less work to implement the MIB than it would to
argue about whether we should do it or not ;-)
-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: "tom.petch" <[email-masked]>
Date: Tue, 14 Jul 2009 15:07:27 +0200

----- Original Message ----- 
From: "David Harrington" <[email-masked]>
To: "'Wes Hardaker'" <[email-masked]>; <[email-masked]>
Sent: Sunday, July 12, 2009 1:59 AM
> mandate implementation of (but not use of) self-signed certs for

I agree; we should at least keep syslog and SNMP in line.

I would also encourage anyone listening in to join 
[email-masked]
and press for this in the server identification draft, 
draft-hodges-server-ident-check
Some on that list are pushing for an http, TLS, PKI solution only,
whereas I see the I-D as an opportunity to introduce a much-needed,
wider coherence to the IETF.

Tom Petch

---

From: <[email-masked]>
Date: Mon, 27 Jul 2009 10:34:24 +0200

> If I have this wrong, I invite correction by Sam and/or Pasi.

In syslog, syslog-over-tls is the mandatory-to-implement transport,
and the only currently specified security mechanism. However, for ISMS
we already have SSHTM that can be used without PKI, so requiring a PKI
for DTLSTM is not totally unreasonable.

Nevertheless, I think supporting fingerprints (like in syslog) in
DTLSTM would be quite useful, and I'd support including it in the
draft.

Best regards,
Pasi