Subject: [Isms] review of transport security model 09

From: "David Harrington" <[email-masked]>
Date: Thu, 9 Oct 2008 23:11:33 -0400

Hi,

Here is my review of the TSM-09 document

2.3
"The MIB module ... to disable support ..."
The MIB does not suppport this

2.5.
s/Note that if/If/

3.3.1
The REQUIRES text has been shortened to not mention tsmSameSecurity,
which is the model-independent way to force this requirement.

3.3.2
transport model has been changed to security model; need to verify
this is correct usage, since the security model does not map
transport-specific security parameters.

4.2 1) securityName extracted from securityCache has a prefix. 

The MIB

The MIB no longer allows disabling a transport, so
snmpTsmInvalidDomains needs to be changed.

snmpTsmInvalidPrefixDomain should end in an 's'
If we need this, I think it should be snmpTsmUnknownPrefixes

snmpTsmConfigurationUsePrefix needs some rewording.

David Harrington
[email-masked]
[email-masked]
[email-masked]

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

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 14 Oct 2008 09:31:53 -0700

Quick legend:

  - [-]:  nothing done; more info or discussion needed
  - [/]:  partially done
  - [X]:  done

Your words are prefixed with a '|', and my replies with WH:

|  - [X] 2.3
|            "The MIB module ... to disable support ..."
|            The MIB does not suppport this

            WH: Changed the paragraph to only reflect the on/off switch.

| - [X] 2.5.
|       s/Note that if/If/

        WH: done

| - [ ] 3.3.1
|           The REQUIRES text has been shortened to not mention tsmSameSecurity,
|           which is the model-independent way to force this requirement.

        WH: I assume you removed it because of someone's comment
        or Dave's rewording?  Do you remember why?

        WH: I actually don't think it's a huge deal since I
        believe (ie, I haven't double checked) that it's covered
        by the EOP.

| - [-] 3.3.2
|           transport model has been changed to security model; need to verify
|           this is correct usage, since the security model does not map
|           transport-specific security parameters.

        WH: this was also text changed by you?  I assume because
        of a comment or from Dave S's wording edits?

|  - [-] 4.2 1) securityName extracted from securityCache has a prefix. 

        WH: Actually, it's wasn't defined whether it would be or not.
        The Incoming procedure didn't say anything about what was cached
        in the securityStateReference.  I think we need to decide what
        we should cache.

| - [X] The MIB no longer allows disabling a transport, so
|       snmpTsmInvalidDomains needs to be changed.

        WH: done

| - [X] snmpTsmInvalidPrefixDomain should end in an 's'
|       If we need this, I think it should be snmpTsmUnknownPrefixes

        WH: Ok, changed to the new name.

| - [X]    snmpTsmConfigurationUsePrefix needs some rewording.

        WH: since you didn't state your concerns I guessed a bit
        and made some minor edits.  If you have more specific
        concerns, please spell them out and suggest replacement
        text.  New current text:

                "If this object is set to true then securityNames
             passing to and from the application are expected
             contain a transport domain specific prefix. If this
             object is set to true then a domain specific prefix
             will be added by the TSM to the securityName for
             incoming messages and removed from the securityName
             when processing outgoing messages. The resulting
             securityName, when prefixed, will begin with a
             transport domain specific prefix, followed by a ':'
             (ASCII 0x3a). The transport domain specific prefix
             should be described within the transport domain's
             object DESCRIPTION clause. Implementations SHOULD
             make this object persist across system reboots.
            "

-- 
Wes Hardaker
Sparta, Inc.

---

From: "Dave Shield" <[email-masked]>
Date: Wed, 15 Oct 2008 23:59:58 +0100

I don't think this bit (3.3.1/3.3.2) comes from my rewording,
though it feels a sensible addition to the basic shared text.
It would probably be clearer to mention the tmSameSecurity
flag explicitly at this point.   Something like

    The Transport Security Model REQUIRES that the security parameters
    used for a response are the same as those used for the corresponding
    request.  This would typically be indicated by setting the tmSameSecurity
    flag.  It is transport-model-dependent and implementation-dependent how
    this is ensured at the transport layer.

The text here is similar to something I proposed, but not exactly the same.
(I had suggested something about "security parameters used for a response
match[ing] those for the original request").

I'm not sure that the first paragraph (of 3.3.1) and the first two sentences
(of 3.3.2) are really necessary.  They simply repeat the introductions of the
corresponding generic descriptions (3.2 and 3.1 respectively).  Deleting this
text would allow 3.3 to concentate on the specific responsibilities of the TSM.

Is the second paragraph of 3.3.1 still valid?  This feels as if it's
referring to
the previous approach (now defunct), rather then the current prefix mechanism.

>        in the securityStateReference.  I think we need to decide what

Why is the securityName being added to the securityCache at all?
This value is passed out of the processIncomingMsg ASI (along
with the securityStateReference), and returned into the
generateResponseMsg ASI  (again, along with the securityStateReference).
What it the purpose of adding it to the cache as well?

If the intention is to ensure that the same security credentials are
used for request/response, then why not re-use the tmSecurityName
value cached in the tmStateReference ?

>        and made some minor edits.

My concern here is that I didn't find the current descriptions particularly
clear.   The details of the discussion rather obscured the fundamental
behaviour of this object.

I'd propose the following:

4.2  2)  b)
   If the snmpTsmConfigurationUsePrefix object is set to true, then
   the transport-specific prefix (and colon - ':', ASCII 0x3a) is stripped
   off the securityName, with the result being placed in [[or "used as"]]
   the tmSecurityName value.   The mapping from transportDomain to
   the appropriate prefix is impementation-dependent, but this prefix will
   will typically be given in the DESCRIPTION of the MIB object
   identifying this transport domain.

   If the prefix lookup for the transportDomain fails for any reason, then
   the snmpTsmInvalidPrefixDomain  [[snmpTsmUnknownPrefixes]]
   counter is incremented and an error indication is returned to the
   calling module.  If the prefix lookup succeeds, but the value returned
   does not match the actual prefix present in the securityName value,
   then the snmpTsmInvalidPrefix  [[snmpTsmInvalidPrefixes ??]]
   counter is incremented and an error indication is returned to the
   calling module.

5.2  3) b)
   If the snmpTsmConfigurationUsePrefix object is set to true, then
   set the securityName to be the concatenation of a transport-specific
   prefix, the colon character (':', ASCII 0x3a) and the tmSecurityName.
   The mapping from transportDomain to the appropriate prefix is
   impementation-dependent, but this prefix will will typically be given
   in the DESCRIPTION of the MIB object identifying this transport domain.

   If the prefix lookup for the transportDomain fails for any reason, then
   the snmpTsmInvalidPrefixDomain  [[snmpTsmUnknownPrefixes]]
   counter is incremented and an error indication is returned to the
   calling module.

I'm currently in the process of reviewing the latest drafts more fully,
and seeing how much of my earlier comments are still valid, or need
updating.   Hopefully I should be able to feed some of that back tomorrow.
(But it's late, and I need to turn in!)

One final comment, though:

In section 10. Ackowledgements
   It's  "Dave Shield" - singular.   There's only one of me.
All attempts by the Net-SNMP project team to clone me
have so far ended in failure :-)
   (Similarly in the SSH draft)

Thanks

Dave

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 21 Oct 2008 14:54:43 -0700

>>>>> On Wed, 15 Oct 2008 23:59:58 +0100, "Dave Shield" <[email-masked]> said:

[3.3.1]

DS> used for a response are the same as those used for the corresponding
DS> request.  This would typically be indicated by setting the tmSameSecurity
DS> flag.  It is transport-model-dependent and implementation-dependent how
DS> this is ensured at the transport layer.

I mostly used your text.  However, it's more than "typically" so I
reworded it slightly:

    The Transport Security Model REQUIRES that the security parameters
    used for a response are the same as those used for the
    corresponding request.  This is indicated during TSM processing by
    setting the tmSameSecurity flag.  It is transport-model-dependent
    and implementation-dependent how this is ensured at the transport
    layer.

