RE: [Isms] charter proposal

["David B Harrington" <ietfdbh at comcast.net>]

Hi Juergen,

>From my limited experince looking at the problem,

If we start to discuss HOW the SSH will support AAA, then we will need
to discuss
1) which AAA protocol?
2) which AAA attributes contain the authorization information
2a) should we use filterID, which is supposed to be for packet
filtering, not policy management
2b) should we define a new standard attribute for this purpose, since
the only attributes available don't provide the granularity we need?
2c) should vendors develop their own VSAs to provide this granularity?
3) will we standardize the naming mechanisms for ACM policies?
4) will we support user-to-group mappings or user-to-policy mappings
(i.e. non-group policies)?

And so on....

I'd like to avoid the whole discussion of how to connect SNMP
authorization to AAA authorization for now, and simply focus on how to
connect SSH user-auth to SNMP user-auth.

However, if the WG REALLY wants to trigger/capture AAA-authorization
via the security model, we'll need to open that whole can of worms,
because it will require changes to the architecture or an agreement of
how to do it outside the architecture (wink, wink).

David Harrington
dbharrington at comcast.net

> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:j.schoenwaelder at iu-bremen.de] 
> Sent: Tuesday, August 02, 2005 1:06 PM
> To: David B Harrington
> Cc: isms at ietf.org
> Subject: Re: [Isms] charter proposal
> 
> On Tue, Aug 02, 2005 at 12:54:06PM -0400, David B Harrington wrote:
> 
> > Hmmmm. I am of the impression that, as a source for
authentication,
> > the use of AAA is an implementation-dependent detail of the SSH
> > authentication; whether SSH authentication relies on RADIUS 
> or AAA or
> > local users to authenticate the transport connection and the user
> > should be transparent to the SNMP engine, shouldn't it? If 
> so, then it
> > doesn't belong in the charter at all.
> 
> I agree that this is fully transparent to the SNMP engine. On the
> motivational side of the charter, I thought it might be worth to
> mention this since not everybody might be aware that SSH
> authentication decisions can easily be outsourced to AAA servers,
> something that was requested in the past by operators.
> 
> > Where we run into the problem is if a TMSM also needs to somehow
> > capture the authorization information returned by AAA so the AC
> > subsystem can use it later. If we want that feature, and we seem
to
> > have a lot of people suggesting it is an important feature 
> to support,
> > then we need to address how to standardize that feature so 
> future TMSM
> > security models handle it in a compatible way. 
> 
> I simply did not put this in the charter since I do not yet
understand
> the dimension of this problem. I need to learn more how AAA servers
> provide this authorization information and how it looks like.
Perhaps
> someone here can educate me or point to the relevant specs to read.
> 
> /js
> 
> -- 
> Juergen Schoenwaelder		    International University Bremen
> <http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 
> 28725 Bremen, Germany
> 



_______________________________________________
Isms mailing list
Isms at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms