Subject: [Isms] SSHSM RADIUS Integration draft (draft-narayan-isms-sshsm-radius-01.txt) submitted

From: "Kaushik Narayan \(kaushik\)" <[email-masked]>
Date: Wed, 14 Mar 2007 12:20:18 -0700

Hi All,
 
The RADIUS integration draft for SSHSM has been submitted to the drafts
directory. The draft specifies details how RADIUS could be used as an
authentication and authorization mechanism for SSHSM. 
 
This draft currently describes two approaches for integration of
authorization information returned from the RADIUS server.
 
a. Receive authorization information along with authentication request
(traditional RADIUS model) & cache authorization information within
TMSM. Augment VACM in an implementation-dependent fashion to fetch
authorization parameters from TMSM (using tmStateReference).
b. Define a new access control model that can issue direct RADIUS
authorize-only requests to fetch authorization information on demand.
This approach will also require the use of the TMSM cache to store the
RADIUS state attribute. The draft does not elaborate on the details of
such an access control model.
 
We need further discussion within the WG on the two approaches and
whether we need to elaborate on both. 
 
regards,
 David Nelson & Kaushik Narayan
_______________________________________________
Isms mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isms

---

From: "David Harrington" <[email-masked]>
Date: Wed, 14 Mar 2007 15:59:51 -0400

Hi,
 
Following ietf66, we changed direction somewhat in ISMS. There is no
SSHSM anymore; there is a Transport subsystem, an SSH-TM (transport
model), and a TSM (Transport Security Model).
 
Currently, we do not pass the tmStateReference into the
IsAccessAllowed ASI. I don't think we even pass it tothe applications,
and the applications call IsAccessAllowed, so you may be talking about
changing a few ASIs.
 
Another way to approach the problem would be to use a MIB to store the
transport&security information in a local configuration database
addressable by securityName/securityModel/securityLevel and
transportDomain/Address. Another RADIUS-specific MIB could contain
RADIUS information, and that MIB could AUGMENT the transport&security
MIB.
 
Actually I can envision 3 MIB modules:
1) known to a specific transport model, indexed by
securityN/L,transportD/A, independent of securityModel
2) known to the Transport Security Model, contains TSM-specific info
indexed by securityN/L and trasnportD/A, indepednent of specific
transport models but it can get a pointer to a specific transport row
using securityNL,transportDA
3) a RADIUS-specific MIB indexed by securityM/N/L,transportDA. This
MIB could store authoriaztion info and the RADIUS state. A
RADIUS-spepxcifc ACM could check for a RADIUS state attribute in the
transport model MIB.
 
I'm not sure this maintains the modulairty as much as we want, but at
least we' can try to lay the MIBs out in a way that they can remain
independnent of each other, and define some common MOs to be used by
potentially multiple models within a subsystem, and make the MOs
accessible in a model-independent manner from other subsystems.
 
dbh

  _____  

From: Kaushik Narayan (kaushik) [mailto:[email-masked]] 
Sent: Wednesday, March 14, 2007 3:20 PM
To: [email-masked]
Subject: [Isms] SSHSM RADIUS Integration
draft(draft-narayan-isms-sshsm-radius-01.txt) submitted 

Hi All,
 
The RADIUS integration draft for SSHSM has been submitted to the
drafts directory. The draft specifies details how RADIUS could be used
as an authentication and authorization mechanism for SSHSM. 

 
 
regards,

---

From: "David B. Nelson" <[email-masked]>
Date: Thu, 15 Mar 2007 08:19:59 -0400

David Harrington writes... 

> IsAccessAllowed ASI. I don't think we even pass it to the 
> applications, and the applications call IsAccessAllowed, 
> so you may be talking about changing a few ASIs.

The modularity of the current SNMP architecture seems to be predicated upon
the notion that passing around securityName is all that is ever needed.
That seems to be predicated on the notion that there is a local
configuration store that contains useful information addressed by
securityName.  That seems to imply USM or something very much like it.  If
we really want to break the ties to USM, we're going to need to address this
issue.

