Subject: RE: [Isms] Discussion: Architecture direction for ISMS

From: "Sharon Chisholm" <[email-masked]>
Date: Tue, 5 Apr 2005 10:32:59 -0400

hi

Out of band keying is what is required.

Sharon 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Ken Hornstein
Sent: Friday, March 18, 2005 6:40 PM
To: [email-masked]
Subject: [Isms] Discussion: Architecture direction for ISMS

Greetings all,

As you all know, the outcome from the ISMS working group meeting was that
due to a number of events, we are now tasked with deciding on the
architecture to use for ISMS.  As discussed in the meeting, there are three
obvious choices, which neatly correspond to the three proposed ISMS
protocols.  Note that choosing a security architecture doesn't necessarily
mean we have to choose the particular proposed protocol; my expectation is
that once we pick a particular architecture, we'll develop a new protocol
based on that architecture.

As I see it, we have the following architectures to choose from.  Note that
when I say "features", I'm not making a decision on whether or not a feature
is good or bad; it's just some of the more important points to consider. I
have no doubt others will have other features to bring up about each
architecture.

- "Out of Band Keying"

  This is the approach chosen by EUSM.  Essentially, a seperate protocol
  exchange is conducted between the manager and agent (or a third party)
  and a key is then established/derived for use with standard USM.

  Features:

  - Can make use of existing USM (already-analyzed protocol).
  - Likely wide variety of IETF protocols to use as out-of-band keying
protocol
  - Encryption/checksum modes limited to ones supported by USM
  - Extra care would be required to assure keying material derived from
    out-of-band exchange is matched with a particular USM session.

- "In Band Keying"

  This is the approach taken by SBSM.  The security protocol is
  contained within SNMP payloads and likely whatever protocol is chosen
  will have a way to secure the PDU contents.

  Features:

  - Requires new SNMP security model.
  - Is more in line with the traditional way security is applied to
    application protocols.
  - Exact privacy/integrity details will need to be specified by this or
    other protocol (depending on which framework is chosen).

- "Encapsulation keying"

  This is the approach taken by TLSM.  An encapsulation protocol (such
  as TLS) is used to "wrap" SNMP payloads.  A traditional USM could be
  run underneath this protocol.

  - Likely requires no changes to SNMP protocol.
  - Is used by a number of other protocols with a great deal of success.
  - _May_ require the use of TCP.
  - Traditional TLS only performs authentication for some mechanisms, may
    require additional work to support other authentication schemes.

I am sure that others will have additional features to add to the ones I've
listed above.  Anyway, please, anyone that has any thoughts, please lets get
them out there!

--Ken

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

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

---

From: "Sharon Chisholm" <[email-masked]>
Date: Tue, 5 Apr 2005 12:26:26 -0400

hi

I don't see anything that would prohibit the development of a usable
elements of procedure around session lifespan. 

I expect to have fewer problems to take something that works, don't muck
with it and then add on something that provides the additional functionality
I need than by mushing things together and coming up with something new.

Sharon

-----Original Message-----
From: Blumenthal, Uri [mailto:[email-masked]] 
Sent: Tuesday, April 05, 2005 12:03 PM
To: Chisholm, Sharon [CAR:5K50:EXCH]; [email-masked]
Subject: RE: [Isms] Discussion: Architecture direction for ISMS

One problem with out-of-band keying is that it isn't tied with the session
lifetime. It might be OK for one-time key setup, but less useful for routine
access authorization. 

Another problem is how to integrate it smoothly, and yet another one -
[artificially] created need to maintain and synchronize two protocols and
implementations.

Summary: I'm a strong proponent of in-band keying.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Sharon Chisholm
Sent: Tuesday, April 05, 2005 10:33 AM
To: [email-masked]
Subject: RE: [Isms] Discussion: Architecture direction for ISMS

hi

Sharon 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On
Behalf Of Ken Hornstein
Sent: Friday, March 18, 2005 6:40 PM
To: [email-masked]
Subject: [Isms] Discussion: Architecture direction for ISMS

