Subject: Re: [Isms] (D)TLS question (#1): selecting a client certificate to use

From: Wes Hardaker <[email-masked]>
Date: Thu, 02 Jul 2009 10:18:27 -0700

>>>>> On Tue, 30 Jun 2009 23:25:26 -0400, "Donati Andrew-MGIA0477" <[email-masked]> said:

Donati,

Thanks for the response and the opinion.

DA> -- Since RowStatus and StorageType are already present the
DA> snmpTargetParams table, it may be conflicting to have these columns
DA> duplicated in the augmenting tlstmParams table.  

I don't think so.  Not every row in the snmpTargetParams table will have
an entry in the tlstmParamsTable so creation needs to be managed
independently.  It could be done either way, you're right but I think it
makes more sense to have a separate creation/deletion object.  Other
opinions are welcome on the subject though.

However, it shouldn't be an AUGMENT in the first place.  I've changed
the next to be an identical copy of the snmpTargetParamsTable index
since it's not a 1:1 mapping, which rules out AUGMENT usage in the first
place.

Regardless the fate sharing needs to be documented better than it is
currently so I'll work on the wording for that.

DA> Note that the tlstmParamsRowStatus description states that "The
DA> value of this object has no effect on whether other objects in this
DA> conceptual row can be modified" and the values for objects in the
DA> snmpTargetParams table cannot be set if the RowStatus is active.

Well, I suppose that I should copy that table's method of modification
method you're right.

DA> -- The tlstmParamsHashValue object may need to have a default value
DA> defined.    

Well, it'd have to default to "" which isn't helpful.  I think I'd
rather state that the row can't be made active unless the values are
legally set.  There is no sensible default value.

How's this for new text for the tlstmParamsRowStatus object:

tlstmParamsRowStatus 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, a manager 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 tlstmParamsRowStatus
        column is 'notReady'.

        In particular, a newly created row cannot be made
        active until the corresponding
        tlstmParamsClientHashType,
        and tlstmParamsClientHashValue have both been set.

        The row may not be made active(1) if the
        tlstmParamsClientHashValue object is not of a length suitable
        for use with the corresponding tlstmParamsClientHashType.

        The following objects may not be modified while the
        value of this object is active(1):
            - tlstmParamsClientHashType
            - tlstmParamsClientHashValue
        An attempt to set these objects while the value of
        tlstmParamsRowStatus is active(1) will result in
        an inconsistentValue error.

        The value of this object has no effect on whether
        other objects in this conceptual row can be modified.

        If this row is deleted it has no effect on the corresponding
        row in the tlstmParamsTable.

	If the corresponding row in the tlstmParamsTable is deleted
	then this row must be automatically removed."

-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: "Donati Andrew-MGIA0477" <[email-masked]>
Date: Thu, 2 Jul 2009 15:12:50 -0400

Wes, 

Thanks for the update.

WH> -- However, it shouldn't be an AUGMENT in the first place.  
WH> -- I've changed the next to be an identical copy of the
snmpTargetParamsTable
WH> -- index since it's not a 1:1 mapping, which rules out AUGMENT usage
in the first place. 

Agreed. ... and if the table is not an AUGMENT, it needs to have it's
own separate
RowStatus and StorageType columns.  

>AD> -- The tlstmParamsHashValue object may need to have a default value
>AD> -- defined.    
WH> -- Well, it'd have to default to "" which isn't helpful.  I think
I'd rather state that the row
WH> -- can't be made active unless the values are legally set.  There is
no sensible default value.
 
You're right. Since tlstmParamsRowStatus will now be in control of it's
own table and the new text in the description clause states that the
value of tlstmParamsClientHashValue needs to meet certain criteria
before being activated, it may not be especially helpful if there is a
DEFVAL clause present. 

WH> -- How's this for new text for the tlstmParamsRowStatus object:

It looks very good.  
If the corresponding row in the tlstmParamsTable is deleted and the row
is automatically removed, I am assuming that setting
tlstmParamsRowStatus to createAndGo(4) or createAndWait(5) returns an
error if the corresponding row in the tlstmParamsTable is not present.
If so, maybe this can be added in the description text ?  I'm not too
sure what the appropriate error code should be in this case
(inconsistentValue ? ) - I'll need to take a closer look at RFC2579.   

Andy Donati
Motorola HN&M

-----Original Message-----
From: Wes Hardaker [mailto:[email-masked]] 
Sent: Thursday, July 02, 2009 1:18 PM
To: Donati Andrew-MGIA0477
Cc: Wes Hardaker; [email-masked]
Subject: Re: (D)TLS question (#1): selecting a client certificate to use

Donati,

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 03 Jul 2009 10:06:44 -0700

>>>>> On Thu, 2 Jul 2009 15:12:50 -0400, "Donati Andrew-MGIA0477" <[email-masked]> said:

DA> If the corresponding row in the tlstmParamsTable is deleted and the
DA> row is automatically removed, I am assuming that setting
DA> tlstmParamsRowStatus to createAndGo(4) or createAndWait(5) returns
DA> an error if the corresponding row in the tlstmParamsTable is not
DA> present.

Good point.  The options are:

1) let the row be created in anticipation of another being created later
   in the snmpTargetPararms table.
2) prohibit it with inconsistentValue, which I agree is the right
   choice.

When deleting, I think it makes sense to auto-remove the column from the
tlstmParamsTable table since it's unlikely you'd want it there in the
future.  But, I don't necessarily think that's true for creation and I
don't see us getting a huge amount of benefit from disallowing the
creation of a row in the tlstmParamsTable table when the row in the
snmpTargetParams doesn't exist.  But you're right, that doesn't feel
consistent either.

Opinions welcome :-)

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 3 Jul 2009 10:34:49 -0700

Hi -

> From: "Wes Hardaker" <[email-masked]>
> To: "Donati Andrew-MGIA0477" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Friday, July 03, 2009 10:06 AM
> Subject: Re: [Isms] (D)TLS question (#1): selecting a client certificate touse
...
> snmpTargetParams doesn't exist.  But you're right, that doesn't feel
...

I'm a bit confused.  Re-reading the thread, it looks like the text under
discussion is this:

-------------

--------

If so, I think the proposed text has a problem.
Most importantly, since tlstmParamsRowStatus is part of
the tlstmParamsTable, the last two sentences of the DESCRIPTION
make no sense.

The real question is whether there should be any "fate sharing"
between it and the snmpTargetParamsTable.  I'd strongly recommend
that there be *no* coupling whatsoever.  This would simplify
implementation, testing, provisioning, and operational use.  I
see no benefits from "fate sharing", and lots of disadvantages.

Randy

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 03 Jul 2009 11:37:20 -0700

>>>>> On Fri, 3 Jul 2009 10:34:49 -0700, "Randy Presuhn" <[email-masked]> said:

WH> If this row is deleted it has no effect on the corresponding
WH> row in the tlstmParamsTable.

WH> If the corresponding row in the tlstmParamsTable is deleted
WH> then this row must be automatically removed."

WH> If so, I think the proposed text has a problem.
RP> Most importantly, since tlstmParamsRowStatus is part of
RP> the tlstmParamsTable, the last two sentences of the DESCRIPTION
RP> make no sense.

You're right.    "tlstmParamsTable" in both those paragraphs should be
"targetParamsTable".

RP> The real question is whether there should be any "fate sharing"
RP> between it and the snmpTargetParamsTable.  I'd strongly recommend
RP> that there be *no* coupling whatsoever.  This would simplify
RP> implementation, testing, provisioning, and operational use.  I
RP> see no benefits from "fate sharing", and lots of disadvantages.

Thanks for the opinion.  I do see advantages to having the row in the
tlstmParamsTable be removed when the snmpTargetParamsTable is removed,
because I think it's cleaner to do complete removal when the base config
for anything is destroyed.

But, I'm not going to take a hard stand on it either way.  I think it'd
work either way.  And I don't think there is a security concern with
leaving a reference to the client side key to use around even if the
parent row gets replaced again.

(A reference to the expected server side key, however, I'm more
concerned with and was a future topic I was going to bring up but didn't
want muddy the waters with more than one topic at a time)

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 3 Jul 2009 14:57:39 -0700

Hi -

> To: "Randy Presuhn" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Friday, July 03, 2009 11:37 AM
> Subject: Re: (D)TLS question (#1): selecting a client certificate touse
...
> parent row gets replaced again.

Look at it from the perspective of a management application which
provisions / performs updates to snmpTargetParamsTable.
Depending on who wrote the code and the underlying support
libraries, applications can make updates by incrementally
updating individual variables, by setting several at once, or
by deleting a row and then creating its replacement.  That
application may well be ignorant of tlstmParamsTable.

If there is no fate sharing, then none of the possible implementation
strategies could have bad side-effects.  If there is fate sharing,
then any management applications that use the delete-and-create-afresh
strategy would have the unintended side-effect of trashing entries
in the tlstmParamsTable.  I think we should avoid situations where
adding a new capability to a system requires changing the behaviour
of software that doesn't know (or care) about that capability.

> want muddy the waters with more than one topic at a time)

When an application decides to stash sensitive bits here and there
in the network, it needs to take responsibility for issuing the
instructions to wipe that information when the time comes.
Anything beyond that starts entering the realm of tamper-proof
self-destruct memories.  I don't think this is substantially different
from shared keys for notifications in USM.

Randy

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 03 Jul 2009 15:35:33 -0700

>>>>> On Fri, 3 Jul 2009 14:57:39 -0700, "Randy Presuhn" <[email-masked]> said:

RP> Look at it from the perspective of a management application which
RP> provisions / performs updates to snmpTargetParamsTable.

Yep, I had been and understood all your points.  My conclusions just
came out on the opposite side :-)

