RE: [Isms]SSHSMRADIUSIntegrationdraft(draft-narayan-isms-sshsm-radius-01.txt)submitted

["Kaushik Narayan \(kaushik\)" <[e-mail]>]

Hi Eric,

Please find my reply inline. 

<snipped>

My aspirations as a large end user for this WG is for ISMS
authentication to be able to fit into (integrate with) the
authentication systems used within existing large scale deployments. The
problem for this WG is that my goal ultimately is site specific.
However, for a variety of reasons, we end users are slowly being
"encouraged" to migrate apps to PKI, and so I believe that the solution
should include hooks to support PKI. Historically, user name and
password is also prevalent, so I also believe that the default approach
should also be able to include that. Many other authentication
mechanisms are deployed, and it is A Good Thing to also have provisions
to support them, but I personally do not believe that they are as
compelling as PKI and username-password, which I believe constitute the
absolute minimum default alternatives to be supported.

Concerning whether this goal of supporting PKI and username-password and
other-popular-authentication-mechanisms should be accomplished via PAM
or authentication chaining, that particular issue should probably be
solved by asking which alternative is the cleanest for the ISMS codebase
to support? All things being equal, please favor approaches that are
used elsewhere, such as PAM. 

Rather than "leave to implementations specific approaches" and thereby
not address it in the ISMS codebase, I prefer the codebase itself
implementing PAM as a default, with the provision of optionally
supporting other techniques as well.

My concern is that if we don't provide a default solution to this
problem, then we will continue to have the same types of problems with
ISMS that we currently have with SNMPv3 -- irregularly built
applications so that key distribution can't be assured in large
deployments, despite the presence of RFCs which, if implemented, could
have assured key distribution.

<Kaushik> 

Just to clarify, PAMs are typically provided by operating systems for
password based authentication. SSH2 implementations provide chaining
between X.509 based authentication & password based authentication
methods & rely on PAMs to chain individual password based mechanisms.


</Kaushik>




-----Original Message-----
From: Juergen Schoenwaelder [mailto:[e-mail]]
Sent: Friday, March 16, 2007 12:50 PM
To: Kaushik Narayan (kaushik)
Cc: [e-mail]
Subject:
Re:[Isms]SSHSMRADIUSIntegrationdraft(draft-narayan-isms-sshsm-radius-01.
txt)submitted

On Fri, Mar 16, 2007 at 11:53:44AM -0700, Kaushik Narayan (kaushik)
wrote:
> Hi Juergen,
> 
> I think the question atleast in my mind is about not whether we would 
> support local accounts but more about how to handle them in the 
> context of the current RADIUS integration draft. As I suggested in my 
> previous thread we have two options
> 
> 1. Leave to implementation specific approaches such as a Pluggable 
> Authentication Module (PAM) framework.

As an implementor and system administrator, I like PAM because this is
used by many pieces of software...
 
> 2. Build the chaining of authentication methods into the security 
> model, this would be required especially if we want build an access 
> control model that is RADIUS specific.
> 
> It would be useful to get some discussion on this topic.

... and here I have no clue what this is supposed to be good for or why
things are needed in the security model; remember that access control is
done in the access control model (and all the security processing
including authentication exchanges happen in the secure transport
models, at least for SSH or TLS. Are you saying all the work in the last
months was heading in the wrong direction??


<Kaushik> 

Sorry, my comment is confusing. I wasn't suggesting that we include
authentication part of the access control model. I was really trying to
understand whether we need include PAM like functionality part of the
security model since PAM implementations (for multiple password
mechanisms) might not be available on all operating systems that sshsm
will be deployed. I think you have mentioned this question in your
email.

</Kaushik>



My understanding is that we have in principle two mappings:

a) authenticated principal -> securityName
b) securityName -> groupName

The first mapping a) happens in the security model (USM) or in the
transport mappings (TSM). The mapping b) happens in the access control
subsystem, that is VACM. We should not confuse these things (I think
section 3.3.2 in the RADIUS document is pretty unclear and potentially
confusing things, e.g. sentences such as

   The User-
   Based Security Method (USM) integrates with VACM, by mapping the user
   identity as defined in USM to access rights within VACM.

seem wrong since all USM provides is a securityName. Do you say this is
all wrong? Or is it about how to pass RADIUS attributes provided in
a) up to an access control mapping which does b) that you have in mind?

<Kaushik>

I agree that the text in section 3.3.2 is misleading. The question is
whether we can extend VACM to accept a securityName -> groupName mapping
done by the RADIUS server.

</Kaushik>


/js

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

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

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