Subject: [Isms] tmsm-13 section 5.2.2: transport principals

From: Wes Hardaker <[email-masked]>
Date: Tue, 02 Sep 2008 16:55:33 -0700

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
[email-masked]
https://www.ietf.org/mailman/listinfo/isms

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 16 Sep 2008 17:20:44 +0200

Hi,

I have not seen any reaction to this message by Wes. Does this mean
everybody agrees to the proposed changes?

/js

PS: I personally very much like the figures - I think they are
    helpful. Does it make sense to include them in the SSH TM
    specifications?

-- 
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/>
_______________________________________________
Isms mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isms

---

From: "David Harrington" <[email-masked]>
Date: Tue, 16 Sep 2008 12:26:34 -0400

Hi,

I am in the process of editing the documents. As I try to apply Wes's
proposals to the documents, I will have a much better idea whether I
agree with them. Wes's and others' proposed text changes have been
tremendously helpful in getting the documents updated. While
processing some of the previous proposals, I have found some problems
with proposed wordings that cause implicit technical changes. I cannot
really react to this until I try to apply them to the drafts.

Demands of my day job are constraining my time available to edit
drafts and discuss the issues, so I have been focusing on getting the
edits into the documents rather than participating in the email
discussions. I am watching the discussions and working to make sure
the documents reflect consensus, but choose not to spend a lot of time
discussing the points until I see how they actually affect the
documents.

dbh

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Juergen Schoenwaelder
> Sent: Tuesday, September 16, 2008 11:21 AM
> To: Wes Hardaker
> Cc: ISMS WG
> Subject: Re: [Isms] tmsm-13 section 5.2.2: transport principals
> 
> Hi,
> 
> >   +-----------+                
> +---------------------------------------+
> >   |CG         |                |CR                          
>            |
> >   |           |<---------------|                            
>  .         |
> >   +-----------+   I'm x.y.com  
> +------------------------------o--------+
> >                                                                O
> >                                                                 O
> >                                                        
> +----------------+
> >                                                        
> |I'll let "foo"  |
> >                                                        |in 
> today I guess|
> >                                                        
> +----------------+
> > 
> >                                   SNMPv3          SSH
SNMPv3
> >   |NG                                     |   I'm foo      
> |CR         |
> >   |      .                                |   I'm x.y.com  
> |           |
> transport

---

From: "David Harrington" <[email-masked]>
Date: Wed, 17 Sep 2008 11:31:05 -0400

Hi,

Actually, the pictures are incorrect from an RFC3411 perspective. And
it is important to not confuse readers with incorrect pictures.

So if we include pictures similar to this, then we need to be sure to
label them as being inaccurate representations of RFC3411 modularity,
but as guides to understanding the issue.

--
We have started to mix things up in a way that could be confusing, but
also might be enabling. And we may need to consider the security
issues related to how an operator configures notifications.

In SNMPv3, securityName was meant to be an identifier of the principal
on whose behalf operations would be performed. The principal would be
the same on both sides since the community models and USM used shared
keys, and therefore the identifier would be the same on both sides
(and the securityModel and securityName are passed in an snmpv3
message to permit algorithm agility). 

With SSH, the asymetric security introduces two principals - the
client and the server, but once the user is authenticated using
user-auth, both sides have the same SSH user name associated with the
session because the authenticated user name is in the
SSH_MSG_USERAUTH_SUCCESS message (except possibly for GSSAPI - gee
thank guys ;-), and that can be mapped to consistent securityNames on
both sides. An application passes the desired SSH principal to the SSH
client, the client and server agree on which name is authenticated,
and the SSH implementation passes the user name to the application
(somehow).

With the "[email-masked]" transport addressing, we are breaking the
basic assumption. Now the operator has two principals - a local
principal for ACM and a remote principal for authentication, and we
have no rules that they must be the same; in fact, we deliberately
allow them to be different (and expect them to be different).
Therefore the securityName used by the NO no longer necessarily
represents the principal to be authenticated. 

An operator can configure the NO to do a ACM check against "foo", but
is there anything that prevents the operator from specifying the
receiving principal ([email-masked]) or the receiving host (x.y.com) as
the securityName? We have lost the binding between the name used for
ACM and the name used for authentication. In the community models and
USM, I think you cannot misconfigure a system to specify
securityName="dbh" is to be authenticated by the remote system, and
securityname="root" to determine what is allowed to be sent. Now you
can.

I know the SNMPv3 WG wanted these two identities to be bound together
because I wrote a proposal to allow them to be different by sending
one identity in the security parameters and another in the PDU, and it
was totally rejected because there was no binding - the ACM was
supposed to be applied to the authenticated principal (even if authz
was done before authn). So this change to use "[email-masked]" seems to
be a definite override of an SNMPv3 WG consensus.

As we discussed earlier this year, the wording in the SNMPv3 documents
does not force this binding. I assure you that was an oversight
related to the fact that the ACM decision is an optional feature of
the application subsystem (although required by the existing
application "models").

If the operator can configure the NO to use two different principals,
what are the security considerations of that change? I think we need
to consider any vulnerabilities caused by a lack of any binding
between authn and authz. We also should consider security properties
when 1) the operator uses an unauthenticated local name for the ACM,
2) the operator uses the authenticated remote user ([email-masked]) for
ACM, and 3) the operator uses the authenticated remote host (x.y.com)
for ACM, and 4). I can see operators experimenting with different
possibilities, and we should understand the security implications.
Maybe we should REQUIRE or RECOMMEND a particular approach to ensure
consistent interoperable security properties.

dbh

SNMPv3

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 17 Sep 2008 08:35:20 -0700

DH> So if we include pictures similar to this, then we need to be sure to
DH> label them as being inaccurate representations of RFC3411 modularity,
DH> but as guides to understanding the issue.

They were indented to be helpful to real-world implementation and
discussion around what is happening and weren't intended to be used
within the documents...  If you want an architecturally labeled diagram,
one could easily be created.

(The reason I didn't do a complete diagram was I was trying for
simplicity for understanding the situation; eg, the engine blocks don't
really exist in the CR in an architecture, but everyone does implement
the engine directly in the CR application in the real world)
--
We have started to mix things up in a way that could be confusing, but
also might be enabling. And we may need to consider the security
issues related to how an operator configures notifications.

dbh

SNMPv3

---

From: "David Harrington" <[email-masked]>
Date: Wed, 17 Sep 2008 12:13:44 -0400

I understand why you didn't do an architecturally accurate diagram. I
support the current diagrams, but just want to make sure they are
labelled as being non-rfc3411-modular if we use them.

You didn't comment on the stuff following the "--" line in my email; I
hope you didn't think that was the end of the post.

dbh

> From: Wes Hardaker [mailto:[email-masked]] 
> Sent: Wednesday, September 17, 2008 11:35 AM
> To: David Harrington
> Cc: [email-masked]; 'Wes Hardaker'; 'ISMS WG'
> Subject: Re: tmsm-13 section 5.2.2: transport principals
> 
>

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 17 Sep 2008 09:27:49 -0700

>>>>> On Wed, 17 Sep 2008 12:13:44 -0400, "David Harrington" <[email-masked]> said:

DH> You didn't comment on the stuff following the "--" line in my email; I
DH> hope you didn't think that was the end of the post.

Whoops; I didn't see it.  I'll respond to it separately.
-- 
Wes Hardaker
Sparta, Inc.
_______________________________________________
Isms mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isms

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 17 Sep 2008 16:06:11 -0400

--On Wednesday, September 17, 2008 11:31:05 AM -0400 David Harrington 
<[email-masked]> wrote:

> thank guys ;-),

Huh?  No.  Inside SSH, the authenticated username is the one that was used 
in an SSH_MSG_USERAUTH_REQUEST message that resulted in successful 
authentication, as indicated by an SSH_MSG_USERAUTH_SUCCESS message (which 
itself does not contain any data).

However, you are not inside SSH; you are outside SSH and so don't get to 
peek inside its messages; that would violate the abstraction.  As far as 
SNMP is concerned, the authenticated username is the one SSH gave it.

> be a definite override of an SNMPv3 WG consensus.

Unfortunately, the SNMPv3 security name design was shortsighted, limited by 
USM being the only model anyone had in mind and by frequently ignoring the 
abstraction boundary.  As a result, it has been a real pain to figure out 
what the architecture is supposed to be, because there isn't one!

