Subject: Re: [Isms] fyi: [kerberos security model for snmp]

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 03 Nov 2010 01:48:02 -0400

--On Wednesday, October 27, 2010 07:11:21 AM -0700 Wes Hardaker 
<[email-masked]> wrote:

>>>>>> On Wed, 27 Oct 2010 12:47:12 +0000, "Pejaver, Rajaram"
>>>>>> <[email-masked]> said:
>
> PR> The table on the responder must not have any preexisting
> PR> non-volatile entries for KSM.
>
> I think that's not the correct behavior.  Operators should be able to
> configure the VACM and I think the radius draft addresses this and the
> KSM draft needs to as well.

I think there is an awful lot of confusion here.
Kerberos is an authentication system.  A Kerberos-based security model 
should fit the architecture well; the only hard part is describing the 
mapping between Kerberos principal names and the SNMP securityName.

Kerberos does not _have_ any access control or similar policy; such things 
are more or less out of scope.  I would expect a Kerberos security model to 
be used with VACM, with no interactions between them except as described in 
the SNMP ASIs.

Now, Kerberos does provide a mechanism for transporting a variety of types 
of "authorization data", which can be used to carry information about what 
the holder of a ticket is allowed to do.  Examples of things that might be 
carried as authorization data are POSIX uid/gid/group mappings, SAML 
assertions, X.509 attribute certificates, RADIUS attributes, etc (though at 
present, Kerberos AD types have not been defined for any of these).

I would not expect a Kerberos security model to describe how to handle 
authorization data, except to note that such data might be used to provide 
an implementation- and/or policy-dependent mapping to security names, along 
similar lines to what we did with DTLS (but with far less specificity; 
unlike X.509, Kerberos has only one "natural" name (the principal name), 
which is not contained in authorization data).

If a Kerberos AD type were defined for carrying RADIUS attributes, I'd 
expect to be able to use that AD type, KSM, and the existing RADIUS VACM 
work in a natural way.  RADIUS data would be extracted from Kerberos in an 
unspecified, implementation-dependent way and applied to VACM as already 
specified, with no need for additional language about this in KSM.

Similarly, if work were done to describe management of VACM configuration 
based on SAML assertions, X.509 attribute certificates, or other forms of 
access-control information, and corresponding Kerberos AD types were 
defined for carrying those, I'd expect those to _also_ Just Work, again 
with no need for any language in KSM.

Now, I suspect what people might be thinking of is using the Microsoft PAC, 
which is carried in Kerberos as authorization data, to configure VACM. 
There's no reason that can't be done, but again, the Kerberos Security 
Model need not say anything about it, any more than TSM/SSHTM say anything 
about RADIUS.  One would need to define a mechansim for managing VACM along 
similar lines to the RADIUS work, but that would not be part of any SNMP 
security model and IMHO does not belong in the same document as a Kerberos 
Security Model for SNMP.

-- Jeff

---

From: "Pejaver, Rajaram" <[email-masked]>
Date: Wed, 3 Nov 2010 13:37:27 +0000

Jeff,

This was very well said.  
I can say almost nothing in response, to disagree or add.

For clarity, the KSM model may need to mention that it handles the Authorization Data similar to radius-vacm.
The ISMS group will provide necessary guidance for the wording.

Perhaps, the SNMP securityName could be carried along with the groupName in the AD field of the Kerberos ticket.
(i.e. the securityName, which is the principal's model independent name, is also stored in the Authorization Database)

We deferred discussing the Microsoft PAC, saving it for a future sortie.

Thanks

--raj

-----Original Message-----
From: Jeffrey Hutzelman [mailto:[email-masked]] 
Sent: Wednesday, November 03, 2010 1:48 AM
To: Wes Hardaker; Pejaver, Rajaram
Cc: isms; [email-masked]
Subject: Re: [Isms] fyi: [kerberos security model for snmp]

-- Jeff

---

From: "Dave Nelson" <[email-masked]>
Date: Wed, 3 Nov 2010 13:01:44 -0400

Jeffrey Hutzelman writes...

> Kerberos is an authentication system.

I agree that's how it started out, and that many people still use it that
way.

> Kerberos does not _have_ any access control or similar policy;
> such things are more or less out of scope.

> Now, Kerberos does provide a mechanism for transporting a variety
> of types of "authorization data", which can be used to carry 
> information about what the holder of a ticket is allowed to do.

OK.  I'm claiming that these three quoted sentences constitute a distinction
without any real difference.  If Kerberos can be used to transport
"authorization data", how can one claim that it's *just* an authentication
service?  Yes, it may be that there is no standardized definition of a
"policy engine" in Kerberos KDCs, and the authorization data may come from
some other back-end service.  However, the same can be said for RADIUS.  If
it walks like a duck...  :-)