[Isms] tmsm-13 section 5.2.2: transport principals

[Wes Hardaker <wjhns1 at hardakers.net>]

Starting note: this discussion assumes 1:1 mappings and prefixes
turned off (ie, the default).  The text below is divided into two
sections: a long winded reason for text I'm suggesting followed by
additional related discussion information.


* Section 5.2.2, "transport principal":

The one major think I needs to be worded a bit better is section
5.2.2.  In particular, it discusses the "transport principal".  The
problem is that what we're using as a transport principal is different
depending on who is opening the connection.  We keep coming back to
this, so I'm trying again to point out the problem again but with a
different set of ugly pictures.

Let's take the case of a CG talking to a CR:

    SNMPv3          SSH         SNMPv3
                  Protocol
  +-----------+                +---------------------------------------+
  |CG         |                |CR                                     |
  |    +----+ |    I'm foo     |    +----+     +-----+     +------+    |
  |    | TM | |--------------->|    | TM | --> | TSM | --> | VACM |    |
  |    +----+ |                |    +----+     +-----+     +------+    |
  |           |<---------------|                             .         |
  +-----------+   I'm x.y.com  +------------------------------o--------+
                                                               O
                                                                O
                                                       +----------------+
                                                       |I'll let "foo"  |
                                                       |in today I guess|
                                                       +----------------+

In the above, the transport principal (and via propagation the
tmSecurityNanme and the securityName) is "foo" right?  It's what the
CR makes the decision by.  The VACM is saying yea or nay based on it.
It's what the CG presents to the CR in the form of a SSH user name (in
this TM example).  But, the CG MUST also verify that it's talking to
the right CR as well and it does this by verifying that x.y.com is
presenting the hostname it expects and that the public key it's
presented matched the expected value and that the entity on the remote
side can prove they have the private half of the key.

The point is that there are two identities here: "foo", and
"x.y.com".  The current text is really only talking about "foo" but it
doesn't clearly say that.

And, to make matters more confusing...  When the NG/NR process steps
in then it gets more confusing:


                                  SNMPv3          SSH         SNMPv3
                                                Protocol

  +---------------------------------------+                +-----------+
  |NG                                     |   I'm foo      |CR         |
  |  +------+    +-----+      +----+      |--------------->|    +----+ |
  |  | VACM |--->| TSM |----->| TM |      |                |    | TM | |
  |  +------+    +-----+      +----+      |<---------------|    +----+ |
  |      .                                |   I'm x.y.com  |           |
  +-------o-------------------------------+                +-----------+
           O
            O
      +--------------------+
      |I'll let "foo"      |
      |see my notifications|
      |today ...           |
      +--------------------+


(Note: The NG should still be configured to realize that x.y.com is
presenting the expected and authenticated SSH credentials)


This is where the problem lies.  In this case, we're still using a SSH
user name to identify *ourselves* and that is the outgoing
securityName which is passed to tmSecurityNanme which becomes the
principal identity.

The problem is that the name being used by the VACM (and potentially
other places) is always the one that the client side uses to
authenticate itself.  That needs to be made clear in the text, IMHO.
I think the current text leads to confusion about this.  This is the
text in the last copy:

  transport principal: the transport-authenticated identity, on
  whose behalf the secure transport connection was (or should be)
  established.  This value is transport-, mechanism- and
  implementation- specific, and is only used within a given
  transport model.

The only reason I know the correct authenticated identity to use is
because I've been thinking about it for 3 years along with the rest of
the group.  I don't think most of the rest of the first-time-readers
will be able to pull out the proper value.  This was an incredibly
long winded way of proposing a replacement paragraph:

  transport principal: the authenticated identity that will be used to
  identify the authoritative principal for the SNMPv3 messages being
  sent.  For asymmetric protocols which may be presenting different
  identity names for each side of the connection the transport
  principal will be the locally offered identity name for outgoing
  connections and the remotely authenticated name for incoming
  connections.  This value is transport-, mechanism- and
  implementation- specific, and is only used within a given transport
  model.

For SSH, the text assures that "foo" is always what is used within
both the NG and the CR.  For DTLS, it always uses the certificate that
was used to open the connection.



Aside reminder: (with my "bar@" secshell specification patch, it
actually allows for the authentication to take place using "bar"
according to the SSH server side even though we still refer to it
locally as "foo" within a NG for doing authorization checks)

-- end of proposal text --

-- start of extra discussion about reversing connections --

The security paranoid people should now be asking
themselves

1) ok, but what happens if the NG is sent a command from a
   CG?  What happens then?  (ie, a call-home situation where the
   client is a NG/CR).

   The answer is that the NG application, if it was also a command
   responder (CR), would accept the request and believe it came from
   securityName "foo".  *If* the VACM was configured to allow the
   "foo" user to access the CR then it would be allowed.  Even though
   it hadn't presented the "foo" user name itself.  This is probably
   worth noting in the Security Considerations as well.

2) ok, but what happens if the CR is sent a notification from a NG?
   What happens then?  (ie, the client is a CG/NR).

   The answer, again, is that the securityName must be "foo" *and* if
   the application had registered itself as both a CG and a CR using
   the registerContextEngineID() ASI from section 4.1.5 of RFC3411
   then it would accept the notification and do "something" with it.
   There is no (standardized) authorization process for notifications
   received, so it would simply be accepted.

--
Wes Hardaker
Sparta, Inc.
_______________________________________________
Isms mailing list
Isms at ietf.org
https://www.ietf.org/mailman/listinfo/isms