The shortsighted design is _wrong_.  It makes the assumption that an NO can 
successfully authenticate and deliver a notification by telling the NR the 
_NO's name for the NR_.  The NO does not actually identify itself to the NR 
in any way; instead, it depends on USM's assumption that the NR's name for 
the NO will be the same as the NO's name for the NR, because USM names do 
not name principals; they name pairwise associations between principals.

This model _does not work_ in systems where the names apply to principals 
rather than to principal pairs.  There is no non-pairwise system in which I 
can authenticate to you by telling you only your name; I must tell you my 
name.  Of course, I need to _know_ your name, so I know who I'm talking to. 
This is another difference between USM and non-pairwise systems -- everyone 
needs to know _two_ names, their own and that of their peer.

The difficulty I think you are getting at here is that SSH throws an 
additional complexity into the mix, which is that an entity acting in the 
role of an SSH server might not have the same name as the same entity 
acting in the role of an SSH client.  In fact, this issue is sufficiently 
complex that SSH client implementations typically provide a mechanism for 
storing information about arbitrarily-named servers, and a set of 
conventions for deriving the server's name and its transport address (or at 
least, its network address) from the same user input.

So, we have two major problems...
(1) Recording the name an NO must use for itself when talking to an NR
(2) Recording the name an NO must use for the NR it is talking to, and
   correlating that name to the securityName used by VACM.

We have agreed, I think, to resolve (1) by extending the SSH transport 
address format to record the ssh username to use on an outgoing connection, 
in a syntax that will be familiar to users of SSH.

So far, we have handled (2) somewhat poorly.  Particularly, we seem to be 
determining the NR's name by deriving it from the "hostname" in its 
transport address, in much the same way that SSH clients normally do. 
However, as you point out, this provides no binding to the securityName, 
which is a problem.  Effectively, the only binding is the operator's 
assertion that using a particular transport address (and authenticating the 
SSH server in the usual way) will reach an entity that corresponds to the 
configured securityName.

One solution might be to require on outgoing connections that the 
securityName be used as the SSH client's name for the remote SSH server, 
rather than deriving that from the transport address, and that the 
transport address be used _only_ to identify the remote IP address, port, 
and outgoing SSH username.  This could make configuration somewhat more 
complex, as it would require maintaining in the SSH client's database a 
mapping between securityName and host key or other credentials, rather than 
the usual mapping involving a hostname.  However, this should not be too 
difficult for any SSH implementation general enough to be used in ISMS.

One potential disadvantage to binding an NR's SSH server credentials to its 
securityName rather than to its transport address is that an NG will expect 
any given securityName to use the same credentials regardless of its 
transport address, and in practice that may not be feasible -- a user who 
uses any of several different management stations will always have the same 
username (authenticated by central infrastructure, we hope), but each 
management station will likely have its own SSH host key pair (hopefully 
distinct from key pairs used by that station for other users), and 
requiring users to keep "their" SSH host key in sync between management 
stations would make the system unusable.

-- Jeff

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 17 Sep 2008 13:49:16 -0700

>>>>> On Wed, 17 Sep 2008 16:06:11 -0400, Jeffrey Hutzelman <[email-masked]> said:

[thanks Jeff for writing first, since you significantly shortened my
reply since I agree with most of what you said!]

