Re: ISMS working group and charter problems

Jeffrey Hutzelman <jhutz@cmu.edu> Thu, 08 September 2005 21:36 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDU4Y-0007dw-3q; Thu, 08 Sep 2005 17:36:42 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDU4W-0007ci-78 for ietf@megatron.ietf.org; Thu, 08 Sep 2005 17:36:40 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19659 for <ietf@ietf.org>; Thu, 8 Sep 2005 17:36:37 -0400 (EDT)
Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EDU7x-0000mA-Cl for ietf@ietf.org; Thu, 08 Sep 2005 17:40:14 -0400
Received: from SIRIUS.FAC.CS.CMU.EDU ([128.2.209.170]) by minbar.fac.cs.cmu.edu id aa00605; 8 Sep 2005 17:36 EDT
Date: Thu, 08 Sep 2005 17:36:02 -0400
From: Jeffrey Hutzelman <jhutz@cmu.edu>
To: j.schoenwaelder@iu-bremen.de, Sam Hartman <hartmans-ietf@mit.edu>
Message-ID: <7A2F5427CACFC35EF18323E8@sirius.fac.cs.cmu.edu>
In-Reply-To: <20050908211508.GA28818@boskop.local>
References: <200509081520.IAA02206@cisco.com> <00a101c5b49c$5e913680$0601a8c0@pc6> <tslirxbnyqz.fsf@cz.mit.edu> <20050908200547.GA25650@boskop.local> <tslvf1bmgx4.fsf@cz.mit.edu> <20050908211508.GA28818@boskop.local>
Originator-Info: login-token=Mulberry:01/11OnWnFwxFLqMYeMtt+DJbPhciGkcds0nwCNd0=; token_authority=postmaster@andrew.cmu.edu
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
Content-Transfer-Encoding: 7bit
Cc: IETF Discussion <ietf@ietf.org>
Subject: Re: ISMS working group and charter problems
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


On Thursday, September 08, 2005 11:15:08 PM +0200 Juergen Schoenwaelder 
<j.schoenwaelder@iu-bremen.de> wrote:

> On Thu, Sep 08, 2005 at 04:40:55PM -0400, Sam Hartman wrote:
>
>> Authentication is sometimes symmetric; it is not in the case of
>> passwords.  For authentication methods like public key or GSS, it is
>> reasonably symmetric.
>
> The networking boxes I have access to all use password authentication
> because they like to stick the password into RADIUS/TACACS...
>
> I am not sure what "reasonably symmetric" means. Who authenticates
> whom and in which way if the server establishes a connection to the
> client with public key or GSS?

SSH servers don't establish connections to SSH clients.
An SSH server is authenticated as part of key exchange.
An SSH client is authenticated as part of user authentication.

In some cases, the same kinds of credentials can be used in either 
direction.  For example, an RSA key pair can be used either to authenticate 
a host (as a host key) or to authenticate a user (via the publickey 
userauth method).  Similarly, if the Kerberos GSSAPI mechanism is used, the 
same Kerberos principal can be used in either a client or a server role, 
provided the Kerberos infrastructure is configured to allow such usage for 
that principal.

-- Jeffrey T. Hutzelman (N3NHS) <jhutz+@cmu.edu>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf