Subject: [Isms] IPFIX session summary

From: Juergen Quittek <[email-masked]>
Date: Thu, 13 Jul 2006 19:21:10 +0200

ISMS Session Summary
Wednesday, July 12, 2006, 1510-1610

The two existing WG I-Ds on a transport mapping model and on an SSH
security model for SNMP still have few remaining decisions to be made.
There was consensus on clearly separating user authentication for
establishing a transport session from authorization required for
access control to MIB elements.
The discussion on how to create sessions for notifications from a
managed mode to a management system could still not get solved. From
the management system point of view, there is a clear preference for
initiating TLS sessions in 'reverse' direction.  However, the security
problems implied by this approach might be too severe to use it.
Finally, the WG discussed RADIUS integration of the SSH security model.
There seems to be different positions in the security community about
whether or not 'authorization only' requests harmonize or dis-harmonize
with the Kerberos architecture.

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 13 Jul 2006 19:28:40 +0200

> with the Kerberos architecture.

I like to add that the room had concensus to introduce a transport
sub-system into the TMSM document which has the nice side effect of
simplifying the terminology significantly.  In particular, the TMSP
becomes a transport model and the SMSP becomes a more generic
session-based security model (which might map to multiple different
session-based secure transports). See Dave Harrington slides for the
details.

/js

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

---

From: Eliot Lear <[email-masked]>
Date: Thu, 13 Jul 2006 20:39:19 +0200

Juergen,

> problems implied by this approach might be too severe to use it.
Could someone elaborate on what they think those implications are?
> with the Kerberos architecture.
A simple approach to take here would be to say that if you're using
Kerberos to authenticate you must fill in appropriate VACM tables OOB. 
This would, therefore, involve a bunch of null functions for Kerberos.

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Thu, 13 Jul 2006 21:16:01 +0200

Juergen Schoenwaelder wrote:
> On Thu, Jul 13, 2006 at 08:39:19PM +0200, Eliot Lear wrote:
>
>   
> Two observations:
> (a) The security name to group name mapping is a VACM feature and once
>     you are in VACM in our architecture, you surely do not know
>     anymore what was actually used down there in the SSH layer to
>     actually perform the authentication. We do have a layered
>     architecture and we should not break up those layers.
>   

Right.  Nothing I proposed would do that.  I'm saying that for Kerberos
and others, for instance, you use the existing VACM rules with the
Kerberos principal name.  That's all.

> (b) Our charter currently says:
>
>     Work on new access control models or centralized administration of
>     View-based Access Control Model (VACM) rules and mappings is outside
>     the scope of the working group.
>   
I don't understand what would need to change re the above, so I'm not
sure how we get to (b), which I believe to be a general SNMP shortcoming
not limited to ISMS.

Eliot

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 13 Jul 2006 21:00:40 +0200

Two observations:

As much as I understand the desire to have a security name to group
name mapping coming from AAA, it seems that we are currently not
chartered to provide it. Note that relevant RADIUS attributes have
been proposed to the radext WG and people really interested to have
support should read
    
	draft-nelson-radius-management-authorization-03.txt

and help David Nelson to move this document along in RADEXT.

/js