>> SSH_MSG_USERAUTH_SUCCESS message (except possibly for GSSAPI - gee

JH> Huh?  No.

I agree with Jeff here completely...  Just because you used a user name
to authenticate with, it does *not* suddenly change the name both sides
of the connection use to "name" it.  A client will still name the remote
side foo.example.com, and the server will still name the person
connecting "dbh".  Never in that transaction does the client suddenly
say "I'm talking to 'dbh' on the other system" because it's gotten past
the authentication stage.

JH> So, we have two major problems...
JH> (1) Recording the name an NO must use for itself when talking to an NR
JH> (2) Recording the name an NO must use for the NR it is talking to, and
JH> correlating that name to the securityName used by VACM.

Up until this point, you and I are in agreement.  However, starting with
the above text you're making some statements that are invalid about the
way SNMPv3 handles processing notifications.

JH> We have agreed, I think, to resolve (1) by extending the SSH transport
JH> address format to record the ssh username to use on an outgoing
JH> connection, in a syntax that will be familiar to users of SSH.

Yep.  We agree on this point.

JH> So far, we have handled (2) somewhat poorly.  Particularly, we seem to
JH> be determining the NR's name by deriving it from the "hostname" in its
JH> transport address, in much the same way that SSH clients normally
JH> do. However, as you point out, this provides no binding to the
JH> securityName, which is a problem.  Effectively, the only binding is
JH> the operator's assertion that using a particular transport address
JH> (and authenticating the SSH server in the usual way) will reach an
JH> entity that corresponds to the configured securityName.

This, unfortunately, is wrong.  And I say unfortunately because the
situation is actually worse, not better.

The problem is that the VACM processing handles way too early in the
desire to send a notification.

The typical (snmp-instrumented) agent which needs to act as a NO in
order to send a "sky is falling" notification goes through these steps:

1) panics.  (realizes it's in trouble and needs to send a notification).
   [yes, Virginia, there are good notifications too]

2) creates the notification to be sent, including varbinds

3) looks up it's notification destinations in the NOTIFICATION-MIB and
   the TARGET-MIB (or other proprietary configuration)

4) Finds (for example):
   domain:        SSH
   address:       manager.example.com:9876
   securityName:  foo
   securityModel: TSM

5) Decides whether user 'foo' using 'TSM' is allowed to see the
   notification that needs to be sent.

6) If the VACM says it's ok, then at this point, 'foo' using TSM is
   authorized to see it.  We've only checked authorization against the
   assigned name "foo" without actually proving the remote side can
   prove that they're manager.example.com successfully.

7) lots of internal, security-irrelevant stuff happens between 6 and 8

8) The TSM gets the request to send an outgoing notification and doesn't
   have a security cache for it then TSM (outgoing step 3) sets the
   outgoing tmSecurityName to 'foo'.

9) lots more stuff

10) the SSH TM is either opened here, using only the address above and
    possibly the securityName (or "someone@" if present in the address)
    to connect to manager.example.com.

*Because* we've decide that it's implementation specific as to how an
implementation verifies that the credentials (eg RSA cert) presented by
manager.example.com legitimately belongs to manager.example.com, that's
all swept under the rug as "implementation dependent".

The really really important thing to take away from all of the above, is
that the VACM makes it's decision on whether a notification can be sent
to some one *long before* the transport is opened.  There is at no point
in any of this that the securityName is derived from the NRs address.
It comes straight out of the mapping table from the configuration in the
TARGET-MIB.  The VACM operator *only* on the security name assigned to
the "target" by the operator.

This makes the SNMP protocol very very unique.  It's authorizing
something long before it's even begun to talk to the other side.

Now...  does this matter?  I don't think so.  It's just a name.  As long
as there is all the complete mapping pieces, it doesn't matter what we
locally (to the NO) name this "connection".  As long as I verify the
remote credentials and they match what I expect, the name is
supplementary to the cryptography.

Somewhere, though, there has to exist a table mapping
manager.example.com to the expected presented cert.  In openssh this is
in ~/.ssh/known_hosts.  But right now there is no interoperable way to
set up this file (as it's been declared, for good reasons, out of scope).

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 17 Sep 2008 18:13:05 -0400

>    address:       manager.example.com:9876

I think we're more in agreement than you think.  I understand the unusual 
authorization-before-authentication model that gets used here, and I don't 
think it makes a difference.

Under our current model, the above record carries with it the implicit 
assertion that the SSH server at manager.example.com:9876, however you 
eventually end up authenticating that, is equivalent to the securityName 
"foo" under TSM.  So when you eventually set up a connection to that host 
and it successfully authenticates, you know it is safe to send that host 
any notifications that "foo" is authorized to receive.

>     to connect to manager.example.com.

I think there's a disconnect here that we may choose to fix.

Currently, the SSH connection is opened to a particular server running on a 
specified transport address.  We expect that server to prove its identity 
based on credentials (a host key) that we associate with that transport 
address in an implementation-specified way.  We then authenticate to it 
using an SSH username that is derived from the "someone@" in the address, 
or from the securityName.

Unfortunately, this depends on the assertion I described above to insure 
that the SSH server we reach represents an agent authorized to receive 
notifications that "foo" is authorized to receive.

What if, instead of associating host credentials with a transport address 
in an implementation-specific way, we associated them with a securityName, 
or possibly with a (transport address, securityName) tuple?  Would that 
resolve the issue?

-- Jeff

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 17 Sep 2008 15:53:47 -0700

>>>>> On Wed, 17 Sep 2008 18:13:05 -0400, Jeffrey Hutzelman <[email-masked]> said:

>> address:       manager.example.com:9876

JH> Under our current model, the above record carries with it the implicit
JH> assertion that the SSH server at manager.example.com:9876, however you
JH> eventually end up authenticating that, is equivalent to the
JH> securityName "foo" under TSM.

Agreed.  That's not, admittedly, what I thought you were implying though
so I'm certainly happier that we're on the same page and actually always
have been :-)