Greetings all,

- "Out of Band Keying"

  Features:

- "In Band Keying"

  Features:

- "Encapsulation keying"

--Ken

---

From: "Blumenthal, Uri" <[email-masked]>
Date: Tue, 5 Apr 2005 12:34:12 -0400

There is nothing that works and is directly usable. In your terminology,
"attempting to take what's already there and add extra functionality"
(considering what that functionality is), is precisely "mushing things
together".  End result - you will come up with something new anyway.

I will leave alone security implications for now. But in short - you
won't be able to preserve protocol's security properties.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Sharon Chisholm
Sent: Tuesday, April 05, 2005 12:26 PM
To: [email-masked]
Subject: RE: [Isms] Discussion: Architecture direction for ISMS

hi

I expect to have fewer problems to take something that works, don't muck
with it and then add on something that provides the additional
functionality
I need than by mushing things together and coming up with something new.

Sharon

-----Original Message-----
From: Blumenthal, Uri [mailto:[email-masked]] 
Sent: Tuesday, April 05, 2005 12:03 PM
To: Chisholm, Sharon [CAR:5K50:EXCH]; [email-masked]
Subject: RE: [Isms] Discussion: Architecture direction for ISMS

One problem with out-of-band keying is that it isn't tied with the
session
lifetime. It might be OK for one-time key setup, but less useful for
routine
access authorization. 

Another problem is how to integrate it smoothly, and yet another one -
[artificially] created need to maintain and synchronize two protocols
and
implementations.

-----Original Message-----

hi

Sharon 

-----Original Message-----

Greetings all,

As you all know, the outcome from the ISMS working group meeting was
that
due to a number of events, we are now tasked with deciding on the
architecture to use for ISMS.  As discussed in the meeting, there are
three
obvious choices, which neatly correspond to the three proposed ISMS
protocols.  Note that choosing a security architecture doesn't
necessarily
mean we have to choose the particular proposed protocol; my expectation
is
that once we pick a particular architecture, we'll develop a new
protocol
based on that architecture.

As I see it, we have the following architectures to choose from.  Note
that
when I say "features", I'm not making a decision on whether or not a
feature
is good or bad; it's just some of the more important points to consider.
I
have no doubt others will have other features to bring up about each
architecture.

- "Out of Band Keying"

  Features:

- "In Band Keying"

  Features:

- "Encapsulation keying"

  - Traditional TLS only performs authentication for some mechanisms,
may

I am sure that others will have additional features to add to the ones
I've
listed above.  Anyway, please, anyone that has any thoughts, please lets
get
them out there!

--Ken

---

From: "Martin Soukup" <[email-masked]>
Date: Wed, 13 Apr 2005 07:56:33 -0400

Fair point on usability, but use of such mechanisms doesn't imply knowledge.
In fact, with an IKE based system there are likely entirely equivalent
configurations with TLS. TLS certificates and IKE certificates are the same
thing (X.509). In fact, I'd argue that having users set up X.509
certificates is probably far more portable than SSH keys.

Martin.

> Behalf Of Juergen Schoenwaelder
> Sent: April 13, 2005 2:50 AM
> To: Blumenthal, Uri
> Cc: [email-masked]
> Subject: Re: [Isms] Discussion: Architecture direction for ISMS
> 
> On Wed, Apr 13, 2005 at 01:35:46AM -0400, Blumenthal, Uri wrote:
> 
> > Yes using existing keying of USM is the most easily implementable. I
> > strongly favor AUGMENTing the usmUserTable with the relevant life-time
> > etc. attributes.
> 
> Easy implementation is a nice feature but at the end can't be the goal
> of this WG. This WG is about integration and ultimately deployment.
> 
> Mind you: When the SNMPv2p party model turned out to be a complex beast
> to configure, people were writing RFCs to throw algorithms and code at
> it in order to make it simpler to deploy SNMPv2p. This did not really
> solve the problem at the end. We should avoid falling in the same
> trap again.
> 
> In my University, the number of people who know how to deal with TLS
> certificates or SSH keys is much much bigger compared to the number
> of people who know IKE, SNMPv3/USM and such things. And I believe
> this is true in many enterprise networks.
> 
> /js
> 
> --
> Juergen Schoenwaelder		    International University Bremen
> <http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen,
> Germany
>

---

From: "Martin Soukup" <[email-masked]>
Date: Wed, 13 Apr 2005 09:24:24 -0400

Actually, they are part of the existing infrastructure, just not commonly
used. Like SSL certificates in web browsers, SSH can be configured for
mutual authentication (not including the part 6 I guess - although ssh is
actually bidirectional).

Point taken that the configuration has to happen on both ends, but you sort
of have to do that anyways.

Martin.

> From: Robert Story [mailto:[email-masked]] 
> Sent: April 13, 2005 9:18 AM
> To: Soukup, Martin [CAR:5K50:EXCH]
> Cc: [email-masked]
> On Wed, 13 Apr 2005 08:28:22 -0400 Martin wrote:
> MS> Why does the reverse communication require any different 
> MS> configuration,
> 
> Again, I'm using the specific example of ssh in its current 
> form. To communicate with a peer:
> 
> 1) generate my private/public keys
> 2) configure peer with my public key
> 3) connect to host (and peer host key is save for future reference)
> 
> This is the existing infrastructure that I am referring to. 
> Note that while I do have a key for the host, it is only used 
> to verify that I'm talking to the same host the next time I connect.
> 
> To allow the host to connect back to my machine autonomously, 
> I would have to:
> 
> 4) generate a private/public key on the peer (possibly could 
> re-use host key)
> 5) configure my host with the peer's public key
> 6) install/configure/run ssh server
> 
> The point is that these steps are extra, and not part of the 
> configuration of the existing infrastructure.
> 
>

---

From: "Blumenthal, Uri" <[email-masked]>
Date: Wed, 13 Apr 2005 12:21:49 -0400

Sam, the issue is that (a) different entities have different sets of
credentials, (b) there is no conceptual mapping between those
credentials and groups that SNMPv3 VACM bases its access control
decision, (c) there is no mapping of those credentials to security
information that SNMPv3 USM needs to protect per-packet traffic, (d)
there is no mechanism to map between "long-term" credentials such as
Windows NT Domain password or RADIUS shared secret and per-packet keying
LIFE-TIME.

While all of the above is possible - it has yet to be done, i.e.
architecture defined, protocols specified, encapsulations and encodings
decided, implementations done, interoperation bugs ironed out.

Hope it answers the question.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Robert Story
Sent: Wednesday, April 13, 2005 5:14 AM
To: Sam Hartman
Cc: [email-masked]
Subject: Re: [Isms] Discussion: Architecture direction for ISMS

On Tue, 12 Apr 2005 16:22:24 -0400 Sam wrote:
SH> Why is this true?  If all engines have credentials they can use, why
can't
SH> you open a session if you need one?

My concern was was with regards to fitting into an existing
infrastructure
where unsolicited communication was not the norm. I use ssh as an
example,
because I am not familiar with TLS. While a ssh session does establish a
key
for the peer host, additional configuration would be needed to allow
that peer
to autonomously establish connections back to the originator's host.

With one of the goals of ISMS being re-use of existing infrastructure, I
was
just thinking that for some infrastructures (eg ssh), get and set would
easily
fit, but notifications would require more thinking.

---

From: "Blumenthal, Uri" <[email-masked]>
Date: Thu, 14 Apr 2005 16:51:18 -0400

I don't particularly care for OOBK - but it does not matter. What
matters is - how (with what existing protocols) to interact with those
authorizing entities of the existing infrastructure? We can always
encapsulate them, but what are they? How do you authenticate yourself to
a RADIUS server, for example?

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Thursday, April 14, 2005 1:37 PM
To: Blumenthal, Uri
Cc: Martin Soukup; [email-masked]
Subject: Re: [Isms] Discussion: Architecture direction for ISMS