> Another way to approach the problem would be to use a MIB
> to store the transport&security information in a local 
> configuration database addressable by 
> securityName/securityModel/securityLevel and 
> transportDomain/Address. Another RADIUS-specific MIB could 
> contain RADIUS information, and that MIB could AUGMENT the 
> transport&security MIB.

So, maybe that is one way to address the issue.  I'll need a bit to time to
absorb all this...

---

From: "David Harrington" <[email-masked]>
Date: Thu, 15 Mar 2007 10:07:35 -0400

> the notion that passing around securityName is all that is 

Roughly, that's true. 
The other model-dependent details should be hidden within the specific
models.

> securityName. 

That's not quite true. 

In fact, the goal of the modularity is to NOT share model-specific
information in the background through a LCD; that type of sharing is
one of the problems that was so hard to fix in SNMPv2. We had problems
because different operators/implementers want different capabilities
for different reasons, and different SNMPv2 designs kept overwriting
each other in the "global memory" that is the LCD. The modular
approach allowed us to specify model-specific LCDs (MIB modules),
modifiable only by the defining model, to prevent volatile changes to
the data. 

> That seems to imply USM or something very much 
> like it.  If

So far, I have not seen any proposals, either written or just proposed
verbally, that provides a secure transport with all the security
characteristics of USM. A critical feature of USM, not provided by SSH
or TLS or RADIUS proposals so far, is local authentication with NO
ties to a third party authenticator.

SNMP is deliberately built to work even when network connectivity is
impaired. There are a number of design decisions based on this
requirements, including having UDP as a mandatory-to-implement
transport, messages sizes that do not require fragmentation, and local
authentication. SNMP is designed to use a local authentication model
(two-party - the manager and agent) rather than a three-party
authentication model, because it might be impossible to reach the
third party due to network impairment. Any solution that requires a
third party authentication server, or a CA, or any other third-party
security functionality does not meet all the requirements of SNMP.

The USM model combined with the UDP/IPv4 transport model meets the
SNMP "reachability" requirements and the SNMP message security
requirements. We can **supplement** USM with secure transport models,
and centralized authentication and authorization, that are easier to
use but do not meet the "reachability" requirement, as long as USM and
UDP transport are still mandatory to implement.

I don't think we can break the ties to USM until we either 
1) design a new security model that provides this non-reliance on
third-parties at runtime, or
2) decide that the ability for SNMP to work when network connectivity
is impaired is no longer a requirement of SNMP design.

Dbh

---

From: Eliot Lear <[email-masked]>
Date: Thu, 15 Mar 2007 16:15:33 +0100

> ties to a third party authenticator.

Well define 3rd party.  BEEP with TLS+SASL does the job quite nicely, 
but when one uses TLS one must of course take some care regarding trust 
anchors.  If you're doing CRL checks then you are probably going off 
box, unless YOU signed the cert.  But most people don't do CRL checks at 
all.

Eliot

---

From: "David Harrington" <[email-masked]>
Date: Thu, 15 Mar 2007 16:44:33 -0400

Party #1: an snmp engine (e.g., a manager) 
Party #2: another snmp engine (e.g., an agent)
Party #3: anybody else not co-locaetd with #1 or #2 that needs to be
involved.

With USM, only #1 and #2 need to be able to reach each other.

dbh

> -----Original Message-----
> From: Eliot Lear [mailto:[email-masked]] 
> Sent: Thursday, March 15, 2007 11:16 AM
> To: David Harrington
> Cc: 'David B. Nelson'; [email-masked]
> Subject: Re: [Isms] SSHSM 
> RADIUSIntegrationdraft(draft-narayan-isms-sshsm-radius-01.txt)
>  submitted
> 
> David Harrington wrote:
> >  
> >
> >

---

From: "Kaushik Narayan \(kaushik\)" <[email-masked]>
Date: Thu, 15 Mar 2007 16:04:23 -0700

Hi David,

Please find my reply inline. 

<snipped>

That's not quite true. 

