Subject: [Isms] Some text on identity and authentication for SSHSM

From: [email-masked]
Date: Fri, 16 Sep 2005 19:41:01 -0700

Hi Dave, Juergen, Joe,
 
Please find some text in the attached document pertaining to identity
and authentication with SSHSM.
 
regards,
  kaushik!
_______________________________________________
Isms mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isms

---

From: "David B Harrington" <[email-masked]>
Date: Fri, 16 Sep 2005 22:52:51 -0400

Hi Kaushik,
 
Where in the document is your text meant to go?
Please provide the revision and the section numbers so I know where
you intend it to go.
 
dbh

  _____  

From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, September 16, 2005 10:41 PM
To: [email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]
Subject: Some text on identity and authentication for SSHSM

Hi Dave, Juergen, Joe,

regards,
  kaushik!

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 17 Sep 2005 09:50:41 +0200

On Fri, Sep 16, 2005 at 07:41:01PM -0700, [email-masked] wrote:
> 
>    1. Each SNMP engine that uses the SSHSM MUST be capable of performing 
>       the role of SSH server and SSH client and MUST have appropriate 
>       server credentials, i.e. host key pairs are prevelant in most 
>       deployments but may not required in case GSSAPI is used for SSH key
>       exchange. X.509 certificates will be supported in the near future
> 
>    2. SSHSM will support public key authentication (X.509 certs will be 
>       supported in the near future for SSH user authentication) and 
>       password based authentication that could be used to support Local 
>       Accounts, RADIUS and TACACS+ mechanisms.
> 
>    3. Host based authentication (hosts.equiv) MUST not be supported.
> 
>    4. In case host key pairs, each SNMP engine must be pre-configured with 
>       SSH host public keys of other SNMP engines that it would require to 
>       communicate (2*) with. 
> 
>    5. The username used in the SSH User Authentication Protocol SHOULD be 
>       the SNMP securityName and in instances that is not the case, 
>       implementations MUST be to able to map the authenticated name (3*) to 
>       securityName. 

I am not sure what the purpose of this is. RFC 3411 already requires
that whatever a security model authenticates must map to a
securityName. I am also not sure about the SHOULD. In fact, I have no
clue whether you write requirements, applicability text, security
considerations or protocol specification.

>    1* The use of the SNMP engine in key localization does not really 
>       constitute use of host identity.
>    2* SSH public keys might already be cached on workstations that use SSH
>       for remote login purposes.
>    3* Some implementations may map host identity to the securityName.
>      
>    Public Key Authentication
> 
>    The SSH authentication method name "publickey" will be used to support
>    this mechanism. The user's public key and a signature generated using 
>    the user's private key is sent to the server to authenticate the user.
>    Although this authentication mechanism is mandatory for the SSH User
>    Authentication protocol, the use of this mechanisms for SSHSM will be
>    restricted to operators that use public key authentication when managing
>    networks via the Command Line Interface (using SSH remote login).

I am only allows to use SSHSM with public keys if I also use them for
the CLI? I fail to see the purpose of this CLR.

>    Password based authentication
> 
>    The SSH TMSM will support a variety of authentication systems via the 
>    SSH user authentication "password" method. The most prevelant would
>    be authentication via RADIUS and Local Accounts. The SSH authentication
>    protocol will not differentiate between these various mechansims and will
>    behave identically. Most SSH implementations use a pluggable 
>    authentication mechanism (PAM) for the integration of the password
>    based authentication method to a variety of authentication 
>    systems. 
> 
>    RADIUS Authentication
> 
>    SSHSM SHOULD use RADIUS Digest for authentication for security reasons. 
>    Implementations MAY however choose to use of RADIUS PAP to support 
>    additional backend authentication systems such as Active Directory and 
>    Token Servers.
> 
>    The RADIUS server MAY return authorization information such as a GroupName
>    or Role Name on sucessful authentication. 

The last paragraph, if included, should be phrased in terms of generic
AAA services.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany