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

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 26 Oct 2010 10:14:01 +0200

Hi,

I have sent the email below to the kerberos working group in order to
make them aware of the kerberos security model for snmp and to solicit
technical advice/assistance.

/js

----- Forwarded message from Juergen Schoenwaelder <[email-masked]> -----

Date: Tue, 26 Oct 2010 10:10:56 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
Subject: kerberos security model for snmp
Message-ID: <[email-masked]>

Hi,

a kerberos security model for the simple network management protocol
(snmp) has been proposed to the ISMS working group. I like to solicit
feedback on the proposal from the kerberos community. The document can
be found here:

http://tools.ietf.org/html/draft-pejaver-isms-kerberos-01

We are going to have a technical discussion of this proposal at the
Beijing IETF in the Wednesday 15:10-16:10 time slot. Perhaps some of
you can join this meeting to make sure things are heading into the
right direction. Please send any questions / comments to the ISMS
working group mailing list <[email-masked]>.

/js (ISMS co-chair)

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

----- End forwarded message -----

---

From: "Lee, Yiu" <[email-masked]>
Date: Tue, 26 Oct 2010 08:52:59 +0000

Thanks Juergen.

On Oct 26, 2010, at 4:14 AM, "Juergen Schoenwaelder" <[email-masked] 
 > wrote:

> ----- Forwarded message from Juergen Schoenwaelder <[email-masked] 
> > -----
>
> _______________________________________________
> Isms mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isms

---

From: "t.petch" <[email-masked]>
Date: Tue, 26 Oct 2010 18:40:18 +0200

I think that this I-D has some way to go.

- There seems to be a confusion over what a Security Model is, in that s2.1
states that
" The first security models, USM [RFC3414]and VACM [RFC3415] ..."

while if, as s6.2 says, this is "Compatible with VACM." then what is s4.3 doing?

I expect a security model to specify how securityEngineID and securityName are
derived, which this I-D does not do, and then leave VACM to get on with it.

Then again, s2.6 says
"For KSM, this value must contain the permissions for the specific
   user on the identified device.  Though the semantics of this value
   can vary widely, for SNMP it is constrained to be a VACM groupName
   that the user should be placed into."
Well no, this is nothing to do with SNMP, this is to do with KSM or not; this is
really a rerun of RADIUS, in that if Kerberos is supplying a securityName to
groupName mapping, then that needs to be incorporated in the VACM table; sounds
like we need a
ietf-isms-kerberos-vacm

- s3.4, 3.5 and 3.6 seem to ignore the work of the isms WG in that the ASIs of
RFC5590 are ignored.

- And s.5 has
"Traps and Reports are handled just as all other outgoing requests."
which suggests a lack of understanding of security for Notifications.

(and there is plenty more:-(

Tom Petch

----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, October 26, 2010 10:14 AM
Subject: [Isms] fyi: [kerberos security model for snmp]

> ----- Forwarded message from Juergen Schoenwaelder
<[email-masked]> -----

---

From: "Pejaver, Rajaram" <[email-masked]>
Date: Tue, 26 Oct 2010 19:26:37 +0000

t.petch said:

[RAJ] Agreed.  We need your help along the way.

[RAJ] A command responder that implements KSM may not have a configurable vacmSecurityToGroupTable.
[RAJ] Instead, the "groupName (x)" will simply be the value that was extracted from the ticket.
[RAJ] (I am referring to s3.1 in RFC 3415 for above.)

[RAJ] The securityName is extracted from the ticket in s4.2.
[RAJ] There is no securityEngineID.

Then again, s2.6 says
like we need a ietf-isms-kerberos-vacm

[RAJ] I don't understand your statement.
[RAJ] Yes, the Kerberos server (effectively) is providing the securityName to group mapping.
[RAJ] As stated above, step 2 of isAccessAllowed(), the VACM vacmSecurityToGroupTable would
[RAJ] return the value that was extracted from the ticket.

[RAJ] Do you mean tmStateReference?  Oops.  Good catch.

- And s.5 has

[RAJ] A lot of sections need to be explained further.
[RAJ] It isn't always clear to me as to what is necessary and what is redundant, so comments are valuable.
[RAJ] The goal for the present version was to give an outline, and to improve the document structure.

[RAJ] I am sure...  Thanks for your comments.

--raj
Rajaram Pejaver
Comcast

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 27 Oct 2010 11:53:32 +0200

> [RAJ] (I am referring to s3.1 in RFC 3415 for above.)

With RADIUS, the supplied mapping is overwritten by local VACM
configuration. You seem to propose a different model. I believe this
needs to be carefully looked at.
 
> [RAJ] return the value that was extracted from the ticket.

Sorry, we likely won't change what isAccessAllowed() in VACM does. So
things have to work with the elements of procedure documented in
RFC3415. This is why RADIUS supplied group mappings cause volatile
entries to be added to the vacmSecurityToGroupTable if they do not
collide with non-volatile config.

/js

---

From: "Pejaver, Rajaram" <[email-masked]>
Date: Wed, 27 Oct 2010 12:47:12 +0000

> [RAJ] (I am referring to s3.1 in RFC 3415 for above.)

[JS] With RADIUS, the supplied mapping is overwritten by local VACM
[JS] configuration. You seem to propose a different model. I believe this
[JS] needs to be carefully looked at.

We are proposing exactly the same procedure as in draft-ietf-isms-radius-vacm-11.
The supplied mapping from the ticket is overwritten -into- local VACM configuration.
No new models are being added to RFC3415 (VACM).

> [RAJ] return the value that was extracted from the ticket.

[JS] Sorry, we likely won't change what isAccessAllowed() in VACM does. So
[JS] things have to work with the elements of procedure documented in
[JS] RFC3415. This is why RADIUS supplied group mappings cause volatile
[JS] entries to be added to the vacmSecurityToGroupTable if they do not
[JS] collide with non-volatile config.

Again, no change is being requested to RFC3415 (VACM).
To be more clear, I will copy language from draft-ietf-isms-radius-vacm-11 into our next draft.
I do not have that doc handy at the moment, but conceptually something as follows:
- The groupName authorization value is inserted into the vacmSecurityToGroupTable and
  is associated with the securityName (same as Kerberos principal name) and the model (KSM).
  This happens when the incoming request is being processed.
  The update procedure is as described in radius-vacm.
- When isAccessAllowed() is subsequently executed, it will pick up the correct groupName
  from vacmSecurityToGroupTable.  
- At the end of the SNMP operation, the table entry (association) must be deleted.
  The table on the responder must not have any preexisting non-volatile entries for KSM.

Please pardon my language & terminology.  I will get that right eventually.

--raj
Rajaram Pejaver
Comcast

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 27 Oct 2010 07:11:21 -0700

>>>>> 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.
-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: "Pejaver, Rajaram" <[email-masked]>
Date: Wed, 27 Oct 2010 16:38:45 +0000

Wes said:

[WES] PR> The table on the responder must not have any preexisting
[WES] PR> non-volatile entries for KSM.
[WES] I think that's not the correct behavior.  Operators should be able to
[WES] configure the VACM and I think the radius draft addresses this and the
[WES] KSM draft needs to as well.

I agree that pre-configuration of local name->group mappings may be useful sometimes,
especially while testing & trouble shooting devices.

Question, is an error generated if the existing entry is non-volatile, and the new groupName
is different from the existing one?
Or is the old value silently used, thereby potentially causing an inexplicable error
later in isAccessAllowed()?
Where can I find the answer?

Say a request comes in with sufficient privileges, but there is a previously configured
value with insufficient privileges inadvertently left behind on the managed device.
The resulting error could be confusing.  It won't point to the root cause.
Also, Security fascists typically do not like locally unique security settings.

Say KSM adds an entry to the table like { securityModel, securityName, groupName, sessionID }
The sessionID must be a number unique for each new command request.

This aligns KSM with radius-vacm.
It also solves the problem of having multiple concurrent requests from the same principal
but with different groupNames, if that ever happens.
But it takes away the capability of pre-configuration of local name->group mappings.

I am just thinking, but perhaps the ideal behavior could be for VACM to search the table
for a match on the sessionID first.
If no entry is found, then that means that no authorization information was found in the ticket.
VACM could then look for a default non-volatile entry and use that value.
Food for thought for later.  Much much later...

--raj
Rajaram Pejaver
Comcast

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 27 Oct 2010 12:48:40 -0700

Hi -

> From: "Pejaver, Rajaram" <[email-masked]>
> To: "Wes Hardaker" <[email-masked]>
> Cc: "isms" <[email-masked]>
> Sent: Wednesday, October 27, 2010 9:38 AM
> Subject: Re: [Isms] fyi: [kerberos security model for snmp]
...
> Where can I find the answer?

http://www.ietf.org/id/draft-ietf-isms-radius-vacm-11.txt 7.2.3

> Also, Security fascists typically do not like locally unique security settings.

Discussed at length on this WG mailing list.  Conclusion was that a device-specific
policy explicitly configured by a security administrator should indeed take precedence
over "global" AAA settings.

> The sessionID must be a number unique for each new command request.

This would work, but why is a new number *necessary* for each command request?
Maintaining a small amount of state within KSM would avoid this overhead.

> but with different groupNames, if that ever happens.

I think http://www.ietf.org/id/draft-ietf-isms-radius-vacm-11.txt 7.3 already addresses
this issue.

> But it takes away the capability of pre-configuration of local name->group mappings.

How/Why?

> for a match on the sessionID first.

VACM knows absolutely nothing about sessions.  Do you perhaps mean KSM?

> Food for thought for later.  Much much later...

This sounds like an overly convoluted approach.

Randy