Subject: [Isms] Tmsm#2: cache contents

From: "David Harrington" <[email-masked]>
Date: Fri, 16 Feb 2007 09:59:38 -0500

>From Bert Wijnen (1/12):

"> - I am not 100% sure, but is it correct that section 5.1. about the
>   securityStateReference is not adding any new (or changing any
>   existing) information compared to RFC3411?
>   If so, I would prefer we state that explicitly.
>   If it does add something, pls make it clear what is being
> added/changed.
> 
> - Section 5.2
>   I think (but it is not clear) that the transport model should save
>   a mapping from transport security/authentication ID to
seucirtyName
>   so the the Security Model can pick it up and pass it back as an
>   OUT parameter on the processIncomingMessage ASI,. no?"

Dbh response:

Yes, this information should be saved in one of the caches. The format
and contents of the caches are implementation-specific however, so I
don't know what information we can discuss. The transport model might
also need to know the authentication algorithm, the integity-checking
and encryption parameters, and so on. These are very much
transport-model specific. The way we deal with it is to provide two
caches - one for the request/response pair, and another for the
session-like mechanism. It is up to the implementer to decide what
goes where. Added to Open Issues for discussion."

Bert: "
I'd say we need to just state that thuis is what we expect, and that
each specific transport model needs to be specific as to what kind
of data needs to be saved in order tolet aSecurity Model be able to
pick up the proper data that it needs."

DBH:
"The related security parameters may include transport-specific
security information."
I am not sure that the security experts would like to see MUST
language about what needs to be included. This would potentially limit
algorithm agility. It also might depend on the libraries they are
using to implement; different libraries may require different
parameters. So the cached information is transport-model and
implementation dependent:

"A Transport Model may store transport-specific parameters in the
cache for subsequent usage. Since the contents of a cache are
meaningful only within an implementation, and not on-the-wire, the
format of the cache is implementation-specific."

"For each message or transport session, information about the message
security is stored in a cache, which may include model- and
mechanism-specific parameters. The tmStateReference is passed between
subsystems to provide a handle for the cache. A Transport Model may
store transport-specific parameters in the cache for subsequent usage.
Since the contents of a cache are meaningful only within an
implementation, and not on-the-wire, the format of the cache is
implementation-specific."

To keep things modular, a secure transport model translates from
transport-specific security principal to securityName, and passes the
securityName in the cache.  The transport model determines what
security services were provided by the transport, and puts
securityLevel into the cache. A security model does not need to know
anything about the transport specific principal or services. The
security model just takes securityName and securityLevel from the
cache, already translated. Otherwise we would have a problem of
requiring a specific security model for each specific transport model,
something we definitely want to avoid.

What happens with the cache depends on the security model called by
the message processing model. Some might take the values from the
cache to return to the MPM; some might just use parameters provided in
a message security block and totally ignore the cache; some might use
a mapping from a MIB module and totally ignore the cache.

David Harrington
[email-masked] 
[email-masked]
[email-masked]

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 27 Feb 2007 10:59:30 +0100

> a mapping from a MIB module and totally ignore the cache.

Can we resolve this issue by spelling out (a) which SNMP parameters
need to be maintained in the cache and at the same time we spell out
(b) that there might be additional parameters used by the secure
transport, which are specific to the secure transport itself (and need
not be spelled out since this is the job of the secure transport
technology to spell out if desirable)?

/js

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

---

From: "Wijnen, Bert \(Bert\)" <[email-masked]>
Date: Tue, 27 Feb 2007 11:10:56 +0100

Yep, that probably works. Need to see the text of course.

Bert 

> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:[email-masked]] 
> Sent: dinsdag 27 februari 2007 11:00
> To: David Harrington
> Cc: [email-masked]
> Subject: Re: [Isms] Tmsm#2: cache contents
> 
> > each specific transport model needs to be specific as to 
> what kind of 
> > data needs to be saved in order tolet aSecurity Model be 
> able to pick 
> > up the proper data that it needs."
> > 
> > DBH:
> Can we resolve this issue by spelling out (a) which SNMP 
> parameters need to be maintained in the cache and at the same 
> time we spell out
> (b) that there might be additional parameters used by the 
> secure transport, which are specific to the secure transport 
> itself (and need not be spelled out since this is the job of 
> the secure transport technology to spell out if desirable)?
> 
> /js
> 
> --

---

From: "David Harrington" <[email-masked]>
Date: Tue, 27 Feb 2007 11:17:24 -0500

Please see revision -06-.
Is that text OK?

dbh

> From: Wijnen, Bert (Bert) [mailto:[email-masked]] 
> Sent: Tuesday, February 27, 2007 5:11 AM
> To: [email-masked]; David Harrington
> Cc: [email-masked]
> Subject: RE: [Isms] Tmsm#2: cache contents
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 27 Feb 2007 19:21:58 +0100

> Please see revision -06-.

I assume you are referring to section 5, right? If my guess is correct,
I believe this text is just fine for me.

/js

---

From: "Wijnen, Bert \(Bert\)" <[email-masked]>
Date: Tue, 27 Feb 2007 22:20:57 +0100

A quick read seems to make me happy.
I may come back to this when I reread the whole doc. 
But at first sight iy looks fine.

Bert

> Sent: dinsdag 27 februari 2007 19:22
> To: David Harrington
> Cc: Wijnen, Bert (Bert); [email-masked]
> I assume you are referring to section 5, right? If my guess 
> is correct, I believe this text is just fine for me.
> 
> /js
> 
> --