Re: [Isms] ISMS/SSH and notifications
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Isms] ISMS/SSH and notifications
> -----Original Message-----
> From: Pasi.Eronen at nokia.com [mailto:Pasi.Eronen at nokia.com]
> Sent: Tuesday, May 20, 2008 4:55 AM
> To: ietfdbh at comcast.net; isms at ietf.org
> Subject: RE: [Isms] ISMS/SSH and notifications
>
[...]
> Right, my choice of terminology was poor; "snmpSSHOutgoingTable"
> should have been called "snmpSSHClientTable" and
> "snmpSSHIncomingTable" is "snmpSSHServerTable". Even for ordinary
> request/response, both are needed, and TM doesn't indeed know what
> the PDU is.
>
[...]
>
> The admin could also decide that the host
> authenticating with certain host key is "authorized representative"
> of Alice, and simply have single Alice entiry in VACM. This would
> be purely a configuration issue -- in this case, the tables
> could contain something like this:
>
> -- table that's used when SSHTM needs to open a connection in
> -- SSH client role
Here's the crux of thFrom isms-bounces at ietf.org Tue May 20 05:39:55 2008
Return-Path: <isms-bounces at ietf.org>
X-Original-To: isms-archive at megatron.ietf.org
Delivered-To: ietfarch-isms-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 861FF3A6994;
Tue, 20 May 2008 05:39:55 -0700 (PDT)
X-Original-To: isms at core3.amsl.com
Delivered-To: isms at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id A152A3A6994
for <isms at core3.amsl.com>; Tue, 20 May 2008 05:39:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.799
X-Spam-Level:
X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[AWL=0.800,
BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id Lrp11o0o9G3F for <isms at core3.amsl.com>;
Tue, 20 May 2008 05:39:53 -0700 (PDT)
Received: from QMTA04.emeryville.ca.mail.comcast.net
(qmta04.emeryville.ca.mail.comcast.net [76.96.30.40])
by core3.amsl.com (Postfix) with ESMTP id 1D8E63A68D4
for <isms at ietf.org>; Tue, 20 May 2008 05:39:53 -0700 (PDT)
Received: from OMTA07.emeryville.ca.mail.comcast.net ([76.96.30.59])
by QMTA04.emeryville.ca.mail.comcast.net with comcast
id Tn0d1Z0021GXsucA40Af00; Tue, 20 May 2008 12:39:53 +0000
Received: from Harrington73653 ([24.128.66.199])
by OMTA07.emeryville.ca.mail.comcast.net with comcast
id Tofr1Z0024HwxpC8T00000; Tue, 20 May 2008 12:39:53 +0000
X-Authority-Analysis: v=1.0 c=1 a=ahfscIEc1Jw-Em-gjDwA:9
a=LRSZtmQ6ehOroaIX_YMA:7 a=PNf-XjaRnUTWJ8-RZB5PpKYUaXYA:4
a=1pxjJC3EenQA:10
a=si9q_4b84H0A:10 a=lZB815dzVvQA:10 a=hPjdaMEvmhQA:10 a=gJcimI5xSWUA:10
From: "David Harrington" <ietfdbh at comcast.net>
To: <Pasi.Eronen at nokia.com>,
<isms at ietf.org>
References: <sdskx1wof3.fsf at wes.hardakers.net>
<07c601c8b6d3$69bce180$0600a8c0 at china.huawei.com>
<1696498986EFEC4D9153717DA325CB72A13B84 at vaebe104.NOE.Nokia.com>
<07dd01c8b75d$65989880$0600a8c0 at china.huawei.com>
<1696498986EFEC4D9153717DA325CB72AA13A9 at vaebe104.NOE.Nokia.com>
Date: Tue, 20 May 2008 08:39:51 -0400
Message-ID: <094901c8ba76$9a0dc4c0$0600a8c0 at china.huawei.com>
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <1696498986EFEC4D9153717DA325CB72AA13A9 at vaebe104.NOE.Nokia.com>
Thread-Index: Acir6hmVy3ZUdaUvRT6mENS3EiZoJQKBBnLAAFRQFUAABCzXUADA3n6QAAal7jA=
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
Subject: Re: [Isms] ISMS/SSH and notifications
X-BeenThere: isms at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/isms>,
<mailto:isms-request at ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/isms>
List-Post: <mailto:isms at ietf.org>
List-Help: <mailto:isms-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/isms>,
<mailto:isms-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: isms-bounces at ietf.org
Errors-To: isms-bounces at ietf.org
> -----Original Message-----
> From: Pasi.Eronen at nokia.com [mailto:Pasi.Eronen at nokia.com]
> Sent: Tuesday, May 20, 2008 4:55 AM
> To: ietfdbh at comcast.net; isms at ietf.org
> Subject: RE: [Isms] ISMS/SSH and notifications
>
[...]
> Right, my choice of terminology was poor; "snmpSSHOutgoingTable"
> should have been called "snmpSSHClientTable" and
> "snmpSSHIncomingTable" is "snmpSSHServerTable". Even for ordinary
> request/response, both are needed, and TM doesn't indeed know what
> the PDU is.
>
[...]
>
> The admin could also decide that the host
> authenticating with certain host key is "authorized representative"
> of Alice, and simply have single Alice entiry in VACM. This would
> be purely a configuration issue -- in this case, the tables
> could contain something like this:
>
> -- table that's used when SSHTM needs to open a connection in
> -- SSH client role
Here's the crux of the problee problem from the standpoint of editing the
secshell draft - how does the TM know it needs to open a connection in
a client role or in a server role?
The information the TM is given includes transportDomain,
transportAddress, securityName, securityLevel, and a wholeMsg which
is opaque to the TM. It is asked to send the message. It checks to see
if there is already a connection associated with (transportDomain,
transportAddress, securityName, securityLevel) and does not find one.
The PDU in wholeMsg might contain an outgoing GET-REQUEST or a Trap;
it doesn't know.
How does the TM determine whether to open the new connection as a
client or as a server? Where in the system is that decision made? what
information is needed by the module making that decision? which
subsystem *has* the necessary information to make that decision?
If an existing connection is available, should the TM use it? Does the
TM need to know in which direction that connection was opened, i.e.
does it need to know whether it is acting as a client or server to
reuse the connection? Do the security properties differ if the TM's
role is client or server? Is the TM the right place to make that reuse
decision - it is obviously the only module that understand SSH
client/server roles so it appears that it must, but if the security
properties are different, which module should be making that decision
(or should it be the admin)?
And then, Should these decisions be admin-specified deployment
decisions (e.g., in a MIB), implementation decisions, or hard-coded
model-specific decisions?
The information below requires the client/server decision be made
first, so we know which tables to look in.
David Harrington
dbharrington at comcast.net
ietfdbh at comcast.net
dharrington at huawei.com
> snmpSSHTMClientTable:
> index:
> snmpSSHTransportDomain snmpSSHDomain
> snmpSSHTransportAddress 192.0.2.1:162
> snmpSSHSecurityName "Alice"
> snmpSSHSecurityLevel authPriv
> columns:
> snmpSSHClientParameters "27x"
>
> snmpSSHClientParameterTable:
> index:
> snmpSSHClientParameters "27x"
> columns:
> snmpSSHUserCredentialType 1 (1 = userPublicKey,
> 2 = userPassword,
> 3 = hostPublicKey
> ... enum list)
> snmpSSHUserKeyPair ++++ (the public/private
> key pair to use if 1)
> snmpSSHUserPassword ++++ (the passphrase to
> use if 2)
> snmpSSHRemoteHostPublicKey +++ (the public key
> expected from peer)
>
> -- table used when SSHTM establishes a connection in SSH server role
> snmpSSHServerTable:
> index:
> snmpSSHUserName "alicek" (peer says "I'm alicek")
> columns:
> snmpSSHSecurityName "Alice" (this is what gets
> passed outside SSHTM)
> snmpSSHServerParameters "99foo" (how the SSH client is
> authenticated)
> snmpSSHServerParameterTable:
> index:
> snmpSSHServerParameteres "99foo"
> columns:
> snmpSSHUserCredentialType 1 (1 = userPublicKey,
> 2 = userPassword, ...)
> snmpSSHUserPublicKey +++ (the public key to use if
1)
> snmpSSHUserPassword +++ (the correct password if
2)
>
> And I agree that of these tables, snmpSSHClientParameterTable and
> SNMPSSHServerParameterTable don't have to be MIB tables, but could
be
> just data structures in the SSH implementation. Since the details
> will anyway depend on the implementation (and as Jeffrey pointed
> out, get complex for GSS-API and keyboard-interactive), that's
> probably the best solution.
>
> Best regards,
> Pasi
>
_______________________________________________
Isms mailing list
Isms at im from the standpoint of editing the
secshell draft - how does the TM know it needs to open a connection in
a client role or in a server role?
The information the TM is given includes transportDomain,
transportAddress, securityName, securityLevel, and a wholeMsg which
is opaque to the TM. It is asked to send the message. It checks to see
if there is already a connection associated with (transportDomain,
transportAddress, securityName, securityLevel) and does not find one.
The PDU in wholeMsg might contain an outgoing GET-REQUEST or a Trap;
it doesn't know.
How does the TM determine whether to open the new connection as a
client or as a server? Where in the system is that decision made? what
information is needed by the module making that decision? which
subsystem *has* the necessary information to make that decision?
If an existing connection is available, should the TM use it? Does the
TM need to know in which direction that connection was opened, i.e.
does it need to know whether it is acting as a client or server to
reuse the connection? Do the security properties differ if the TM's
role is client or server? Is the TM the right place to make that reuse
decision - it is obviously the only module that understand SSH
client/server roles so it appears that it must, but if the security
properties are different, which module should be making that decision
(or should it be the admin)?
And then, Should these decisions be admin-specified deployment
decisions (e.g., in a MIB), implementation decisions, or hard-coded
model-specific decisions?
The information below requires the client/server decision be made
first, so we know which tables to look in.
David Harrington
dbharrington at comcast.net
ietfdbh at comcast.net
dharrington at huawei.com
> snmpSSHTMClientTable:
> index:
> snmpSSHTransportDomain snmpSSHDomain
> snmpSSHTransportAddress 192.0.2.1:162
> snmpSSHSecurityName "Alice"
> snmpSSHSecurityLevel authPriv
> columns:
> snmpSSHClientParameters "27x"
>
> snmpSSHClientParameterTable:
> index:
> snmpSSHClientParameters "27x"
> columns:
> snmpSSHUserCredentialType 1 (1 = userPublicKey,
> 2 = userPassword,
> 3 = hostPublicKey
> ... enum list)
> snmpSSHUserKeyPair ++++ (the public/private
> key pair to use if 1)
> snmpSSHUserPassword ++++ (the passphrase to
> use if 2)
> snmpSSHRemoteHostPublicKey +++ (the public key
> expected from peer)
>
> -- table used when SSHTM establishes a connection in SSH server role
> snmpSSHServerTable:
> index:
> snmpSSHUserName "alicek" (peer says "I'm alicek")
> columns:
> snmpSSHSecurityName "Alice" (this is what gets
> passed outside SSHTM)
> snmpSSHServerParameters "99foo" (how the SSH client is
> authenticated)
> snmpSSHServerParameterTable:
> index:
> snmpSSHServerParameteres "99foo"
> columns:
> snmpSSHUserCredentialType 1 (1 = userPublicKey,
> 2 = userPassword, ...)
> snmpSSHUserPublicKey +++ (the public key to use if
1)
> snmpSSHUserPassword +++ (the correct password if
2)
>
> And I agree that of these tables, snmpSSHClientParameterTable and
> SNMPSSHServerParameterTable don't have to be MIB tables, but could
be
> just data structures in the SSH implementation. Since the details
> will anyway depend on the implementation (and as Jeffrey pointed
> out, get complex for GSS-API and keyboard-interactive), that's
> probably the best solution.
>
> Best regards,
> Pasi
>
_______________________________________________
Isms mailing list
Isms at ietf.org
etf.org
https://www.ietf.org/mailman/listinfo/isms
https://www.ietf.org/mailman/listinfo/isms
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