On Thu, Apr 14, 2005 at 04:33:07PM -0400, Blumenthal, Uri wrote:

> Security ADs forbid us from using either IKE or EAP. I'll let Sam
speak
> on this subject.

I know. So what is then left as an option for OOBK?

/js

---

From: "Martin Soukup" <[email-masked]>
Date: Fri, 15 Apr 2005 07:29:07 -0400

Actually, I think it could be zero touch on the AAA server side, with
minimal SNMP engine impact. 

1. The returning of session lifetime is already supported in RADIUS
{Session-Timeout}
2. The returning of VACM group mapping is already supported in RADIUS (would
require a configuration file, but no code changes to most RADIUS servers)
(note that this support assumes we standardize the passing of VACM group
info since otherwise we wouldn't have interoperability of the transmission
of this information) {RADIUS servers let you put authorization/policy
information anywhere you want using configuration directives)
3. The use of an existing, supported key exchange mechanism for RADIUS (e.g.
EAP as used for the same purpose in 802.1x) (i.e. Cisco and LEAP since 2000)

On the SNMP engine side the information request must be made and the
returned information must be provided/populated in USM and VACM, but that
implementation effort seems minimal to me and many implementations would be
able to reuse off-the-shelf or freely available components for the
communication.

Martin.

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Blumenthal, Uri
> Sent: April 14, 2005 8:22 PM
> To: Thierry Moreau
> Cc: [email-masked]
> >> RADIUS server or whatever is authorizing the user, must provide
> (besides
> >> the keying, of course) the mapping to SNMP VACM, so that 
> the actual 
> >> access control can be performed.
> >> 
> >> We must solve the first problem first - getting users
> RADIUS-authorized
> >> (for example). But we must also realize that it is only a 
> half of the 
> >> issue.
> >
> >If user mapping to VACM can be in a centralized database 
> accessible to
> >the RADIUS server, perhaps we solve half of the other half of the
> issue!
> 
> No reason why it cannot be there. It's just another set of 
> data, related
> to users and their access rights.
> 
> So in case of RADIUS, the "access granted" should be accompanied by:
> 
>  - generated fresh keying for this session (including its life-time);
>  - identity to use for this connection (as probably nobody wants to
> configure user database on the SNMP agent :-);
>  - mapping of that identity onto an existing VACM group.
> 
> Not that hard really...  But somebody has to add that info to the
> existing server database. So this solution will utilize the existing
> infrastructure - but it can never be "zero touch". Something 
> extra will
> have to be done. 
>

---

From: "Blumenthal, Uri" <[email-masked]>
Date: Fri, 15 Apr 2005 10:57:44 -0400

Every existing infrastructure has its own way to identify its users.
More often than not, these identitites do not match. One of the
complaints wrt. SNMPv3 deployment is the fact that its set of identities
does not [necessarily] match those other ones - and thus user datastore
has to be filled during provisioning or configuration time. Thus when a
RADIUS user "msoukup" request SNMP access and is
authenticated+authorized, RADIUS must tell SNMP engine what identity to
use in the SNMP traffic packets. For USM, it could be dynamically
created entry with usmUserName=usmSecurityName="msoukup", or a reference
to an already-existing one (then RADIUS should tell which, or there
should be a rule by which the SNMP engine can figure it out by itself).
For other systems - perhaps they can be made to just directly take the
identity that RADIUS just authorized - but I don't think it would be any
easier.

________________________________

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Martin Soukup
	Sent: Friday, April 15, 2005 4:10 AM
	To: [email-masked]
	Subject: RE: [Isms] Discussion: Architecture direction for ISMS

	RADIUS "Access-Accept" indicates a successful authenthentication
response for a user. 

	The Access-Accept already returns a "Session-Timeout", defined
as "Sets the maximum number of seconds of service to be provided to the
user before the session terminates. This attribute value becomes the
per-user "absolute timeout."".

	RADIUS is commonly used to return policy (e.g. VACM group
mapping) and specific uses have been standardized. 

	This definitely fits well with EUSM, if something which can be