[...snip...]

JH> We then authenticate to it using an SSH username that is derived
JH> from the "someone@" in the address, or from the securityName.

JH> Unfortunately, this depends on the assertion I described above to
JH> insure that the SSH server we reach represents an agent authorized to
JH> receive notifications that "foo" is authorized to receive.

Good so far.

JH> What if, instead of associating host credentials with a transport
JH> address in an implementation-specific way, we associated them with a
JH> securityName, or possibly with a (transport address, securityName)
JH> tuple?  Would that resolve the issue?

That would be one way of adding that last bit of needed configuration.
In reality it would be an augmentation to the snmpTargetAddrTable that
would contain rows that only apply when snmpTargetAddrTDomain was of
type snmpSSHDomain.  It could contain 1-2 indexes of the above, and the
final column would be what though?  This is where we got stuck before
because it was declared out of scope for ISMS to identify keying
material expected from the remote side because it violated the
separation layer.  The options are (assuming 2 indexes here):

1) indexes=securityName,TAddress  columns=pubkeytype,pubkeyvalue

   We'd need to publish the list of current key types (eg, RSA, DSA,
   ...) and have IANA publish a MIB every time SSH adds another one.
   pubkeyvalue would then be a binary blob.

   Caveats though:
     - this violates the abstraction (which I don't care about because it
       increases usability, but I thought you were against SSH config)
       - (will the mib still be good when SSH/X.509 comes around?)
     - pubkeyvalue sizes would run into tricky SNMP configuration over
       non-fragmenting UDP (you'd have to implement trickle-in
       configuration or other oddities to take care of it).

2) indexes=securityName,TAddress  columns=pubkeytype,hash(pubkeyvalue)

   Similar but would authorize based on a hash of the key

   Caveats though:
     - still violates abstraction layer
     - gets around the sizing issues
     - massively different security implications and this alone makes it
       not likely to be an acceptable candidate.  I only offer it
       because someone would ;-)

3) indexes=securityName,TAddress  columns=keyname

   Where keyname would be a unique index to local configuration store
   pointing to a particular key

   Caveats:
     - doesn't buy us anything really.  still requires an implementation
       dependent keyname -> key lookup which is really no different 
       than what we have today:  TAddress->key

4) Don't standardize a MIB configuration structure, but just
   standardize that implementations SHOULD/MUST have a configuration
   mechanism that provides securityName,TAddress mapping pairs to key
   names.

   Caveats:
     - still requires implementation dependent configuration mechanism
     - the only real gain is a particular "index" mapping requirement

5) Don't standardize any expectation system

   Caveats:
     - That's where we're at today anyway.

I'm very much interested in the results of this discussion, because I
have the same issues with the DTLS draft but involving expected X.509
certs.  I thought about adding a very similar table there for offered
key expectations (but in that case, there is also CA certs to consider).
It would be nice if the SSH and eventual DTLS drafts used a similar
expectation architecture since they're both pub/priv based transports.
-- 
Wes Hardaker
Sparta, Inc.
_______________________________________________
Isms mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isms

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 17 Sep 2008 19:27:28 -0400

> expectation architecture since they're both pub/priv based transports.

SSH today has very little to say on this subject.  Architecturally, there 
are two layers that are of interest here.  SSH supports a number of key 
exchange algorithms, which authenticate the server based on some 
combination of its host keys and knowing what its name is supposed to be. 
It also supports a number of host key algorithms; a key exchange method may 
be used with any host key algorithm which supports the operations it needs. 
Some key exchange methods, such as the GSS-API based ones, don't require 
any host key operations.  Note that knowing the key alone is _not 
sufficient_; in a GSS-API key exchange, the SSH server proves that it has a 
particular name but does not prove that it knows any particular host key. 
So, storing public key data in SNMP is not helpful, because it assumes that 
the public key is all you need to know.

What most SSH implementations do is maintain a database of public key 
information indexed by hostname.  So, you start with a hostname, and if 
you're using a key exchange method that requires a public key, you can look 
up the public key for that hostname in the database.  Further, 
implementations such as OpenSSH allow one to independently specify the 
authentication "hostname" (-oHostKeyAlias) from the transport address 
(-oHostName).  The name given on openssh's command line is actually neither 
of these, though it is used as a default value for both; in fact, it is the 
name of a configuration database entry which can specify nearly any 
options, including these as well as the authentication methods and 
algorithms to be used and even the remote username to be used.

My first inclination is to use the transport address hostname as a key into 
this SSH configuration database, and also as the default transport address 
and authentication name.  The difficulty in using it for the last purpose 
is that we really want that to be tied to the securityName, not the 
TAddress.

So, my second inclination is to use the securityName as a key into that 
database, and also as the default for the authentication name.  The 
TAddress would continue to be used to determine the transport address to 
connect to, and optionally the remote username to use (if this is not 
specified in the TAddress, it comes from the SSH config db, or defaults to 
the same as the securityName, useless as that probably is).  The many 
caveat with this approach is that it assumes that practically everything 
that might be in that configuration database should be associated with the 
securityName rather than the TAddress or the combination.

Your option 3 resolves that, by allowing us to use the combination of 
securityName and TAddress to look up some value, which could be treated 
either as a key into SSH's configuration database or as an authentication 
hostname (which also serves as a key into SSH's host key database, when 
appropriate).  You can even make the question of which one 
implementation-dependent, by saying that the RHS is normally the hostname 
used by SSH for authentication, but that some SSH implementations may also 
use this name to find other configuration.

-- Jeff

---

From: <[email-masked]>
Date: Mon, 22 Sep 2008 10:22:03 +0300

Jeffrey Hutzelman wrote:
> I think we're more in agreement than you think.  I understand the
> unusual authorization-before-authentication model that gets used
> here, and I don't think it makes a difference.
> 
> Under our current model, the above record carries with it the
> implicit assertion that the SSH server at manager.example.com:9876,
> however you eventually end up authenticating that, is equivalent to
> the securityName "foo" under TSM.  So when you eventually set up a
> connection to that host and it successfully authenticates, you know
> it is safe to send that host any notifications that "foo" is
> authorized to receive.

Well -- not exactly *equivalent*, but it does implicitly assert that
once you've succesfully authenticated manager.example.com:9876, it's
OK to send this information (which VACM says "foo" is allowed to see)
there.

(But it's not one-to-one equivalence; some other notifications with
securityName "bar" could also have manager.example.com:9876 as
transport address. But no, this doesn't really matter as long as we
don't assume the implementation actually needs to find "foo" when
given "manager.example.com:9876" -- and since we're doing the VACM
steps long before the transport connection exists, we don't need
this.)

> > 10) the SSH TM is either opened here, using only the 
> >     address above and possibly the securityName (or "someone@" 
> >     if present in the address) to connect to manager.example.com.
> 
> Currently, the SSH connection is opened to a particular server
> running on a specified transport address.  We expect that server to
> prove its identity based on credentials (a host key) that we
> associate with that transport address in an implementation-specified
> way.  We then authenticate to it using an SSH username that is
> derived from the "someone@" in the address, or from the
> securityName.
> 
> Unfortunately, this depends on the assertion I described above to
> insure that the SSH server we reach represents an agent authorized
> to receive notifications that "foo" is authorized to receive.
> 
> What if, instead of associating host credentials with a transport
> address in an implementation-specific way, we associated them with a
> securityName, or possibly with a (transport address, securityName)
> tuple?  Would that resolve the issue?

Using just "securityName" would probably complicate things on the
command generator side (where securityName is "peer's name for us").
Associating host credentials with hostname+port is also more in
line with how SSH usually works...

Best regards,
Pasi