In fact, the goal of the modularity is to NOT share model-specific
information in the background through a LCD; that type of sharing is one
of the problems that was so hard to fix in SNMPv2. We had problems
because different operators/implementers want different capabilities for
different reasons, and different SNMPv2 designs kept overwriting each
other in the "global memory" that is the LCD. The modular approach
allowed us to specify model-specific LCDs (MIB modules), modifiable only
by the defining model, to prevent volatile changes to the data. 

<Kaushik> I think one of the issues being out here is that we still
require the securityName(s) to be defined on every SNMP engine (similar
to USM) and that creates a manageability issue. The reason
administrators deploy external authentication mechanisms such as RADIUS
is to avoid having to manage securityName(s) on every SNMP engine. 

> That seems to imply USM or something very much like it.  If we really 
> want to break the ties to USM, we're going to need to address this 
> issue.

So far, I have not seen any proposals, either written or just proposed
verbally, that provides a secure transport with all the security
characteristics of USM. A critical feature of USM, not provided by SSH
or TLS or RADIUS proposals so far, is local authentication with NO ties
to a third party authenticator.

SNMP is deliberately built to work even when network connectivity is
impaired. There are a number of design decisions based on this
requirements, including having UDP as a mandatory-to-implement
transport, messages sizes that do not require fragmentation, and local
authentication. SNMP is designed to use a local authentication model
(two-party - the manager and agent) rather than a three-party
authentication model, because it might be impossible to reach the third
party due to network impairment. Any solution that requires a third
party authentication server, or a CA, or any other third-party security
functionality does not meet all the requirements of SNMP.

The USM model combined with the UDP/IPv4 transport model meets the SNMP
"reachability" requirements and the SNMP message security requirements.
We can **supplement** USM with secure transport models, and centralized
authentication and authorization, that are easier to use but do not meet
the "reachability" requirement, as long as USM and UDP transport are
still mandatory to implement.

I don't think we can break the ties to USM until we either
1) design a new security model that provides this non-reliance on
third-parties at runtime, or
2) decide that the ability for SNMP to work when network connectivity is
impaired is no longer a requirement of SNMP design.

<Kaushik>  It is very common in authentication systems to chain a set of
authentication methods, I can think a similar capability is what is
required. This is supported by PAM configuration that is typically used
by SSH implementations. Alternatively we can build this into the
security model and allow fallback to a local user database in case
reachability is not available.

regards,
   kaushik

Dbh

> 
> > Another way to approach the problem would be to use a MIB to store 
> > the transport&security information in a local configuration database

> > RADIUS information, and that MIB could AUGMENT the 
> > transport&security MIB.
> 
> So, maybe that is one way to address the issue.  I'll need a bit to 
> time to absorb all this...
> 
> 
> 
>

---

From: Eliot Lear <[email-masked]>
Date: Fri, 16 Mar 2007 06:36:51 +0100

> Party #3: anybody else not co-locaetd with #1 or #2 that needs to be

Yes, SASL+TLS could easily handle this case under the constraints I 
previously mentioned.

Eliot

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 16 Mar 2007 09:47:24 +0100

On Thu, Mar 15, 2007 at 04:04:23PM -0700, Kaushik Narayan (kaushik) wrote:

> [...] A critical feature of USM, not provided by SSH or TLS or
> RADIUS proposals so far, is local authentication with NO ties to a
> third party authenticator.

Isn't a locally stored password or key pair providing just exactly
that feature?

Anyway, I am in general quite confused by this thread as it seems that
people talk about different things without really trying to understand
the other's background / terminology / view of the world.

Perhaps it helps to go through the RADIUS document and to bring up
paragraphs that are considered problematic and to propose alternative
text fragments so that we avoid getting trapped in some general and
abstract discussions that we had in the past and which might not be
effective to improve our documents.

/js

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

---

From: Eliot Lear <[email-masked]>
Date: Fri, 16 Mar 2007 12:26:08 +0100

> effective to improve our documents.

TMSM should work both with a local store AND radius.  If there are 
problems with either that's what needs to be found.  This thread came up 

> ties to a third party authenticator.

Kaushik, Keith and I proposed a method last summer that would have 
precisely addressed the 2nd sentence in that paragraph.  I believe this 
leaves David Nelson's question somewhat unanswered.