---

From: "Purvis, Ray" <[email-masked]>
Date: Tue, 7 Jul 2009 12:49:23 -0400

Hi Wes,

I saw the opinions welcome clause at the end and decided to jump in.  :)

It seems to me that an entry can exist in the snmpTargetParamsTable that doesn't have a corresponding tlstmParamsEntry, but not vice verse.  So, basically, option 2 below is the best choice.  Additionally, a deletion of the snmpTargetParamsTable entry should cause a deletion of the 1..N entries in tlstmParamsEntry that these rows are tied to.

This brings up my next question.  I haven't seen the new table structure since you decided not to augment the params table.  I would assume that with your current thoughts on the tlstmTargetParamsTable, you would include a column that references the snmpTargetParamsName?  This in turn would change your rowStatus verbiage to not allow the row to become active until the certificate info is in place and the snmpTargetParamsName exists and is filled in.

My 2 cents.

Thanks.

Ray

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Wes Hardaker
Sent: Friday, July 03, 2009 12:07 PM
To: Donati Andrew-MGIA0477
Cc: [email-masked]
Subject: Re: [Isms] (D)TLS question (#1): selecting a client certificate to use

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

---

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

>>>>> On Tue, 7 Jul 2009 12:49:23 -0400, "Purvis, Ray" <[email-masked]> said:

RP> I saw the opinions welcome clause at the end and decided to jump in.
RP> :)

Always!  And thanks for the opinion.

RP> Additionally, a deletion of the snmpTargetParamsTable entry should
RP> cause a deletion of the 1..N entries in tlstmParamsEntry that these
RP> rows are tied to.

FYI, there is only a 1:0..1 mapping.

RP> This brings up my next question.  I haven't seen the new table
RP> structure since you decided not to augment the params table.  I would
RP> assume that with your current thoughts on the tlstmTargetParamsTable,
RP> you would include a column that references the snmpTargetParamsName?

In MIBs there are multiple ways of referencing rows in another table, or
in this case, "adding additional information" to rows in another table.
The AUGMENT clause is designed for the 1:1 case where rows exist
simultaneously and always in both tables.  In this case, we actually
have a 1:0..1 case and the best way to achieve that is by using
identical indexes in the second (tlstmTargetParamsTable) table.  So the
indexing now looks like this on my local disk:

  tlstmParamsEntry OBJECT-TYPE
      SYNTAX      TlstmParamsEntry
      MAX-ACCESS  not-accessible
      STATUS      current
      DESCRIPTION
          "A conceptual row containing a locally held certificate's hash
          type and hash value for a given snmpTargetParamsEntry.  The
          values in this row should be ignored if the connection
          that needs to be established, as indicated by the
          SNMP-TARGET-MIB infrastructure, is not a (D)TLS based
          connection."
      INDEX    { IMPLIED snmpTargetParamsName }
      ::= { tlstmParamsTable 1 }

The INDEX clause now matches (exactly) the clause from the
snmpTargetParamsTable.

RP> This in turn would change your rowStatus verbiage to not allow the
RP> row to become active until the certificate info is in place and the
RP> snmpTargetParamsName exists and is filled in.

I haven't written up that potential clause yet since it's not entirely
clear where consensus lies yet.  I'll post new text when/if I do though
and your review of it would be welcome.
-- 
Wes Hardaker
Cobham Analytic Solutions