[3.3.2]
DS> The text here is similar to something I proposed, but not exactly the same.
DS> (I had suggested something about "security parameters used for a response
DS> match[ing] those for the original request").

DS> I'm not sure that the first paragraph (of 3.3.1) and the first two
DS> sentences (of 3.3.2) are really necessary.  They simply repeat the
DS> introductions of the corresponding generic descriptions (3.2 and 3.1
DS> respectively).  Deleting this text would allow 3.3 to concentate on
DS> the specific responsibilities of the TSM.

Probably true, but I doubt the introduction-ish text hurts and is useful
for people using the document as a reference.

DS> Is the second paragraph of 3.3.1 still valid?  This feels as if it's
DS> referring to the previous approach (now defunct), rather then the
DS> current prefix mechanism.

Yep, you're right.  It seemed a bit out of place in the tmStateReference
section anyway.  Deleted.

>> in the securityStateReference.  I think we need to decide what

DS> Why is the securityName being added to the securityCache at all?

Lets see...

For incoming, it's straight forward:

  The securityName handed up is taken from the tmStateReference passed
  in by the TM (eg, SSH or DTLS).  A prefix is potentially added.

For outgoing, its two choices:

  If it's a response (securityStateReference exists because it got
  passed through the chain) then the tmStateReference is extracted as a
  whole.  The things modified in it before handing down and eventually
  to the TM are tmRequestedSecurityLevel (set to the extracted cached
  securityLevel) and tmSameSecurity (set to true).  No where do we state
  that the other tm parameters should be modified.  Nor does it make
  sense to... The tmStateReference is already part of the cache so all
  the other settings should be the same as they were when the original
  request came in.

  If it's not a response there is no secStateRef, we create a
  tmStateReference and manually set the tmStateReference parameters to
  those from the ASI.

The above is to summarize, since it's not trivial to look at the
document quickly to pull out the details (at least it wasn't for me).

So, you're absolutely right (IMHO) Dave: we don't need to extract it.
In fact, we don't need to extract anything but the securityLevel (used
to set the tmSecurityLevel) and the tmStateReference.  Anyone disagree
with that?  The rest of the listed values aren't used.  Thus the
sentence would change:

FROM:
   Extract transportDomain, transportAddress, securityName,
   securityLevel, securityModel, and tmStateReference from the
   securityStateReference cache.  

TO:
   Extract securityLevel, and tmStateReference from the
   securityStateReference cache.

The only reason I can think for is to do something like a sanity check:
ensure that the ASI passed in securityName matches a cached value.  But
that would really only signal an implementation error not a miss-use
since the architecture never says it should be different for a response
anyway.

I'll respond to your other longer comment about the usePrefix text
separately.

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 21 Oct 2008 15:28:22 -0700

DS> My concern here is that I didn't find the current descriptions
DS> particularly clear.  The details of the discussion rather obscured
DS> the fundamental behaviour of this object.

Originally I was going to give a longer reply because I disagreed with
some of the ordering, but in the end I changed my mind and am copying a
(almost) straight version of your text into place for both incoming and
outgoing processing.  Thanks for the text!

DS> One final comment, though:

DS> In section 10. Ackowledgements
DS> It's  "Dave Shield" - singular.   There's only one of me.

Fixed.

---

From: "Dave Shield" <[email-masked]>
Date: Wed, 22 Oct 2008 09:01:38 +0100

2008/10/21 Wes Hardaker <[email-masked]>:
>  passed through the chain)....

>  If it's not a response there is no secStateRef....

That's something which has been bugging me throughout this
review process.

   Whenever there's a need to distinguish between outgoing
requests and responses,  everyone always talks about
using the presence or absence of the secStateRef.

But the specs define two distinct ASIs - generateRequestMsg
and generateResponseMsg.    Why don't we sinply refer to
these ASIs by name.
    That would (IMO) be a much clearer way to distinguish
between the two cases.

Dave

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 22 Oct 2008 08:44:40 -0700

>>>>> On Wed, 22 Oct 2008 09:01:38 +0100, "Dave Shield" <[email-masked]> said:

DS> Whenever there's a need to distinguish between outgoing
DS> requests and responses,  everyone always talks about
DS> using the presence or absence of the secStateRef.

I wondered why it was written that way too, but in the end you have to
make your decisions based on the presence of the secStateRef because you
don't want to ignore it if it's there and you have to ignore it if it's not.
-- 
Wes Hardaker
Sparta, Inc.
_______________________________________________
Isms mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isms

---

From: "David Harrington" <[email-masked]>
Date: Thu, 23 Oct 2008 16:27:20 -0400

Hi,

It is written that way because consistency is good, RFC341* does it
that way, and we cannot modify RFC341*.

dbh

> -----Original Message-----
> From: Wes Hardaker [mailto:[email-masked]] 
> Sent: Wednesday, October 22, 2008 11:45 AM
> To: Dave Shield
> Cc: Wes Hardaker; David Harrington; ISMS WG
> Subject: Re: Ismsreview of transport security model 09
>