Subject: [Isms] WG review of the SSHSM -01- document

From: "David B Harrington" <[email-masked]>
Date: Thu, 16 Feb 2006 10:57:17 -0500

We need WG review of the SSHSM -01- document to confirm the solutions
discussed at IETF64 and documented in -01-.

It is not an onerous task to do this review, since a simple diff of
-00- and -01- is pretty starightforward. It would help immensely to be
able to take these issues off the table, so we can focus on the bigger
issues identified by the chairs.

Please make the time to review the -01- document and indicate your
agreement or disagreement with the proposed solutions documented in
-01-. 

Thanks,
David Harrington
[email-masked]

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 20 Feb 2006 22:57:57 +0100

> discussed at IETF64 and documented in -01-.

David,

I have completed my pass through the document. I have written some
inline annotations/comments which you might take a look at while
preparing the next revision. Note that some comments have been written
before the interim and other after the interim, so they might not be
always very consistent.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany
_______________________________________________
Isms mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isms

---

From: Eliot Lear <[email-masked]>
Date: Tue, 21 Feb 2006 16:59:11 +0100

Juergen:

> ** Is it realistic to check from the SNMP stack what the SSH did? I
> ** mean, we should be careful to not require something that makes
> ** implementations impossible (without cheating).
>   
I'd tend to agree.  At some point or another SNMP stack has to trust
that the SSH stack.  SSH also has no concept of the security levels that
SSH uses.  There could be a mapping, but that would require a defined
interface between the two, requiring modification of SSH.  In the simple
UNIX case you could envision SSH setting an environment variable for
this purpose.
> 5.  Elements of Procedure
>
> 5.1.  Establishing a Session
>
>    The Secure Shell Security Model provides the following primitive to
>    pass data back and forth between the Transport Mapping portion of the
>    Security Model and the SSH service:
>
>
>    statusInformation =
>    establishSession(
>    IN   destTransportDomain            -- transport domain to be used
>    IN   destTransportAddress          -- transport address to be used
>    IN   securityModel             -- Security Model to use
>    IN   securityEngineID        -- SNMP entity
>    IN   securityName              -- on behalf of this principal
>    IN   securityLevel             -- Level of Security requested
>    IN   subsystem
>    OUT  sessionID
>     )
>
>
>
>
>
>
> Harrington & Salowey     Expires August 12, 2006               [Page 31]
> 
> Internet-Draft    Secure Shell Security Model for SNMP     February 2006
>
>
>    The following describes the procedure to follow to establish a
>    session between a client and sever to run SNMP over SSH.  This
>    process is followed by any SNMP engine establishing a session for
>    subsequent use.  In practice, this is done by an application that
>    initiates a transaction, such as a Command Generator or a
>    Notification Originator or a Proxy Forwarder.  It is never triggered
>    by an application preparing a response message, such as a Command
>    Responder or Notification Receiver, because securityStatereference
>    will always have session information for a response message
>   

This being the case there will never be a way - should an application
lose connectivity - for it to reconnect.  This eliminates any reasonable
implementation of Call Home in the future.
>    The parameters necessary to establish a session are provided by the
>    Secure Shell Security Model to the SSH client code, using the
>    establishSession() ASI.
>
>    1) If the securityLevel specifies that the message is to be
>    authenticated, but the SSH implementation does not support an
>    authentication protocol, then the message cannot be sent.  An error
>    indication (unsupportedSecurityLevel) is returned to the calling
>    module.
>
>    2) If the securityLevel specifies that the message is to be protected
>    from disclosure, but the SSH implementation does not support
>    encryption, then the message cannot be sent.  An error indication
>    (unsupportedSecurityLevel) is returned to the calling module.
>
>    3) Using destTransportDomain and destTransportAddress, the client
>    will establish an SSH transport connection using the SSH transport
>    protocol, and the client and server will mutually authenticate, and
>    exchange keys for message integrity and encryption. if the attempt to
>    establish a connection is successful, then tmStateReference is
>    created, and the values of transportDomain and transportAddress are
>    saved.  If the attempt to establish a connection is unsuccessful,
>    then an error indication [todo] will be returned, and [todo]
>    processing stops.
>
>    [discuss] #22: There are a significant number of security problems
>    associated with mapping to a transport address which may need to be
>    discussed in the security considerations section.
>   

Somewhere around here some private state in SSHSM must be maintained to
deal with the problem mentioned in 5.4 comments.  Specifically, like any
reasonable protocol exponential backoff on attempts MUST be employed. 
For NOs in particular, epsilon delay must also be added.

more comments when able.

Eliot