tunneled over RADIUS can generate the key binding. This is why I like
RADIUS.

	Uri, I'm not entirely sure what you meant by "identity to use"
below since authentication presumes an identity was already provided?

	Martin. 

	> [mailto:[email-masked]] On Behalf Of Randy
Presuhn 
	> Sent: April 14, 2005 8:37 PM 
	> To: [email-masked] 
	> Hi - 
	> > From: "Blumenthal, Uri" <[email-masked]> 
	> > To: "Thierry Moreau" <[email-masked]> 
	> > Cc: <[email-masked]> 
	> > Sent: Thursday, April 14, 2005 5:22 PM 
	> ... 
	> ... 
	> Sounds a lot like EUSM.  (not that that'd be a bad thing) 
	> 
	> Randy 
	> 
	> 
	> 
	>

---

From: "Martin Soukup" <[email-masked]>
Date: Fri, 15 Apr 2005 11:53:24 -0400

Ah - yes. The return of this information (User-Name) in the Access-Accept
would be supported through configuration of any standard RADIUS server.
 
martin.

-----Original Message-----
From: Blumenthal, Uri [mailto:[email-masked]] 
Sent: Friday, April 15, 2005 10:58 AM
To: Soukup, Martin [CAR:5K50:EXCH]; [email-masked]
Subject: RE: [Isms] Discussion: Architecture direction for ISMS

Every existing infrastructure has its own way to identify its users. More
often than not, these identitites do not match. One of the complaints wrt.
SNMPv3 deployment is the fact that its set of identities does not
[necessarily] match those other ones - and thus user datastore has to be
filled during provisioning or configuration time. Thus when a RADIUS user
"msoukup" request SNMP access and is authenticated+authorized, RADIUS must
tell SNMP engine what identity to use in the SNMP traffic packets. For USM,
it could be dynamically created entry with
usmUserName=usmSecurityName="msoukup", or a reference to an already-existing
one (then RADIUS should tell which, or there should be a rule by which the
SNMP engine can figure it out by itself). For other systems - perhaps they
can be made to just directly take the identity that RADIUS just authorized -
but I don't think it would be any easier.

  _____  

Behalf Of Martin Soukup

RADIUS "Access-Accept" indicates a successful authenthentication response
for a user. 

The Access-Accept already returns a "Session-Timeout", defined as "Sets the
maximum number of seconds of service to be provided to the user before the
session terminates. This attribute value becomes the per-user "absolute
timeout."".

RADIUS is commonly used to return policy (e.g. VACM group mapping) and
specific uses have been standardized. 

This definitely fits well with EUSM, if something which can be tunneled over
RADIUS can generate the key binding. This is why I like RADIUS.

Uri, I'm not entirely sure what you meant by "identity to use" below since
authentication presumes an identity was already provided?

Martin. 

> [mailto:[email-masked] <mailto:[email-masked]> ]
On Behalf Of Randy Presuhn 
> Sounds a lot like EUSM.  (not that that'd be a bad thing) 
<https://www1.ietf.org/mailman/listinfo/isms>

---

From: "Blumenthal, Uri" <[email-masked]>
Date: Fri, 15 Apr 2005 16:57:20 -0400

I don't think we're on the same page.

I'm saying that no matter what you do, there are steps necessary that
are essentially the same as creating an entry in USM user table. Because
you need an SNMP-level placeholder for the "session", SNMP-level
identity for that "session", and SNMP mapping to VACM. It does not
matter whether it's a USM entry - you have to have *something* like this
entry. I think that if USM is preserved, then dynamic temporal
(ephemeral) entries is the best approach.

An alternative is to use tunneling, which only has the mapping missing
(and is architecturally ugly as a mule). In this case you'll miss
life-time, as the session will essentially be as long as the underlying
TCP connection (for SSH or TLS) holds. And I don't quite see how you tie
the traffic with the authenticated identities on SNMP level.

I think we've said enough on this.

-----Original Message-----
From: David T. Perkins [mailto:[email-masked]] 
Sent: Friday, April 15, 2005 12:03 PM
To: Blumenthal, Uri
Cc: Martin Soukup; [email-masked]
Subject: RE: [Isms] Discussion: Architecture direction for ISMS

HI,

Uri, please don't get wrapped up with defending a small mistake
on your part.

There is a big difference between a direct mapping of identity
presented at session initiation to an entry in the USM table,
and the creation, insertion, and removal of entries (with,
of course, unique user name values) in the USM table due to
session establishment and termination. 

Whether or not you create and delete entries in the USM table
(or set existing entries to "active" and "notInService") is
not the issue. (And note, use of "active" and "notInSevice"
is an inappropriate usage.) The issue is what identity to
use (since when USM is "reused", the session message integrity
check (MIC) key is the USM auth key, and the session message
encryption key is the USM priv key). If you use a direct
mapping then you have have at most one simulanious session
per identity! 

So, to recap, if one wanted to "reuse USM" with session setup
done either "out of band" or even "in band", then the
straight forward approach is the following for setting
up a session initiated by a command generator to
a comand responder:
1) Disable USM from use except for a new service that manages
   the dynamic USM entries.
2a) With out of band session set up, the command
   generator authenticates directly with this new service
   using a yet to be defined application protocol.
2b) With in band session set up, the command generator
    sends SNMP messages as done by SBSM using the conents
    of the msgSecurityParameters field to authenticate
    with with a new service.
3) The new service then creates a session identifier (which
   is the temporal USM user name), keys, (and other things,
   like max session lifetime), inserts an entry in the
   USM table, inserts an entry in the to group table,
   and returns this info to the command responder.
   (With out of band, this info is returned a fields
   in the application protocol. With in band, this
   info is returned in the msgSecurityParameters field.)
4) If an explicit "end of session" is needed (which, I believe
   is a good thing), then the command generator (or command
   responder) communicates with the new service, which
   then removes the USM and to group table entries.
5) The new service would "wake up on schedule", and remove
   USM and to group table entries that had reached the
   end of their lifetimes.

Is the above do-able? Sure! Is the above a good thing to do?

I don't believe so, since I believe it is way too fragle,
is bloated, and could probably be more work than just
a new security model. However, I might use a subset of
it as a proto-typing and/or proof of concept for a
new security model.  

Regards,
/david t. perkins

On Fri, 15 Apr 2005, Blumenthal, Uri wrote:

> > In URI's message below, he has the the example
> > "For USM, it could be dynamically created entry with
> > usmUserName=securityName="msoukup" ..."
> >
> > This would not work!
> 
> But it will! Se below.
> 
> > If one was to attempt to "reuse USM", then
> > on session establishment, session keys would be created and
> > a session identifier would be created. The session identifier
> > (when reusing USM) HAS GOT TO BE the msgUserName field of
> > the UsmSecurityParameters sequence (which is the value of
> > of the msgSecurityParameters field of SNMPv3 messages.
> 
> Exactly. And this msgUserName will match either the
dynamically-created
> entry in usmUserTable with usmUserName=msoukup, or an existing entry
in
> the table becomes operative and authorized for this session (and gets
> keyed).
> 
> > The value of msgUserName name would be temporal, lasting
> > only the duration of the session, but also unique during
> > its existance.
> 
> Yes. This wa my first idea - I think it's the best solution. But it is
> also possible to dynamically key ("turn on") existing entries this
way.
> It works either way.
> 
> On Fri, 15 Apr 2005, Blumenthal, Uri wrote:
> 
> > Martin, I don't know RADIUS well enough - but if RADIUS User-Name is
> > just the name that RADIUS just authenticated, then it's not what we
> need
> > here. If returned User-Name may be different from the original user
> > identity under which user asked RADIUS for
> authentication/authorization
> > - then it's OK.
> >  
> > From: Martin Soukup [mailto:[email-masked]] 
> > Sent: Friday, April 15, 2005 8:53 AM
> > To: Blumenthal, Uri; [email-masked]'
> > 	Ah - yes. The return of this information (User-Name) in the
> > Access-Accept would be supported through configuration of any
standard
> > RADIUS server.
> > 		Every existing infrastructure has its own way to
> > identify its users. More often than not, these identitites do not
> match.
> > One of the complaints wrt. SNMPv3 deployment is the fact that its
set
> of
> > identities does not [necessarily] match those other ones - and thus
> user
> > datastore has to be filled during provisioning or configuration
time.
> > Thus when a RADIUS user "msoukup" request SNMP access and is
> > 			RADIUS "Access-Accept" indicates a successful
> > authenthentication response for a user. 
> > 
> > 			The Access-Accept already returns a
> > "Session-Timeout", defined as "Sets the maximum number of seconds of
> > service to be provided to the user before the session terminates.
This
> > attribute value becomes the per-user "absolute timeout."".
> > 
> > 			RADIUS is commonly used to return policy (e.g.
> > VACM group mapping) and specific uses have been standardized. 
> > 
> > 			This definitely fits well with EUSM, if
> > something which can be tunneled over RADIUS can generate the key
> > binding. This is why I like RADIUS.
> > 
> > 			Uri, I'm not entirely sure what you meant by
> > "identity to use" below since authentication presumes an identity
was
> > already provided?
> > 			> [mailto:[email-masked]] On Behalf
> > Of Randy Presuhn 
> > 			> >  - generated fresh keying for this session
> > (including its 
> > 			> life-time);

---

From: "Fleischman, Eric" <[email-masked]>
Date: Mon, 18 Apr 2005 10:20:35 -0700

Did the Security ADs give us a rationale for their "forbidding"
direction? If so, could someone please remind me what their rationale
was?

-----Original Message-----
From: Blumenthal, Uri [mailto:[email-masked]] 
Sent: Thursday, April 14, 2005 1:33 PM
To: [email-masked]; Martin Soukup
Cc: [email-masked]
Subject: RE: [Isms] Discussion: Architecture direction for ISMS

Security ADs forbid us from using either IKE or EAP. I'll let Sam speak
on this subject.

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Thursday, April 14, 2005 12:44 AM
To: Martin Soukup
Cc: Blumenthal, Uri; [email-masked]
Subject: Re: [Isms] Discussion: Architecture direction for ISMS

On Wed, Apr 13, 2005 at 09:52:58PM -0400, Martin Soukup wrote:

> Is there any reason OOBK couldn't use SSH keys, or SSH for that
matter. I'm
> not sure the ease of use of a certain existing protocol is relevant to
the
> architectural discussion?

An architecture where do not have suitable protocols in place to 
instantiate it is IMHO useless. 

So far, I heard things like IKE and EAP in the context of OOBK. I must 
have missed the document explaining how to use ssh or ssh keys to 
establish usm session keys.

/js

---

From: "Fleischman, Eric" <[email-masked]>
Date: Mon, 18 Apr 2005 10:34:02 -0700

Uri,

I am not sure that I am correctly understanding the intent of your
posting. Are you stating that because the USM SNMP engine doesn't have
its own credentials, that ISMS shouldn't as well? Or perhaps you only
want to warn us that providing such credentials carries with it
additional overhead? Or perhaps you are intending something else? 

For example, let's pretend for the moment that the WG is interested in
leveraging some of the concepts found in Eric Rescorla's DTLS ID
(http://www.ietf.org/internet-drafts/draft-rescorla-dtls-04.txt). In
this (pretend) example, are you arguing against assigning a PKI identity
to the SNMP engine in order to permit mutual authentication?

--Eric

>> No, I'm arguing an SNMP engine will know what credentials *it* *has*,

>> not *its users have*.  I.E. an SNMP engine will know what key it 
>> shares with a RADIUS server...

>An SNMP engine has *NO* credentials of its own, period. Never had. 
>All the access is done on behalf of *users* by other engines.

>Yes it would make cryptography easier if engines had some credentials 
>(i.e. was associated with some ID that possessed long-term keys, etc). 
>But it would introduce an *additional* burden of provisioning the SNMP 
>engines, and mapping *their* identities onto existing infrastructure 
>(RADIUS database? SSH? /etc/password?).

---

From: "Blumenthal, Uri" <[email-masked]>
Date: Mon, 18 Apr 2005 13:35:46 -0400

The reason is: those protocols (EAP, IKE) have rather narrow
Applicability Statements, and ISMS attempted to violate their
applicability. Sam, could you amplify please (assuming it's necessary)?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Fleischman, Eric
Sent: Monday, April 18, 2005 10:21 AM
To: [email-masked]
Subject: RE: [Isms] Discussion: Architecture direction for ISMS

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Thursday, April 14, 2005 12:44 AM
To: Martin Soukup
Cc: Blumenthal, Uri; [email-masked]
Subject: Re: [Isms] Discussion: Architecture direction for ISMS

matter. I'm
the

/js

---

From: "Martin Soukup" <[email-masked]>
Date: Mon, 18 Apr 2005 14:49:58 -0400

I do not agree with the reflection of the EAP applicability statement
presented here. However, I don't think this is relevant to the choice of an
architecture.

What issues with IBK, OOBK, or TK would need to be resolved in order for us
all to be content with one of them?

Martin.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Blumenthal, Uri
Sent: Monday, April 18, 2005 1:36 PM
To: Fleischman, Eric; [email-masked]
Subject: RE: [Isms] Discussion: Architecture direction for ISMS

The reason is: those protocols (EAP, IKE) have rather narrow Applicability
Statements, and ISMS attempted to violate their applicability. Sam, could
you amplify please (assuming it's necessary)?

-----Original Message-----

Did the Security ADs give us a rationale for their "forbidding" direction?
If so, could someone please remind me what their rationale was?

-----Original Message-----
From: Blumenthal, Uri [mailto:[email-masked]] 
Sent: Thursday, April 14, 2005 1:33 PM
To: [email-masked]; Martin Soukup
Cc: [email-masked]
Subject: RE: [Isms] Discussion: Architecture direction for ISMS

Security ADs forbid us from using either IKE or EAP. I'll let Sam speak on
this subject.

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Thursday, April 14, 2005 12:44 AM
To: Martin Soukup
Cc: Blumenthal, Uri; [email-masked]
Subject: Re: [Isms] Discussion: Architecture direction for ISMS

matter. I'm
the

/js

---

From: "Blumenthal, Uri" <[email-masked]>
Date: Mon, 18 Apr 2005 17:19:44 -0400

Yes, thank you Martin!   And "by design" means "there was much argument
and bickering, and the consensus reached was what you're seeing now".

	From: Martin Soukup [mailto:[email-masked]] 
	Sent: Monday, April 18, 2005 11:47 AM
	To: 'Sam Hartman'; Blumenthal, Uri
	Cc: [email-masked]
	Subject: RE: [Isms] Discussion: Architecture direction for ISMS

	I don't think that is an accurate restatement. I think it would
be more accurate to say: 

	Currently, by design, USM SNMP engines perform operations in the
context of a user's credentials and do not have credentials of their
own.

	Martin. 

	-----Original Message----- 
	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Sam Hartman 
	Sent: Monday, April 18, 2005 2:10 PM 
	To: Blumenthal, Uri 
	Cc: [email-masked] 
	Subject: Re: [Isms] Discussion: Architecture direction for ISMS 

	>>>>> "Blumenthal," == Blumenthal, Uri
<[email-masked]> 
	>>>>> writes: 

	    Blumenthal,> I was saying that CURRENTLY *by conscious
design* 
	    Blumenthal,> SNMP entities do not have credentials of its
own, and 
	    Blumenthal,> operate exclusively on behalf of users who
request 
	    Blumenthal,> operations. 

	Is the following a technically accurate restatement of the
above: 

	Currently, by design, USM SNMP engines share a credential for
each user?