Re: [Isms] ISMS/SSH and notifications

[Jeffrey Hutzelman <jhutz at cmu.edu>]

--On Friday, May 16, 2008 01:40:46 PM +0300 Pasi.Eronen at nokia.com wrote:

> snmpSSHOutgoingTable:
>
>   index:
>      snmpSSHTransportAddress     192.0.2.1:162
>      snmpSSHSecurityName         "Alice"
>   columns:
>      snmpSSHUserName             "Adam"   (I say "I'm Adam")
>      snmpSSHUserCredentialType   1        (1 = userPublicKey,
>                                            2 = userPassword,
>                                            3 = hostPublicKey
>                                            ... enum list)

If you're going to do this, the correct thing to record is not a made-up 
"credential type" number, but an ssh user auth method name.  The problem is 
that then you need some way to record information about the credentials to 
be used (which may be one or more keys, or just a reference to something), 
and that's going to be specific not only to the method being used, but also 
potentially to the implementation and how it is configured.

For example, it's fairly straightforward that "publickey" requires a key 
pair of some sort, and "password" requires a password, but what does 
"keyboard-interactive" require?  The answer is that it depends on how the 
server implements keyboard-interactive and what questions it is going to 
ask.  Similarly, what does "gssapi-with-mic" require?  Well, at a minimum 
it requires a GSS-API mechanism OID, which is really not part of the 
credential but a sub-negotiation parameter, like a public key algorithm 
identifier.  And then it's going to require some mechanism-specific 
credentials; for example, if you're using the Kerberos GSS-API mechanism, 
then you need some way to get a Kerberos ticket, which might involve 
knowing a symmetric key, but might not, depending on your Kerberos 
deployment.

In other words, this is difficult to standardize, and if we're going to 
try, we had better leave holes into which it is possible to shove whatever 
kinds of credentials are required, instead of telling someone that he can't 
use SNMP with his existing authentication infrastructure (remember: this is 
the goal of ISMS) because we didn't anticipate what form of credentials his 
NO's would have.

In addition, while I don't think this is very common in practice, the SSH 
protocol allows servers to require _multiple_ authentications with 
different methods before granting a client access.  So you probably 
actually need a set of (method, credential) tuples.



>      snmpSSHRemoteHostPublicKey  +++      (the public key
>                                            expected from peer)

Again, you can't assume a public key is involved.  Not all SSH key exchange 
mechanisms identify hosts by public keys.  Some may use certificates, or 
underlying security mechanisms that do not involve public keys at all. 
What you actually end up needing here, I think, is a set of (keyex-method, 
keyex-data, key-type, public-key) tuples, where either of keyex-method or 
key-type can be "don't care".  The implication is that the host is 
legitimate if there is a tuple for which

- keyex-method matches the key exchange used
- keyex-data matches the host in some key-exchange-specific way
- key-type and public-key match the key presented by the host

For example, the list for the sshd running on my desktop machine might look 
like this:

(*,*, 'ssh-rsa', 'AAAA...GR/E=')
(*,*, 'ssh-dss', 'AAAA.../HRU=')
('gss-group1-sha1-toWM5Slw5Ew8Mqkay+al2g==', 'host at sirius.fac.cs.cmu.edu',
 *,*)

The first two lines match my server's two public keys; the third allows use 
of GSS-krb5 regardless of host key, as long as the service name matches.


On the SSH server side, I think you have a much easier time of it, because 
SSH does more of the work for you.  Once an SSH session is set up, the SSH 
server knows the authenticated and authorized user name of the client.  How 
the authentication mechanisms work and how the server decides what 
credentials are adequate to use what username are not things I believe are 
in scope for ISMS.  It might be appropriate for some group to define an SSH 
server MIB someday that allows some configuration of this policy, but I do 
not believe that is within our charter and I'm not convinced enough of the 
SSH community is engaged in this group to get it right.  Fortunately, we 
don't have to -- simple use the SSH user name as the SNMP securityName, as 
we had previously agreed, and the problem is solved.  If people think it is 
necessary to introduce a mapping from SSH user names to SNMP securityNames, 
I won't object.

-- Jeff



_______________________________________________
Isms mailing list
Isms at ietf.org
https://www.ietf.org/mailman/listinfo/isms