Eliot

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 16 Mar 2007 12:41:02 +0100

> leaves David Nelson's question somewhat unanswered.

Again, is a local password or key pair in the context of SSH not
exactly addressing the 2nd sentence above, namely "local
authentication with NO ties to a third party authenticator"? I remain
in the confused state for now.

/js

PS: Our implementation calls out to PAM and it actually does not
    matter whether you configure radius, something else, or local
    passwords if you like that.

---

From: "David Harrington" <[email-masked]>
Date: Fri, 16 Mar 2007 08:09:28 -0400

Hi,

Yes, I was off-track.
A local password or key pair should be acceptable.

dbh 

> From: Juergen Schoenwaelder [mailto:[email-masked]] 
> Sent: Friday, March 16, 2007 7:41 AM
> To: Eliot Lear
> Cc: Kaushik Narayan (kaushik); David Harrington; David B. 
> Nelson; [email-masked]
> Subject: Re: 
> [Isms]SSHSMRADIUSIntegrationdraft(draft-narayan-isms-sshsm-rad
> ius-01.txt)submitted
>

---

From: "Kaushik Narayan \(kaushik\)" <[email-masked]>
Date: Fri, 16 Mar 2007 11:53:44 -0700

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.

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.

regards,
  kaushik!

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Friday, March 16, 2007 4:41 AM
To: Eliot Lear
Cc: Kaushik Narayan (kaushik); David Harrington; David B. Nelson;
[email-masked]
Subject: Re:
[Isms]SSHSMRADIUSIntegrationdraft(draft-narayan-isms-sshsm-radius-01.txt
)submitted

On Fri, Mar 16, 2007 at 12:26:08PM +0100, Eliot Lear wrote:
 
> >So far, I have not seen any proposals, either written or just 
> >proposed verbally, that provides a secure transport with all the 
> >security characteristics of USM. A critical feature of USM, not 
> >provided by SSH or TLS or RADIUS proposals so far, is local 
> >authentication with NO ties to a third party authenticator.
> 
> precisely addressed the 2nd sentence in that paragraph.  I believe 
> this leaves David Nelson's question somewhat unanswered.

Again, is a local password or key pair in the context of SSH not exactly
addressing the 2nd sentence above, namely "local authentication with NO
ties to a third party authenticator"? I remain in the confused state for
now.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 16 Mar 2007 20:50:28 +0100

> Authentication Module (PAM) framework.

As an implementor and system administrator, I like PAM because this is
used by many pieces of software...
 
> 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??

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?

/js

---

From: "Fleischman, Eric" <[email-masked]>
Date: Mon, 19 Mar 2007 10:34:36 -0700

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.

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Friday, March 16, 2007 12:50 PM
To: Kaushik Narayan (kaushik)
Cc: [email-masked]
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:
> 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
> 

> 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.
> 

... 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??

   The User-

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?

/js

---

From: "Kaushik Narayan \(kaushik\)" <[email-masked]>
Date: Mon, 19 Mar 2007 17:27:02 -0700

Hi Eric,

<snipped>

<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:[email-masked]]
Sent: Friday, March 16, 2007 12:50 PM
To: Kaushik Narayan (kaushik)
Cc: [email-masked]
Subject:

 

<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>

   The User-

<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

---

From: "Fleischman, Eric" <[email-masked]>
Date: Tue, 20 Mar 2007 09:09:06 -0700

Kaushik,

Yes, I am aware that my suggestions for a default PKI and
username/password authentication basis correlates well with a SSHv2
transport (and RADIUS) and that there are O/S implications to source
code. 

However, the itch that I want scratched is that I want ISMS to include a
viable default solution to key management so that the currently onerous
problem with key distribution in large SNMPv3 deployments would be
solved for ISMS. It's not enough to provide RFCs offering theoretical
solutions. The specs themselves need to create default interoperable
products that adequately (i.e., securely, scalably) handle key
distribution issues. [By "key distribution" I am not solely considering
symmetric and asymmetric keys, but also include the issue of secure
username/password distribution.]

--Eric